一、數據切分
關係型數據庫本身比較容易成爲系統瓶頸，單機存儲容量、連接數、處理能力都有限。當單表的數據量達到1000W或100G以後，由於查詢維度較多，即使添加從庫、優化索引，做很多操作時性能仍下降嚴重。此時就要考慮對其進行切分了，切分的目的就在於減少數據庫的負擔，縮短查詢時間。
數據庫分佈式核心內容無非就是數據切分（Sharding），以及切分後對數據的定位、整合。數據切分就是將數據分散存儲到多個數據庫中，使得單一數據庫中的數據量變小，通過擴充主機的數量緩解單一數據庫的性能問題，從而達到提升數據庫操作性能的目的。
數據切分根據其切分類型，可以分爲兩種方式：垂直（縱向）切分和水平（橫向）切分。
二、垂直（縱向）切分
垂直切分常見有垂直分庫和垂直分表兩種。
垂直分庫就是根據業務耦合性，將關聯度低的不同表存儲在不同的數據庫。做法與大系統拆分爲多個小系統類似，按業務分類進行獨立劃分。與"微服務治理"的做法相似，每個微服務使用單獨的一個數據庫。如圖：
垂直分表是基於數據庫中的"列"進行，某個表字段較多，可以新建一張擴展表，將不經常用或字段長度較大的字段拆分出去到擴展表中。在字段很多的情況下（例如一個大表有100多個字段），通過"大表拆小表"，更便於開發與維護，也能避免跨頁問題，MySQL底層是通過數據頁存儲的，一條記錄佔用空間過大會導致跨頁，造成額外的性能開銷。另外數據庫以行爲單位將數據加載到內存中，這樣表中字段長度較短且訪問頻率較高，內存能加載更多的數據，命中率更高，減少了磁盤IO，從而提升了數據庫性能。
垂直切分的優點：
- 解決業務系統層面的耦合，業務清晰
- 與微服務的治理類似，也能對不同業務的數據進行分級管理、維護、監控、擴展等
- 高併發場景下，垂直切分一定程度的提升IO、數據庫連接數、單機硬件資源的瓶頸
缺點：
- 部分表無法join，只能通過接口聚合方式解決，提升了開發的複雜度
- 分佈式事務處理複雜
- 依然存在單表數據量過大的問題（需要水平切分）
三、水平（橫向）切分
當一個應用難以再細粒度的垂直切分，或切分後數據量行數巨大，存在單庫讀寫、存儲性能瓶頸，這時候就需要進行水平切分了。
水平切分分爲庫內分表和分庫分表，是根據表內數據內在的邏輯關係，將同一個表按不同的條件分散到多個數據庫或多個表中，每個表中只包含一部分數據，從而使得單個表的數據量變小，達到分佈式的效果。如圖所示：
庫內分表只解決了單一表數據量過大的問題，但沒有將表分佈到不同機器的庫上，因此對於減輕MySQL數據庫的壓力來說，幫助不是很大，大家還是競爭同一個物理機的CPU、內存、網絡IO，最好通過分庫分表來解決。
水平切分的優點：
- 不存在單庫數據量過大、高併發的性能瓶頸，提升系統穩定性和負載能力
- 應用端改造較小，不需要拆分業務模塊
缺點：
- 跨分片的事務一致性難以保證
- 跨庫的join關聯查詢性能較差
- 數據多次擴展難度和維護量極大
水平切分後同一張表會出現在多個數據庫/表中，每個庫/表的內容不同。幾種典型的數據分片規則爲：
1.根據數值範圍
按照時間區間或ID區間來切分。例如：按日期將不同月甚至是日的數據分散到不同的庫中；將userId爲1~9999的記錄分到第一個庫，10000~20000的分到第二個庫，以此類推。某種意義上，某些系統中使用的"冷熱數據分離"，將一些使用較少的歷史數據遷移到其他庫中，業務功能上只提供熱點數據的查詢，也是類似的實踐。
這樣的優點在於：
- 單表大小可控
- 天然便於水平擴展，後期如果想對整個分片集羣擴容時，只需要添加節點即可，無需對其他分片的數據進行遷移
- 使用分片字段進行範圍查找時，連續分片可快速定位分片進行快速查詢，有效避免跨分片查詢的問題。
缺點：
- 熱點數據成爲性能瓶頸。連續分片可能存在數據熱點，例如按時間字段分片，有些分片存儲最近時間段內的數據，可能會被頻繁的讀寫，而有些分片存儲的歷史數據，則很少被查詢
2、根據數值取模
一般採用hash取模mod的切分方式，例如：將 Customer 表根據 cusno 字段切分到4個庫中，餘數爲0的放到第一個庫，餘數爲1的放到第二個庫，以此類推。這樣同一個用戶的數據會分散到同一個庫中，如果查詢條件帶有cusno字段，則可明確定位到相應庫去查詢。
優點：
- 數據分片相對比較均勻，不容易出現熱點和併發訪問的瓶頸
缺點：
- 後期分片集羣擴容時，需要遷移舊的數據（使用一致性hash算法能較好的避免這個問題）
- 容易面臨跨分片查詢的複雜問題。比如上例中，如果頻繁用到的查詢條件中不帶cusno時，將會導致無法定位數據庫，從而需要同時向4個庫發起查詢，再在內存中合併數據，取最小集返回給應用，分庫反而成爲拖累。
四、分庫分錶帶來的問題
分庫分表能有效的環節單機和單庫帶來的性能瓶頸和壓力，突破網絡IO、硬件資源、連接數的瓶頸，同時也帶來了一些問題。下面將描述這些技術挑戰以及對應的解決思路。
1、事務一致性問題
分佈式事務
當更新內容同時分佈在不同庫中，不可避免會帶來跨庫事務問題。跨分片事務也是分佈式事務，沒有簡單的方案，一般可使用"XA協議"和"兩階段提交"處理。
分佈式事務能最大限度保證了數據庫操作的原子性。但在提交事務時需要協調多個節點，推後了提交事務的時間點，延長了事務的執行時間。導致事務在訪問共享資源時發生衝突或死鎖的概率增高。隨着數據庫節點的增多，這種趨勢會越來越嚴重，從而成爲系統在數據庫層面上水平擴展的枷鎖。
最終一致性
對於那些性能要求很高，但對一致性要求不高的系統，往往不苛求系統的實時一致性，只要在允許的時間段內達到最終一致性即可，可採用事務補償的方式。與事務在執行中發生錯誤後立即回滾的方式不同，事務補償是一種事後檢查補救的措施，一些常見的實現方法有：對數據進行對賬檢查，基於日誌進行對比，定期同標準數據來源進行同步等等。事務補償還要結合業務系統來考慮。
2、跨節點關聯查詢 join 問題
切分之前，系統中很多列表和詳情頁所需的數據可以通過sql join來完成。而切分之後，數據可能分佈在不同的節點上，此時join帶來的問題就比較麻煩了，考慮到性能，儘量避免使用join查詢。
解決這個問題的一些方法：
-
全局表
全局表，也可看做是"數據字典表"，就是系統中所有模塊都可能依賴的一些表，爲了避免跨庫join查詢，可以將這類表在每個數據庫中都保存一份。這些數據通常很少會進行修改，所以也不擔心一致性的問題。
-
字段冗餘
一種典型的反範式設計，利用空間換時間，爲了性能而避免join查詢。例如：訂單表保存userId時候，也將userName冗餘保存一份，這樣查詢訂單詳情時就不需要再去查詢"買家user表"了。
但這種方法適用場景也有限，比較適用於依賴字段比較少的情況。而冗餘字段的數據一致性也較難保證，就像上面訂單表的例子，買家修改了userName後，是否需要在歷史訂單中同步更新呢？這也要結合實際業務場景進行考慮。
-
數據組裝
在系統層面，分兩次查詢，第一次查詢的結果集中找出關聯數據id，然後根據id發起第二次請求得到關聯數據。最後將獲得到的數據進行字段拼裝。
3、跨節點分頁、排序、函數問題
跨節點多庫進行查詢時，會出現limit分頁、order by排序等問題。分頁需要按照指定字段進行排序，當排序字段就是分片字段時，通過分片規則就比較容易定位到指定的分片；當排序字段非分片字段時，就變得比較複雜了。需要先在不同的分片節點中將數據進行排序並返回，然後將不同分片返回的結果集進行彙總和再次排序，最終返回給用戶。如圖所示：
上圖中只是取第一頁的數據，對性能影響還不是很大。但是如果取得頁數很大，情況則變得複雜很多，因爲各分片節點中的數據可能是隨機的，爲了排序的準確性，需要將所有節點的前N頁數據都排序好做合併，最後再進行整體的排序，這樣的操作時很耗費CPU和內存資源的，所以頁數越大，系統的性能也會越差。
在使用Max、Min、Sum、Count之類的函數進行計算的時候，也需要先在每個分片上執行相應的函數，然後將各個分片的結果集進行彙總和再次計算，最終將結果返回。如圖所示：
5、數據遷移、擴容問題
當業務高速發展，面臨性能和存儲的瓶頸時，纔會考慮分片設計，此時就不可避免的需要考慮歷史數據遷移的問題。一般做法是先讀出歷史數據，然後按指定的分片規則再將數據寫入到各個分片節點中。此外還需要根據當前的數據量和QPS，以及業務發展的速度，進行容量規劃，推算出大概需要多少分片（一般建議單個分片上的單表數據量不超過1000W）
如果採用數值範圍分片，只需要添加節點就可以進行擴容了，不需要對分片數據遷移。如果採用的是數值取模分片，則考慮後期的擴容問題就相對比較麻煩。
五、什麼時候考慮切分
下面講述一下什麼時候需要考慮做數據切分。
1、能不切分儘量不要切分
並不是所有表都需要進行切分，主要還是看數據的增長速度。切分後會在某種程度上提升業務的複雜度，數據庫除了承載數據的存儲和查詢外，協助業務更好的實現需求也是其重要工作之一。
不到萬不得已不用輕易使用分庫分表這個大招，避免"過度設計"和"過早優化"。分庫分表之前，不要爲分而分，先盡力去做力所能及的事情，例如：升級硬件、升級網絡、讀寫分離、索引優化等等。當數據量達到單表的瓶頸時候，再考慮分庫分表。
2、數據量過大，正常運維影響業務訪問
這裏說的運維，指：
1）對數據庫備份，如果單表太大，備份時需要大量的磁盤IO和網絡IO。例如1T的數據，網絡傳輸佔50MB時候，需要20000秒才能傳輸完畢，整個過程的風險都是比較高的。
2）大表會經常訪問與更新，就更有可能出現鎖等待。將數據切分，用空間換時間，變相降低訪問壓力
六. 支持分庫分表中間件
站在巨人的肩膀上能省力很多，目前分庫分表已經有一些較爲成熟的開源解決方案：
- sharding-jdbc（噹噹）
- TSharding（蘑菇街）
- Atlas（奇虎360）
- Cobar（阿里巴巴）
- MyCAT（基於Cobar）
- Oceanus（58同城）