**：
本文著重介紹sharding的基本思想和理論上的切分策略。關於更加仔細的實施策略和參考事例請參考我的還有一篇博文：資料庫分庫分表(sharding)系列(一)
拆分實施策略和演示樣例演示
一、基本思想
sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫(server)上，從而緩解單一資料庫的效能問題。
不太嚴格的講。對於海量資料的資料庫，假設是由於表多而資料多，這時候適合使用垂直切分，即把關係緊密（比方同一模組）的表切分出來放在乙個server上。假設表並不多。但每張表的資料很多。這時候適合水平切分，即把表的資料按某種規則（比方按id雜湊）切分到多個資料庫(server)上。
當然。現實中很多其它是這兩種情況混雜在一起，這時候須要依據實際情況做出選擇。也可能會綜合使用垂直與水平切分。從而將原有資料庫切分成類似矩陣一樣能夠無限擴充的資料庫(server)陣列。以下分別具體地介紹一下垂直切分和水平切分.
垂直切分的最大特點就是規則簡單，實施也更為方便，尤其適合各業務之間的耦合度非
常低，相互影響非常小，業務邏輯非常清晰的系統。在這樣的系統中，能夠非常easy做到將不同業
務模組所使用的表分拆到不同的資料庫中。依據不同的表來進行拆分，相應用程式的影響也
更小。拆分規則也會比較簡單清晰。（這也就是所謂的」share nothing」）。
水平切分於垂直切分相比，相對來說略微複雜一些。由於要將同乙個表中的不同資料拆
分到不同的資料庫中，對於應用程式來說，拆分規則本身就較依據表名來拆分更為複雜。後
期的資料維護也會更為複雜一些。
讓我們從普遍的情況來考慮資料的切分：一方面，乙個庫的全部表通常不可能由某一張表全部串聯起來，這句話暗含的意思是，水平切分差點兒都是針對一小搓一小搓（實際上就是垂直切分出來的塊）關係緊密的表進行的，而不可能是針對全部表進行的。還有一方面，一些負載很高的系統，即使只不過單個表都無法通過單台資料庫主機來承擔其負載，這意味著單單是垂直切分也不能全然解決問明。因此多數系統會將垂直切分和水平切分聯合使用，先對系統做垂直切分，再針對每一小搓表的情況選擇性地做水平切分。
從而將整個資料庫切分成乙個分布式矩陣。
二、切分策略
如前面所提到的，切分是按先垂直切分再水平切分的步驟進行的。垂直切分的結果正好為水平切分做好了鋪墊。垂直切分的思路就是分析表間的聚合關係，把關係緊密的表放在一起。
多數情況下可能是同乙個模組，或者是同一「聚集」。這裡的「聚集」正是領域驅動設計裡所說的聚集。
在垂直切分出的表聚集內，找出「根元素」（這裡的「根元素」就是領域驅動設計裡的「聚合根」），按「根元素」進行水平切分。也就是從「根元素」開始。把全部和它直接與間接關聯的資料放入乙個shard裡。
這樣出現跨shard關聯的可能性就非常的小。應用程式就不必打斷既有的表間關聯。比方：對於社交站點。差點兒全部資料終於都會關聯到某個使用者上，基於使用者進行切分就是最好的選擇。再比方論壇系統，使用者和論壇兩個模組應該在垂直切分時被分在了兩個shard裡，對於論壇模組來說，forum顯然是聚合根，因此按forum進行水平切分，把forum裡全部的帖子和回帖都隨forum放在乙個shard裡是非常自然的。
對於共享資料資料，假設是僅僅讀的字典表，每乙個shard裡維護乙份應該是乙個不錯的選擇。這樣不必打斷關聯關係。假設是一般資料間的跨節點的關聯，就必須打斷。
須要特別說明的是：當同一時候進行垂直和水平切分時。切分策略會發生一些微妙的變化。比方：在僅僅考慮垂直切分的時候，被劃分到一起的表之間能夠保持隨意的關聯關係，因此你能夠按「功能模組」劃分**，可是一旦引入水平切分之後，表間關聯關係就會受到非常大的制約，通常僅僅能同意乙個主表（以該錶id進行雜湊的表）和其多個次表之間保留關聯關係，也就是說：當同一時候進行垂直和水平切分時，在垂直方向上的切分將不再以「功能模組」進行劃分，而是須要更加細粒度的垂直切分，而這個粒度與領域驅動設計中的「聚合」概念不謀而合。甚至能夠說是全然一致，每乙個shard的主表正是乙個聚合中的聚合根！
這樣切分下來你會發現資料庫分被切分地過於分散了（shard的數量會比較多，可是shard裡的表卻不多），為了避免管理過多的資料來源，充分利用每乙個資料庫server的資源。能夠考慮將業務上相近，而且具有相近資料增長速率（主表資料量在同一數量級上）的兩個或多個shard放到同乙個資料來源裡。每乙個shard依舊是獨立的，它們有各自的主表。並使用各自主表id進行雜湊，不同的僅僅是它們的雜湊取模（即節點數量）必需是一致的。（
本文著重介紹sharding的基本思想和理論上的切分策略，關於更加仔細的實施策略和參考事例請參考我的還有一篇博文：資料庫分庫分表(sharding)系列(一) 拆分實施策略和演示樣例演示
）1.事務問題：
解決事務問題眼下有兩種可行的方案：分布式事務和通過應用程式與資料庫共同控制實現事務以下對兩套方案進行乙個簡單的對照。
方案一：使用分布式事務
長處：交由資料庫管理，簡單有效
缺點：效能代價高。特別是shard越來越多時
方案二：由應用程式和資料庫共同控制
原理：將乙個跨多個資料庫的分布式事務分拆成多個僅處
於單個資料庫上面的小事務，並通過應用程式來總控
各個小事務。
長處：效能上有優勢
缺點：須要應用程式在事務控制上做靈活設計。假設使用
了spring的事務管理，修改起來會面臨一定的困難。
2.跨節點join的問題
僅僅要是進行切分。跨節點join的問題是不可避免的。可是良好的設計和切分卻能夠降低此類情況的發生。
解決這一問題的普遍做法是分兩次查詢實現。在第一次查詢的結果集中找出關聯資料的id,依據這些id發起第二次請求得到關聯資料。
3.跨節點的count,order by,group by以及聚合函式問題
這些是一類問題，由於它們都須要基於所有資料集合進行計算。多數的**都不會自己主動處理合併工作。解決方式：與解決跨節點join問題的類似。分別在各個節點上得到結果後在應用程式端進行合併。
和join不同的是每乙個結點的查詢能夠並行執行。因此非常多時候它的速度要比單一大表快非常多。
但假設結果集非常大，相應用程式記憶體的消耗是乙個問題。
參考資料：
《mysql效能調優與架構設計》
注：本文摘自《mysql效能調優與架構設計》一 書
資料庫Sharding的基本思想和切分策略
一 基本思想 sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫 server 上，從而緩解單一資料庫的效能問題。不太嚴格的講，對於海量資料的資料庫，如果是因為表多而資料多，這時候適合使用垂直切分，即把關係緊密 比如同一模組 的表切分出來放在乙個server上。如果表並不多，但...
資料庫Sharding的基本思想和切分策略
本文著重介紹sharding的基本思想和理論上的切分策略，關於更加細緻的實施策略和參考事例請參考我的另一篇博文 資料庫分庫分表 sharding 系列 一 拆分實施策略和示例演示 一 基本思想 sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫 server 上，從而緩解單一資...
資料庫Sharding的基本思想和切分策略
本文著重介紹sharding的基本思想和理論上的切分策略，關於更加細緻的實施策略和參考事例請參考我的另一篇博文 資料庫分庫分表 sharding 系列 一 拆分實施策略和示例演示 一 基本思想 sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫 server 上，從而緩解單一資...