每個優秀的程序員和架構師都應該掌握分庫分表，這是我的觀點。
移動互聯網時代，海量的用戶每天産生海量的數量，比如：
- 用戶表
- 訂單表
- 交易流水表
以支付寶用戶爲例，8億；微信用戶更是10億。訂單表更誇張，比如美團外賣，每天都是幾千萬的訂單。淘寶的曆史訂單總量應該百億，甚至千億級別，這些海量數據遠不是一張表能Hold住的。事實上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，它也能正常工作（只是這時候性能一般）。不過它的缺點很明顯：很多的資源都受到單機的限制，例如連接數，網絡吞吐等！雖然每個分區可以獨立存儲，但是分區表的總入口還是一個MySQL示例。從而導致它的並發能力非常一般，遠遠達不到互聯網高並發的要求！
至于網上提到的一些其他缺點比如：無法使用外鍵，不支持全文索引。我認爲這都不算缺點，21世紀的項目如果還是使用外鍵和數據庫的全文索引，我都懶得吐槽了！
所以，如果使用分區表，你的業務應該具備如下兩個特點：
- 數據不是海量（分區數有限，存儲能力就有限）；
- 並發能力要求不高；
Why 分庫分表?
最後要介紹的就是目前互聯網行業處理海量數據的通用方法：分庫分表。
雖然大家都是采用分庫分表方案來處理海量核心數據，但是還沒有一個一統江湖的中間件，筆者這裏列舉一些有一定知名度的分庫分表中間件：
- 阿裏的TDDL，DRDS和cobar，
- 開源社區的sharding-jdbc（3.x已經更名爲sharding-sphere）；
- 民間組織的MyCAT；
- 360的Atlas；
- 美團的zebra；
備注：sharding-jdbc的作者張亮大神原來在當當，現在在京東金融。但是sharding-jdbc的版權屬于開源社區，不是公司的，也不是張亮個人的！
其他比如網易，58，京東等公司都有自研的中間件。總之各自爲戰，也可以說是百花齊放。
但是這麽多的分庫分表中間件全部可以歸結爲兩大類型：
- CLIENT模式；
- PROXY模式；
CLIENT模式代表有阿裏的TDDL，開源社區的sharding-jdbc（sharding-jdbc的3.x版本即sharding-sphere已經支持了proxy模式）。架構如下：
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分庫分表 + es；
再以幾張實際表爲例，說明如何分庫分表。
訂單表
訂單表幾個核心字段一般如下：
冗余全量
冗余關系索引表的情況如下–只有一個sharding column的分庫分表的數據是全量的，其他分庫分表只是與這個sharding column的關系表，這樣做的優點是節省空間，缺點是除了第一個sharding column的查詢，其他sharding column的查詢都需要二次查詢，這三張表的關系如下圖所示（淺綠色字段就是sharding column）：
用戶表
一般用戶登錄場景既可以通過mobile_no，又可以通過email，還可以通過username進行登錄。但是一些用戶相關的API，又都包含user_id，那麽可能需要根據這4個column都進行分庫分表，即4個列都是sharding-column。
賬戶表
賬戶表幾個核心字段一般如下：
條件篩選
所以，以訂單表爲例，整個架構如下：
es V.S. solr
如果抛開選型過程中所有曆史包袱，單論es+HBase和solr+HBase的優劣，很明顯後者是更好的選擇。solr+HBase高度集成，引入索引服務後我們最關心，也是最重要的索引一致性問題，solr+HBase已經有了非常成熟的解決方案一一Lily HBase Indexer。
延伸閱讀
阿裏雲上的雲數據庫HBase版也是借助solr實現全文索引，有興趣的同學可以戳鏈接了解更多：https://help.aliyun.com/product/49055.html?spm=5176.124785.631202.con1.603452c0cz7bj2。
es+HBase
HBase檢索能力擴展