mycat系列-概述

數(shù)據(jù)庫切分概述

OLTP和OLAP

    在互聯(lián)網(wǎng)時代，海量數(shù)據(jù)的存儲與訪問成為系統(tǒng)設(shè)計與使用的瓶頸問題，對于海量數(shù)據(jù)處理，按照使用場景，主要分為兩種類型：聯(lián)機事務(wù)處理（OLTP）和聯(lián)機分析處理（OLAP）。

   聯(lián)機事務(wù)處理（OLTP）也稱為面向交易的處理系統(tǒng)，其基本特征是原始數(shù)據(jù)可以立即傳送到計算中心進(jìn)行處理，并在很短的時間內(nèi)給出處理結(jié)果。

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

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

關(guān)系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫

  針對上面兩類系統(tǒng)有多種技術(shù)實現(xiàn)方案，存儲部分的數(shù)據(jù)庫主要分為兩大類：關(guān)系型數(shù)據(jù)庫與NoSQL數(shù)據(jù)庫。

  關(guān)系型數(shù)據(jù)庫，是建立在關(guān)系模型基礎(chǔ)上的數(shù)據(jù)庫，其借助于集合代數(shù)等數(shù)學(xué)概念和方法來處理數(shù)據(jù)庫中的數(shù)據(jù)。主流的oracle、DB2、MS SQL Server和mysql都屬于這類傳統(tǒng)數(shù)據(jù)庫。

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

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

下面分析下兩者的特點，及優(yōu)缺點：

關(guān)系型數(shù)據(jù)庫

1) 關(guān)系數(shù)據(jù)庫的特點是：

- 數(shù)據(jù)關(guān)系模型基于關(guān)系模型，結(jié)構(gòu)化存儲，完整性約束。

- 基于二維表及其之間的聯(lián)系，需要連接、并、交、差、除等數(shù)據(jù)操作。

- 采用結(jié)構(gòu)化的查詢語言（SQL）做數(shù)據(jù)讀寫。

- 操作需要數(shù)據(jù)的一致性，需要事務(wù)甚至是強一致性。

2) 優(yōu)點：

- 保持?jǐn)?shù)據(jù)的一致性（事務(wù)處理）

- 可以進(jìn)行join等復(fù)雜查詢。

- 通用化，技術(shù)成熟。

3) 缺點:

- 數(shù)據(jù)讀寫必須經(jīng)過sql解析，大量數(shù)據(jù)、高并發(fā)下讀寫性能不足。

- 對數(shù)據(jù)做讀寫，或修改數(shù)據(jù)結(jié)構(gòu)時需要加鎖，影響并發(fā)操作。

- 無法適應(yīng)非結(jié)構(gòu)化存儲。

- 擴(kuò)展困難。

- 昂貴、復(fù)雜。

NoSQL數(shù)據(jù)庫

1) NoSQL數(shù)據(jù)庫的特點是：

- 非結(jié)構(gòu)化的存儲。

- 基于多維關(guān)系模型。

- 具有特有的使用場景。

2) 優(yōu)點：

- 高并發(fā)，大數(shù)據(jù)下讀寫能力較強。

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

- 簡單，弱結(jié)構(gòu)化存儲。

3) 缺點:

- join等復(fù)雜操作能力較弱。

- 事務(wù)支持較弱。

- 通用性差。

- 無完整約束復(fù)雜業(yè)務(wù)場景支持較差。

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

何為數(shù)據(jù)切分？

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

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

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

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

垂直切分

  一個數(shù)據(jù)庫由很多表的構(gòu)成，每個表對應(yīng)著不同的業(yè)務(wù)，垂直切分是指按照業(yè)務(wù)將表進(jìn)行分類，分布到不同的數(shù)據(jù)庫上面，這樣也就將數(shù)據(jù)或者說壓力分擔(dān)到不同的庫上面，如下圖：

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

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

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

一般來講業(yè)務(wù)存在著復(fù)雜join的場景是難以切分的，往往業(yè)務(wù)獨立的易于切分。如何切分，切分到何種程度是考驗技術(shù)架構(gòu)的一個難題。

下面來分析下垂直切分的優(yōu)缺點：

優(yōu)點：

· 拆分后業(yè)務(wù)清晰，拆分規(guī)則明確。

· 系統(tǒng)之間整合或擴(kuò)展容易。

· 數(shù)據(jù)維護(hù)簡單。

缺點：

· 部分業(yè)務(wù)表無法join，只能通過接口方式解決，提高了系統(tǒng)復(fù)雜度。

· 受每種業(yè)務(wù)不同的限制存在單庫性能瓶頸，不易數(shù)據(jù)擴(kuò)展跟性能提高。

· 事務(wù)處理復(fù)雜。

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

水平切分

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

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

幾種典型的分片規(guī)則包括：

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

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

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

如圖，切分原則都是根據(jù)業(yè)務(wù)找到適合的切分規(guī)則分散到不同的庫，下面用用戶ID求模舉例：

既然數(shù)據(jù)做了拆分有優(yōu)點也就優(yōu)缺點。

優(yōu)點：

· 拆分規(guī)則抽象好，join操作基本可以數(shù)據(jù)庫做。

· 不存在單庫大數(shù)據(jù)，高并發(fā)的性能瓶頸。

· 應(yīng)用端改造較少。

· 提高了系統(tǒng)的穩(wěn)定性跟負(fù)載能力。

缺點：

· 拆分規(guī)則難以抽象。

· 分片事務(wù)一致性難以解決。

· 數(shù)據(jù)多次擴(kuò)展難度跟維護(hù)量極大。

· 跨庫join性能較差。

前面講了垂直切分跟水平切分的不同跟優(yōu)缺點，會發(fā)現(xiàn)每種切分方式都有缺點，但共同的特點缺點有：

· 引入分布式事務(wù)的問題。

· 跨節(jié)點Join的問題。

· 跨節(jié)點合并排序分頁問題。

· 多數(shù)據(jù)源管理問題。

針對數(shù)據(jù)源管理，目前主要有兩種思路：

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

B. 通過中間代理層來統(tǒng)一管理所有的數(shù)據(jù)源，后端數(shù)據(jù)庫集群對前端應(yīng)用程序透明；

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

Mycat 通過數(shù)據(jù)切分解決傳統(tǒng)數(shù)據(jù)庫的缺陷，又有了NoSQL易于擴(kuò)展的優(yōu)點。通過中間代理層規(guī)避了多數(shù)據(jù)源的處理問題，對應(yīng)用完全透明，同時對數(shù)據(jù)切分后存在的問題，也做了解決方案。下面章節(jié)就分析，mycat的由來及如何進(jìn)行數(shù)據(jù)切分問題。

由于數(shù)據(jù)切分后數(shù)據(jù)Join的難度在此也分享一下數(shù)據(jù)切分的經(jīng)驗：

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

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

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

第四原則：由于數(shù)據(jù)庫中間件對數(shù)據(jù)Join實現(xiàn)的優(yōu)劣難以把握，而且實現(xiàn)高性能難度極大，業(yè)務(wù)讀取盡量少使用多表Join。

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

更多內(nèi)容關(guān)注微信公眾號：it_haha