http://blog.csdn.net/bluishglc/article/details/6161475

本文著重介紹sharding的基本思想和理論上的切分策略，關于更加細致的實施策略和參考事例請參考我的另一篇博文：數據庫分庫分表(sharding)系列(一) 拆分實施策略和示例演示?

一、基本思想

????? Sharding的基本思想就要把一個數據庫切分成多個部分放到不同的數據庫(server)上，從而緩解單一數據庫的性能問題。不太嚴格的講，對于海量數據的數據庫，如果是因為表多而數據多，這時候適合使用垂直切分，即把關系緊密（比如同一模塊）的表切分出來放在一個server上。如果表并不多，但每張表的數據非常多，這時候適合水平切分，即把表的數據按某種規則（比如按ID散列）切分到多個數據庫(server)上。當然，現實中更多是這兩種情況混雜在一起，這時候需要根據實際情況做出選擇，也可能會綜合使用垂直與水平切分，從而將原有數據庫切分成類似矩陣一樣可以無限擴充的數據庫(server)陣列。下面分別詳細地介紹一下垂直切分和水平切分.

????? 垂直切分的最大特點就是規則簡單，實施也更為方便，尤其適合各業務之間的耦合度非
常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業
務模塊所使用的表分拆到不同的數據庫中。根據不同的表來進行拆分，對應用程序的影響也
更小，拆分規則也會比較簡單清晰。（這也就是所謂的”share nothing”）。

????? 水平切分于垂直切分相比，相對來說稍微復雜一些。因為要將同一個表中的不同數據拆
分到不同的數據庫中，對于應用程序來說，拆分規則本身就較根據表名來拆分更為復雜，后
期的數據維護也會更為復雜一些。

????? 讓我們從普遍的情況來考慮數據的切分：一方面，一個庫的所有表通常不可能由某一張表全部串聯起來，這句話暗含的意思是，水平切分幾乎都是針對一小搓一小搓（實際上就是垂直切分出來的塊）關系緊密的表進行的，而不可能是針對所有表進行的。另一方面，一些負載非常高的系統，即使僅僅只是單個表都無法通過單臺數據庫主機來承擔其負載，這意味著單單是垂直切分也不能完全解決問明。因此多數系統會將垂直切分和水平切分聯合使用，先對系統做垂直切分，再針對每一小搓表的情況選擇性地做水平切分。從而將整個數據庫切分成一個分布式矩陣。

?

二、切分策略

????? 如前面所提到的，切分是按先垂直切分再水平切分的步驟進行的。垂直切分的結果正好為水平切分做好了鋪墊。垂直切分的思路就是分析表間的聚合關系，把關系緊密的表放在一起。多數情況下可能是同一個模塊，或者是同一“聚集”。這里的“聚集”正是領域驅動設計里所說的聚集。在垂直切分出的表聚集內，找出“根元素”（這里的“根元素”就是領域驅動設計里的“聚合根”），按“根元素”進行水平切分，也就是從“根元素”開始，把所有和它直接與間接關聯的數據放入一個shard里。這樣出現跨shard關聯的可能性就非常的小。應用程序就不必打斷既有的表間關聯。比如：對于社交網站，幾乎所有數據最終都會關聯到某個用戶上，基于用戶進行切分就是最好的選擇。再比如論壇系統，用戶和論壇兩個模塊應該在垂直切分時被分在了兩個shard里，對于論壇模塊來說，Forum顯然是聚合根，因此按Forum進行水平切分，把Forum里所有的帖子和回帖都隨Forum放在一個shard里是很自然的。

????? 對于共享數據數據，如果是只讀的字典表，每個shard里維護一份應該是一個不錯的選擇，這樣不必打斷關聯關系。如果是一般數據間的跨節點的關聯，就必須打斷。

??????需要特別說明的是：當同時進行垂直和水平切分時，切分策略會發生一些微妙的變化。比如：在只考慮垂直切分的時候，被劃分到一起的表之間可以保持任意的關聯關系，因此你可以按“功能模塊”劃分表格，但是一旦引入水平切分之后，表間關聯關系就會受到很大的制約，通常只能允許一個主表（以該表ID進行散列的表）和其多個次表之間保留關聯關系，也就是說：當同時進行垂直和水平切分時，在垂直方向上的切分將不再以“功能模塊”進行劃分，而是需要更加細粒度的垂直切分，而這個粒度與領域驅動設計中的“聚合”概念不謀而合，甚至可以說是完全一致，每個shard的主表正是一個聚合中的聚合根！這樣切分下來你會發現數據庫分被切分地過于分散了（shard的數量會比較多，但是shard里的表卻不多），為了避免管理過多的數據源，充分利用每一個數據庫服務器的資源，可以考慮將業務上相近，并且具有相近數據增長速率（主表數據量在同一數量級上）的兩個或多個shard放到同一個數據源里，每個shard依然是獨立的，它們有各自的主表，并使用各自主表ID進行散列，不同的只是它們的散列取模（即節點數量）必需是一致的。（

本文著重介紹sharding的基本思想和理論上的切分策略，關于更加細致的實施策略和參考事例請參考我的另一篇博文：數據庫分庫分表(sharding)系列(一) 拆分實施策略和示例演示?

）

1.事務問題：
解決事務問題目前有兩種可行的方案：分布式事務和通過應用程序與數據庫共同控制實現事務下面對兩套方案進行一個簡單的對比。
方案一：使用分布式事務
??? 優點：交由數據庫管理，簡單有效
??? 缺點：性能代價高，特別是shard越來越多時
方案二：由應用程序和數據庫共同控制
???? 原理：將一個跨多個數據庫的分布式事務分拆成多個僅處
?????????? 于單個數據庫上面的小事務，并通過應用程序來總控
?????????? 各個小事務。
???? 優點：性能上有優勢
???? 缺點：需要應用程序在事務控制上做靈活設計。如果使用???
?????????? 了spring的事務管理，改動起來會面臨一定的困難。
2.跨節點Join的問題
????? 只要是時行切分，跨節點Join的問明是不可避免的。但是良好的設計和切分卻可以減少此類情況的發生。解決這一問題的普遍做法是分兩次查詢實現。在第一次查詢的結果集中找出關聯數據的id,根據這些id發起第二次請求得到關聯數據。

3.跨節點的count,order by,group by以及聚合函數問題
????? 這些是一類問題，因為它們都需要基于全部數據集合進行計算。多數的代理都不會自動處理合并工作。解決方案：與解決跨節點join問題的類似，分別在各個節點上得到結果后在應用程序端進行合并。和join不同的是每個結點的查詢可以并行執行，因此很多時候它的速度要比單一大表快很多。但如果結果集很大，對應用程序內存的消耗是一個問題。

參考資料：

《MySQL性能調優與架構設計》

注：本文圖片摘自《MySQL性能調優與架構設計》一 書

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的数据库的拆分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。