分庫分表的技術演進

每一個優秀的程序員和架構師都應該掌握分庫分表，這是個人觀點。

移動互聯網時代，海量的用戶天天產生海量的數量，好比：

• 用戶表

• 訂單表

• 交易流水錶

以支付寶用戶爲例，8億；微信用戶更是10億。訂單表更誇張，好比美團外賣，天天都是幾千萬的訂單。淘寶的歷史訂單總量應該百億，甚至千億級別，這些海量數據遠不是一張表能Hold住的。事實上MySQL單表能夠存儲10億級數據，只是這時候性能比較差，業界公認MySQL單表容量在1KW如下是最佳狀態，由於這時它的BTREE索引樹高在3~5之間。

既然一張表沒法搞定，那麼就想辦法將數據放到多個地方，目前比較廣泛的方案有3個：

1. 分區；

2. 分庫分表；

3. NoSQL/NewSQL；

說明：只分庫，或者只分表，或者分庫分表融合方案都統一認爲是分庫分表方案，由於分庫，或者分表只是一種特殊的分庫分表而已。NoSQL比較具備表明性的是MongoDB，es。NewSQL比較具備表明性的是TiDB。

Why Not NoSQL/NewSQL?

首先，爲何不選擇第三種方案NoSQL/NewSQL，我認爲主要是RDBMS有如下幾個優勢：
- RDBMS生態完善；
- RDBMS絕對穩定；
- RDBMS的事務特性；

NoSQL/NewSQL做爲新生兒，在咱們把可靠性當作首要考察對象時，它是沒法與RDBMS相提並論的。RDBMS發展幾十年，只要有軟件的地方，它都是核心存儲的首選。

目前絕大部分公司的核心數據都是：以RDBMS存儲爲主，NoSQL/NewSQL存儲爲輔！互聯網公司又以MySQL爲主，國企&銀行等不差錢的企業以Oracle/DB2爲主！NoSQL/NewSQL宣傳的不管多牛逼，就如今各大公司對它的定位，都是RDBMS的補充，而不是取而代之！

Why Not 分區?

咱們再看分區表方案。瞭解這個方案以前，先了解它的原理：

分區表是由多個相關的底層表實現，這些底層表也是由句柄對象表示，因此咱們也能夠直接訪問各個分區，存儲引擎管理分區的各個底層表和管理普通表同樣（全部的底層表都必須使用相同的存儲引擎），分區表的索引只是在各個底層表上各自加上一個相同的索引，從存儲引擎的角度來看，底層表和一個普通表沒有任何不一樣，存儲引擎也無須知道這是一個普通表仍是一個分區表的一部分。

事實上，這個方案也不錯，它對用戶屏蔽了sharding的細節，即便查詢條件沒有sharding column，它也能正常工做（只是這時候性能通常）。不過它的缺點很明顯：不少的資源都受到單機的限制，例如鏈接數，網絡吞吐等！雖然每一個分區能夠獨立存儲，可是分區表的總入口仍是一個MySQL示例。從而致使它的併發能力很是通常，遠遠達不到互聯網高併發的要求！

至於網上提到的一些其餘缺點好比：沒法使用外鍵，不支持全文索引。我認爲這都不算缺點，21世紀的項目若是仍是使用外鍵和數據庫的全文索引，我都懶得吐槽了！

因此，若是使用分區表，你的業務應該具有以下兩個特色：

1. 數據不是海量（分區數有限，存儲能力就有限）；

2. 併發能力要求不高；

Why 分庫分表?

最後要介紹的就是目前互聯網行業處理海量數據的通用方法：分庫分表。

雖然你們都是採用分庫分表方案來處理海量核心數據，可是尚未一個一統江湖的中間件，筆者這裏列舉一些有必定知名度的分庫分表中間件：

• 阿里的TDDL，DRDS和cobar，

• 開源社區的sharding-jdbc（3.x已經改名爲sharding-sphere）；

• 民間組織的MyCAT；

• 360的Atlas；

• 美團的zebra；

其餘好比網易，58，京東等公司都有自研的中間件。總之各自爲戰，也能夠說是百花齊放。

可是這麼多的分庫分表中間件所有能夠歸結爲兩大類型：

• CLIENT模式；

• PROXY模式；

CLIENT模式表明有阿里的TDDL，開源社區的sharding-jdbc（sharding-jdbc的3.x版本即sharding-sphere已經支持了proxy模式）。架構以下：

PROXY模式表明有阿里的cobar，民間組織的MyCAT。架構以下：

可是，不管是CLIENT模式，仍是PROXY模式。幾個核心的步驟是同樣的：SQL解析，重寫，路由，執行，結果歸併。