分庫分表的正確姿勢，你GET到了麼？
每個優秀的程式員和架構師都應該掌握分庫分表，這是我的觀點。
移動網際網路時代，海量的使用者每天產生海量的數量，比如：
-
使用者表
-
訂單表
-
交易流水錶
以支付寶使用者為例，8億；微信使用者更是10億。訂單表更誇張，比如美團外賣，每天都是幾千萬的訂單。淘寶的歷史訂單總量應該百億，甚至千億級別，這些海量資料遠不是一張表能Hold住的。事實上SQL/">MySQL單表可以儲存10億級資料，只是這時候效能比較差，業界公認MySQL單表容量在1KW以下是最佳狀態，因為這時它的BTREE索引樹高在3~5之間。
既然一張表無法搞定，那麼就想辦法將資料放到多個地方，目前比較普遍的方案有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，它也能正常工作（只是這時候效能一般）。不過它的缺點很明顯：很多的資源都受到單機的限制，例如連線數，網路吞吐等！從而導致它的併發能力非常一般，遠遠達不到網際網路高併發的要求！
至於網上提到的一些其他缺點比如：無法使用外來鍵，不支援全文索引。我認為這都不算缺點，21世紀的專案如果還是使用外來鍵和全文索引，我都懶得吐槽了！
所以，如果使用分割槽表，你的業務應該具備如下兩個特點：
-
資料不是海量（分割槽數有限，儲存能力就有限）；
-
併發能力要求不高
Why 分庫分表?
最後要介紹的就是目前網際網路行業處理海量資料的通用方法：分庫分表。
雖然大家都是採用分庫分表方案來處理海量核心資料，但是還沒有一個一統江湖的中介軟體，筆者這裡列舉一些有一定知名度的分庫分表中介軟體：
-
阿里的TDDL，DRDS和cobar，
-
京東金融的sharding-jdbc；
-
民間組織的MyCAT；
-
360的Atlas；
-
美團的zebra；
sharding-jdbc的3.x版本即sharding-sphere已經支援了proxy模式。
其他比如網易，58，京東等公司都有自研的中介軟體。總之各自為戰，也可以說是百花齊放。
但是這麼多的分庫分表中介軟體全部可以歸結為兩大型別：
-
CLIENT模式；
-
PROXY模式；
CLIENT模式代表有阿里的TDDL，京東金融的sharding-jdbc。架構如下：
client arch
PROXY模式代表有阿里的cobar，民間組織的MyCAT。架構如下：
proxy arch
但是，無論是CLIENT模式，還是PROXY模式。幾個核心的步驟是一樣的：SQL解析，重寫，路由，執行，結果歸併。
筆者比較傾向於CLIENT模式，架構簡單，效能損耗較小，運維成本低。
接下來，以幾個常見的大表為案例，說明分庫分表如何落地。
實戰案例
分庫分表第一步也是最重要的一步，即sharding column的選取， sharding column選擇的好壞將直接決定整個分庫分表方案最終是否成功 。而sharding column的選取跟業務強相關，筆者認為選擇sharding column的方法最主要分析你的API流量，優先考慮流量大的API，將流量比較大的API對應的SQL提取出來，將這些SQL共同的條件作為sharding column。例如一般的OLTP系統都是對使用者提供服務，這些API對應的SQL都有條件使用者ID，那麼，使用者ID就是非常好的sharding column。
這裡列舉分庫分表的幾種主要處理思路：
-
只選取一個sharding column進行分庫分表 ；
-
多個sharding column多個分庫分表；
-
sharding column分庫分表 + ElasticSearch
再以幾張實際表為例，說明如何分庫分表。
訂單表
訂單表幾個核心欄位一般如下：
以阿里訂單系統為例（參考《企業IT架構轉型之道：阿里巴巴中臺戰略思想與架構實現》），它選擇了三個column作為三個獨立的sharding column，即：order_id，user_id，merchant_code。user_id和merchant_code就是買家ID和賣家ID，因為阿里的訂單系統中買家和賣家的查詢流量都比較大。而根據order_id進行分庫分表，應該是根據order_id的查詢也比較多。
這裡還有一點需要提及，多個sharding-column的分庫分表是全量冗餘還是隻冗餘關係索引表。
冗餘全量的情況如下--每個sharding列對應的表的資料都是全量的，這樣做的優點是不需要二次查詢，效能更好，缺點是比較浪費儲存空間：
sharding column為order_id:
冗餘索引表的情況如下--只有一個sharding column的分庫分表的資料是全量的，其他分庫分表只是與這個sharding column的關係表，這樣做的優點是節省空間，缺點是除了第一個sharding column的查詢，其他sharding column的查詢都需要二次查詢：
sharding column為order_id:
總結：選擇冗餘全量表還是索引關係表，這是一種架構上的trade off，兩者的優缺點明顯，阿里的訂單表是冗餘全量表。
使用者表
使用者表幾個核心欄位一般如下：
一般使用者登入場景即可以通過mobile_no，也可以通過email，還可以通過username進行登入。但是一些使用者相關的API，又都包含user_id，那麼可能需要根據這4個column都進行分庫分表，即4個列都是sharding-column。
賬戶表
賬戶表幾個核心欄位一般如下：
與賬戶表相關的API，一般條件都有account_no，所以以account_no作為sharding-column即可。
複雜查詢
上面提到的都是條件中有sharding column的SQL執行。但是，總有一些查詢條件是不包含sharding column的，同時，我們也不可能為了這些請求量並不高的查詢，無限制的冗餘分庫分表。那麼這些條件中沒有sharding column的SQL怎麼處理？以sharding-jdbc為例，有多少個分庫分表，就要併發路由到多少個分庫分表中執行，然後對結果進行合併。具體如何合併，可以看筆者sharding-jdbc系列文章，有分析原始碼講解合併原理。
這種條件查詢相對於有sharding column的條件查詢效能很明顯會下降很多。如果有幾十個，甚至上百個分庫分表，只要某個表的執行由於某些因素變慢，就會導致整個SQL的執行響應變慢，這非常符合木桶理論。
更有甚者，那些運營系統中的模糊條件查詢，或者上十個條件框，任何一個條件可有可無。這種情況下，即使單表都不好建立索引，更不要說分庫分表的情況下。那麼怎麼辦呢？這個時候大名鼎鼎的ElasticSearch，即es就派上用場了。將分庫分表所有資料全量冗餘到es中，將那些複雜的查詢交給es處理。
所以，以訂單表為例，整個架構如下：
archeitecture
總結
對於海量資料，且有一定的併發量的分庫分表，絕不是引入某一個分庫分表中介軟體就能解決問題，而是一項系統的工程。需要分析整個表相關的業務，讓合適的中介軟體做它最擅長的事情。例如有sharding column的查詢走分庫分表，一些模糊查詢，或者多個不固定條件篩選則走es。
做了這麼多事情後，後面還會有很多的工作，比如執行幾年後，某些表的資料量慢慢達到單表瓶頸，這時候還需要做冷資料遷移。總之，分庫分表是一項非常複雜的系統工程。任何海量資料的處理，都不是簡單的事情，做好戰鬥的準備吧！