【大數據和雲計算技術社區】分庫分表技術演進&最佳實踐筆記

1.需求背景

移動互聯網時代，海量的用戶天天產生海量的數量，這些海量數據遠不是一張表能Hold住的。好比

• 用戶表：支付寶8億，微信10億。CITIC對公140萬，對私8700萬。
• 訂單表：美團天天幾千萬，淘寶曆史訂單百億、千億。
• 交易流水錶

2.選擇方案

（1）NoSQL/NewSQL（不選擇）

     選擇RDBMS，不選擇NoSQL/NewSQL，主要是由於NoSQL/NewSQL可靠性沒法與RDBMS相提並論。RDBMS有如下幾個優勢：

• RDBMS生態完善；
• RDBMS絕對穩定；
• RDBMS的事務特性；

     目前絕大部分公司的核心數據都是：以RDBMS存儲爲主，NoSQL/NewSQL存儲爲輔！互聯網公司又以MySQL爲主，國企&銀行等不差錢的企業以Oracle/DB2爲主！NoSQL比較具備表明性的是MongoDB，es。NewSQL比較具備表明性的是TiDB。

（2）分區（不選擇）

• 分區原理：分區表是由多個相關的底層表實現，存儲引擎管理分區的各個底層表和管理普通表同樣，只是分區表在各個底層表上各自加上一個相同的索引（分區表要求全部的底層表都必須使用相同的存儲引擎）。
• 分區優勢：它對用戶屏蔽了sharding的細節，即便查詢條件沒有sharding column，它也能正常工做（只是這時候性能通常）。
• 分區缺點：鏈接數、網絡吞吐量等資源都受到單機的限制；併發能力遠遠達不到互聯網高併發的要求。（主要由於雖然每一個分區能夠獨立存儲，可是分區表的總入口仍是一個MySQL示例）。
• 適用場景：併發能力要求不高；數據不是海量（分區數有限，存儲能力就有限）。

（3）分庫分表（選擇）

 互聯網行業處理海量數據的通用方法：分庫分表。 分庫分表中間件所有能夠歸結爲兩大類型：

• CLIENT模式；

• PROXY模式；

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

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

 

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

 3.分庫分表思路（MYSQL）

• 單個sharding column分庫分表 ；
• 多個sharding column分庫分表；
• sharding column分庫分表 + ES檢索；

4.分庫分表落地（MYSQL）

（1）選擇合適的sharding column

   分庫分表第一步也是最重要的一步，即sharding column的選取，sharding column選擇的好壞將直接決定整個分庫分表方案最終是否成功。sharding column的選取跟業務強相關。

• 選擇方法：分析你的API流量，將流量比較大的API對應的SQL提取出來，將這些SQL共同的條件做爲sharding column。
• 選擇示例：例如通常的OLTP系統都是對用戶提供服務，這些API對應的SQL都有條件用戶ID，那麼，用戶ID就是很是好的sharding column。

（2）冗餘全量表和冗餘關係表選擇（訂單表）

例如將一張訂單表t_order拆分紅三張表t_order、t_user_order、t_merchant_order。分別使用三個獨立的sharding column，即order_id（訂單號），user_id（用戶ID），merchant_code（商家ID）。

冗餘全量表：每一個sharding列對應的表的數據都是全量的

 

 冗餘關係表：只有一個sharding column的分庫分表的數據是全量的，其餘分庫分表只是與這個sharding column的關係表。實際使用中可能會冗餘更多經常使用字段，如用戶名稱、商戶名稱等。

冗餘全量表 VS 冗餘關係表

• 速度對比：冗餘全量表速度更快，冗餘關係表須要二次查詢，即便有引入緩存，仍是多一次網絡開銷；
• 存儲成本：冗餘全量表須要幾倍於冗餘關係表的存儲成本；
• 維護代價：冗餘全量表維護代價更大，涉及到數據變動時，多張表都要進行修改。

總結：選擇冗餘全量表仍是索引關係表，這是一種架構上的trade off（權衡），二者的優缺點明顯，阿里的訂單表是冗餘全量表。

 （3）單個sharding column分庫分表示例（帳戶表）

通常帳戶相關API使用account_no爲sharding column

（4）多個sharding column分庫分表示例（用戶表）

用戶能夠經過mobile_no，email和username進行登陸，一些用戶相關API又常使用user_id，因此sharding column選這4個字段。

 （5）sharding column分庫分表 + ES檢索（模糊查詢）

一些複雜查詢，若是條件中沒有sharding column的SQL，尤爲是有些運營系統中的模糊條件查詢，或者上十個條件篩選。例如淘寶個人全部訂單頁面，篩選條件有多個，且商品標題能夠模糊匹配，這即便是單表都解決不了的問題，更不用談分庫分表了。

sharding column + es的模式，將分庫分表全部數據全量冗餘到es中，將那些複雜的查詢交給es處理。以訂單表爲例：

 PS：多sharding column不到萬不得已的狀況下最好不要使用，建議採用單sharding column + es的模式簡化架構。

5.全文索引思路（HBase）

• Solr+HBase
• ES+HBase

可能參與條件檢索的字段索引到ES中，全部字段的全量數據保存到HBase中，這就是經典的ES+HBase組合方案，即索引與數據存儲隔離的方案。Hadoop體系下的HBase存儲能力咱們都知道是海量的，並且根據它的rowkey查詢性能那叫一個快如閃電。而es的多條件檢索能力很是強大。這個方案把es和HBase的優勢發揮的淋漓盡致，同時又規避了它們的缺點，能夠說是一個揚長避免的最佳實踐。

它們之間的交互大概是這樣的：先根據用戶輸入的條件去es查詢獲取符合過濾條件的rowkey值，而後用rowkey值去HBase查詢，後面這一查詢步驟的時間幾乎能夠忽略，由於這是HBase最擅長的場景，交互圖以下所示： 

 

6.總結

最後，對幾種方案總結以下（sharding column簡稱爲sc）：

對於海量數據，且有必定的併發量的分庫分表，毫不是引入某一個分庫分表中間件就能解決問題，而是一項系統的工程。須要分析整個表相關的業務，讓合適的中間件作它最擅長的事情。例若有sharding column的查詢走分庫分表，一些模糊查詢，或者多個不固定條件篩選則走es，海量存儲則交給HBase。

作了這麼多事情後，後面還會有不少的工做要作，好比數據同步的一致性問題，還有運行一段時間後，某些表的數據量慢慢達到單表瓶頸，這時候還須要作冷數據遷移。

 

MySQL單表能夠存儲10億級數據，只是這時候性能比較差，業界公認MySQL單表容量在1KW如下是最佳狀態，由於這時它的BTREE索引樹高在3~5之間。

 

參考文檔：

分庫分表技術演進&最佳實踐-修訂篇

HBase應用實踐專場-HBase for Solr

分庫分表思路

基於Solr的HBase多條件查詢測試