mycat系列-概述

數據庫切分概述

OLTP和OLAP

    在互聯網時代，海量數據的存儲與訪問成為系統設計與使用的瓶頸問題，對于海量數據處理，按照使用場景，主要分為兩種類型：聯機事務處理（OLTP）和聯機分析處理（OLAP）。

   聯機事務處理（OLTP）也稱為面向交易的處理系統，其基本特征是原始數據可以立即傳送到計算中心進行處理，并在很短的時間內給出處理結果。

    聯機分析處理（OLAP）是指通過多維的方式對數據進行分析、查詢和報表，可以同數據挖掘工具、統計分析工具配合使用，增強決策分析功能。

對于兩者的主要區別可以用下表來說明：

關系型數據庫和NoSQL數據庫

  針對上面兩類系統有多種技術實現方案，存儲部分的數據庫主要分為兩大類：關系型數據庫與NoSQL數據庫。

  關系型數據庫，是建立在關系模型基礎上的數據庫，其借助于集合代數等數學概念和方法來處理數據庫中的數據。主流的oracle、DB2、MS SQL Server和mysql都屬于這類傳統數據庫。

NoSQL數據庫，全稱為Not Only SQL，意思就是適用關系型數據庫的時候就使用關系型數據庫，不適用的時候也沒有必要非使用關系型數據庫不可，可以考慮使用更加合適的數據存儲。主要分為臨時性鍵值存儲（memcached、Redis）、永久性鍵值存儲（ROMA、Redis）、面向文檔的數據庫（MongoDB、CouchDB）、面向列的數據庫（Cassandra、HBase），每種NoSQL都有其特有的使用場景及優點。

  Oracle，mysql等傳統的關系數據庫非常成熟并且已大規模商用，為什么還要用NoSQL數據庫呢？主要是由于隨著互聯網發展，數據量越來越大，對性能要求越來越高，傳統數據庫存在著先天性的缺陷，即單機（單庫）性能瓶頸，并且擴展困難。這樣既有單機單庫瓶頸，卻又擴展困難，自然無法滿足日益增長的海量數據存儲及其性能要求，所以才會出現了各種不同的NoSQL產品，NoSQL根本性的優勢在于在云計算時代，簡單、易于大規模分布式擴展，并且讀寫性能非常高。

下面分析下兩者的特點，及優缺點：

關系型數據庫

1) 關系數據庫的特點是：

- 數據關系模型基于關系模型，結構化存儲，完整性約束。

- 基于二維表及其之間的聯系，需要連接、并、交、差、除等數據操作。

- 采用結構化的查詢語言（SQL）做數據讀寫。

- 操作需要數據的一致性，需要事務甚至是強一致性。

2) 優點：

- 保持數據的一致性（事務處理）

- 可以進行join等復雜查詢。

- 通用化，技術成熟。

3) 缺點:

- 數據讀寫必須經過sql解析，大量數據、高并發下讀寫性能不足。

- 對數據做讀寫，或修改數據結構時需要加鎖，影響并發操作。

- 無法適應非結構化存儲。

- 擴展困難。

- 昂貴、復雜。

NoSQL數據庫

1) NoSQL數據庫的特點是：

- 非結構化的存儲。

- 基于多維關系模型。

- 具有特有的使用場景。

2) 優點：

- 高并發，大數據下讀寫能力較強。

- 基本支持分布式，易于擴展，可伸縮。

- 簡單，弱結構化存儲。

3) 缺點:

- join等復雜操作能力較弱。

- 事務支持較弱。

- 通用性差。

- 無完整約束復雜業務場景支持較差。

  雖然在云計算時代，傳統數據庫存在著先天性的弊端，但是NoSQL數據庫又無法將其替代，NoSQL只能作為傳統數據的補充而不能將其替代，所以規避傳統數據庫的缺點是目前大數據時代必須要解決的問題。如果傳統數據易于擴展，可切分，就可以避免單機（單庫）的性能缺陷，但是由于目前開源或者商用的傳統數據庫基本不支持大規模自動擴展，所以就需要借助第三方來做處理，那就是本書要講的數據切分，下面就來分析一下如何進行數據切分。

何為數據切分？

  簡單來說，就是指通過某種特定的條件，將我們存放在同一個數據庫中的數據分散存放到多個數據庫（主機）上面，以達到分散單臺設備負載的效果。

數據的切分（Sharding）根據其切分規則的類型，可以分為兩種切分模式。一種是按照不同的表（或者Schema）來切分到不同的數據庫（主機）之上，這種切可以稱之為數據的垂直（縱向）切分；另外一種則是根據表中的數據的邏輯關系，將同一個表中的數據按照某種條件拆分到多臺數據庫（主機）上面，這種切分稱之為數據的水平（橫向）切分。

  垂直切分的最大特點就是規則簡單，實施也更為方便，尤其適合各業務之間的耦合度非常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業務模塊所使用的表分拆到不同的數據庫中。根據不同的表來進行拆分，對應用程序的影響也更小，拆分規則也會比較簡單清晰。

