一：基本思想
sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫(server)上，從而緩解單一資料庫的效能問題。不太嚴格的講，對於海量資料的資料庫，如果是因為表多而資料多，這時候適合使用垂直切分，即把關係緊密（比如同一模組）的表切分出來放在乙個server上。如果表並不多，但每張表的資料非常多，這時候適合水平切分，即把表的資料按某種規則（比如按id雜湊）切分到多個資料庫(server)上。當然，現實中更多是這兩種情況混雜在一起，這時候需要根據實際情況做出選擇，也可能會綜合使用垂直與水平切分，從而將原有資料庫切分成類似矩陣一樣可以無限擴充的資料庫(server)陣列。下面分別詳細地介紹一下垂直切分和水平切分.
垂直切分的最大特點就是規則簡單，實施也更為方便，尤其適合各業務之間的耦合度非常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業務模組所使用的表分拆到不同的資料庫中。根據不同的表來進行拆分，對應用程式的影響也更小，拆分規則也會比較簡單清晰。（這也就是所謂的」share nothing」）。
讓我們從普遍的情況來考慮資料的切分：一方面，乙個庫的所有表通常不可能由某一張表全部串聯起來，這句話暗含的意思是，水平切分幾乎都是針對一小搓一小搓（實際上就是垂直切分出來的塊）關係緊密的表進行的，而不可能是針對所有表進行的。另一方面，一些負載非常高的系統，即使僅僅只是單個表都無法通過單台資料庫主機來承擔其負載，這意味著單單是垂直切分也不能完全解決問明。因此多數系統會將垂直切分和水平切分聯合使用，先對系統做垂直切分，再針對每一小搓表的情況選擇性地做水平切分。從而將整個資料庫切分成乙個分布式矩陣。
二、切分策略
如前面所提到的，切分是按先垂直切分再水平切分的步驟進行的。垂直切分的結果正好為水平切分做好了鋪墊。垂直切分的思路就是分析表間的聚合關係，把關係緊密的表放在一起。多數情況下可能是同乙個模組，或者是同一「聚集」。這裡的「聚集」正是領域驅動設計裡所說的聚集。在垂直切分出的表聚集內，找出「根元素」（這裡的「根元素」就是領域驅動設計裡的「聚合根」），按「根元素」進行水平切分，也就是從「根元素」開始，把所有和它直接與間接關聯的資料放入乙個shard裡。這樣出現跨shard關聯的可能性就非常的小。應用程式就不必打斷既有的表間關聯。比如：對於社交**，幾乎所有資料最終都會關聯到某個使用者上，基於使用者進行切分就是最好的選擇。再比如論壇系統，使用者和論壇兩個模組應該在垂直切分時被分在了兩個shard裡，對於論壇模組來說，forum顯然是聚合根，因此按forum進行水平切分，把forum裡所有的帖子和回帖都隨forum放在乙個shard裡是很自然的。
對於共享資料資料，如果是唯讀的字典表，每個shard裡維護乙份應該是乙個不錯的選擇，這樣不必打斷關聯關係。如果是一般資料間的跨節點的關聯，就必須打斷。
兩個或多個shard放到同乙個資料來源裡，每個shard依然是獨立的，它們有各自的主表，並使用各自主表id進行雜湊，不同的只是它們的雜湊取模（即節點數量）必需是一致的。（
本文著重介紹sharding的基本思想和理論上的切分策略，關於更加細緻的實施策略和參考事例請參考我的另一篇博文：資料庫分庫分表(sharding)系列(一) 拆分實施策略和示例演示
資料庫Sharding的基本思想和切分策略
一 基本思想 sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫 server 上，從而緩解單一資料庫的效能問題。不太嚴格的講，對於海量資料的資料庫，如果是因為表多而資料多，這時候適合使用垂直切分，即把關係緊密 比如同一模組 的表切分出來放在乙個server上。如果表並不多，但...
資料庫Sharding的基本思想和切分策略
本文著重介紹sharding的基本思想和理論上的切分策略，關於更加細緻的實施策略和參考事例請參考我的另一篇博文 資料庫分庫分表 sharding 系列 一 拆分實施策略和示例演示 一 基本思想 sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫 server 上，從而緩解單一資...
資料庫Sharding的基本思想和切分策略
本文著重介紹sharding的基本思想和理論上的切分策略，關於更加細緻的實施策略和參考事例請參考我的另一篇博文 資料庫分庫分表 sharding 系列 一 拆分實施策略和示例演示 一 基本思想 sharding的基本思想就要把乙個資料庫切分成多個部分放到不同的資料庫 server 上，從而緩解單一資...