水平切分于垂直切分相比，相對來說稍微復雜一些。因為要將同一個表中的不同數據拆分到不同的數據庫中，對于應用程序來說，拆分規則本身就較根據表名來拆分更為復雜，后期的數據維護也會更為復雜一些。

垂直切分

  一個數據庫由很多表的構成，每個表對應著不同的業務，垂直切分是指按照業務將表進行分類，分布到不同的數據庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面，如下圖：

系統被切分成了，用戶，訂單交易，支付幾個模塊。

一個架構設計較好的應用系統，其總體功能肯定是由很多個功能模塊所組成的，而每一個功能模塊所需要的數據對應到數據庫中就是一個或者多個表。而在架構設計中，各個功能模塊相互之間的交互點越統一越少，系統的耦合度就越低，系統各個模塊的維護性以及擴展性也就越好。這樣的系統，實現數據的垂直切分也就越容易。

但是往往系統之有些表難以做到完全的獨立，存在這擴庫join的情況，對于這類的表，就需要去做平衡，是數據庫讓步業務，共用一個數據源，還是分成多個庫，業務之間通過接口來做調用。在系統初期，數據量比較少，或者資源有限的情況下，會選擇共用數據源，但是當數據發展到了一定的規模，負載很大的情況，就需要必須去做分割。

一般來講業務存在著復雜join的場景是難以切分的，往往業務獨立的易于切分。如何切分，切分到何種程度是考驗技術架構的一個難題。

下面來分析下垂直切分的優缺點：

優點：

· 拆分后業務清晰，拆分規則明確。

· 系統之間整合或擴展容易。

· 數據維護簡單。

缺點：

· 部分業務表無法join，只能通過接口方式解決，提高了系統復雜度。

· 受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。

· 事務處理復雜。

由于垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過于龐大，存在單庫讀寫與存儲瓶頸，所以就需要水平拆分來做解決。

水平切分

相對于垂直拆分，水平拆分不是將表做分類，而是按照某個字段的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解為是按照數據行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其他的數據庫中，如圖：

拆分數據就需要定義分片規則。關系型數據庫是行列的二維模型，拆分的第一原則是找到拆分維度。比如：從會員的角度來分析，商戶訂單交易類系統中查詢會員某天某月某個訂單，那么就需要按照會員結合日期來拆分，不同的數據按照會員ID做分組，這樣所有的數據查詢join都會在單庫內解決；如果從商戶的角度來講，要查詢某個商家某天所有的訂單數，就需要按照商戶ID做拆分；但是如果系統既想按會員拆分，又想按商家數據，則會有一定的困難。如何找到合適的分片規則需要綜合考慮衡量。

幾種典型的分片規則包括：

· 按照用戶ID求模，將數據分散到不同的數據庫，具有相同數據用戶的數據都被分散到一個庫中。

· 按照日期，將不同月甚至日的數據分散到不同的庫中。

· 按照某個特定的字段求摸，或者根據特定范圍段分散到不同的庫中。

如圖，切分原則都是根據業務找到適合的切分規則分散到不同的庫，下面用用戶ID求模舉例：

既然數據做了拆分有優點也就優缺點。

優點：

· 拆分規則抽象好，join操作基本可以數據庫做。

· 不存在單庫大數據，高并發的性能瓶頸。

· 應用端改造較少。

· 提高了系統的穩定性跟負載能力。

缺點：

· 拆分規則難以抽象。

· 分片事務一致性難以解決。

· 數據多次擴展難度跟維護量極大。

· 跨庫join性能較差。

前面講了垂直切分跟水平切分的不同跟優缺點，會發現每種切分方式都有缺點，但共同的特點缺點有：

· 引入分布式事務的問題。

· 跨節點Join的問題。

· 跨節點合并排序分頁問題。

· 多數據源管理問題。

針對數據源管理，目前主要有兩種思路：

A. 客戶端模式，在每個應用程序模塊中配置管理自己需要的一個（或者多個）數據源，直接訪問各個數據庫，在模塊內完成數據的整合；

B. 通過中間代理層來統一管理所有的數據源，后端數據庫集群對前端應用程序透明；

可能90%以上的人在面對上面這兩種解決思路的時候都會傾向于選擇第二種，尤其是系統不斷變得龐大復雜的時候。確實，這是一個非常正確的選擇，雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統的擴展性來說，是非常有幫助的。

Mycat 通過數據切分解決傳統數據庫的缺陷，又有了NoSQL易于擴展的優點。通過中間代理層規避了多數據源的處理問題，對應用完全透明，同時對數據切分后存在的問題，也做了解決方案。下面章節就分析，mycat的由來及如何進行數據切分問題。

由于數據切分后數據Join的難度在此也分享一下數據切分的經驗：

第一原則：能不切分盡量不要切分。

第二原則：如果要切分一定要選擇合適的切分規則，提前規劃好。

第三原則：數據切分盡量通過數據冗余或表分組（Table Group）來降低跨庫Join的可能。

第四原則：由于數據庫中間件對數據Join實現的優劣難以把握，而且實現高性能難度極大，業務讀取盡量少使用多表Join。

什么是mycat，maycat從哪里來，又是如何解決這些問題的，下一章讓我們來作分析。

更多內容關注微信公眾號：it_haha