資料庫Sharding的基本思想和切分策略

本文著重介紹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進行雜湊，不同的只是它們的雜湊取模（即節點數量）必需是一致的。（

）1.事務問題：

解決事務問題目前有兩種可行的方案：分布式事務和通過應用程式與資料庫共同控制實現事務下面對兩套方案進行乙個簡單的對比。

方案一：使用分布式事務

優點：交由資料庫管理，簡單有效

缺點：效能代價高，特別是shard越來越多時

方案二：由應用程式和資料庫共同控制

原理：將乙個跨多個資料庫的分布式事務分拆成多個僅處

於單個資料庫上面的小事務，並通過應用程式來總控

各個小事務。

優點：效能上有優勢

缺點：需要應用程式在事務控制上做靈活設計。如果使用

了spring的事務管理，改動起來會面臨一定的困難。

2.跨節點join的問題

只要是時行切分，跨節點join的問明是不可避免的。但是良好的設計和切分卻可以減少此類情況的發生。解決這一問題的普遍做法是分兩次查詢實現。在第一次查詢的結果集中找出關聯資料的id,根據這些id發起第二次請求得到關聯資料。

3.跨節點的count,order by,group by以及聚合函式問題

這些是一類問題，因為它們都需要基於全部資料集合進行計算。多數的**都不會自動處理合併工作。解決方案：與解決跨節點join問題的類似，分別在各個節點上得到結果後在應用程式端進行合併。和join不同的是每個結點的查詢可以並行執行，因此很多時候它的速度要比單一大表快很多。但如果結果集很大，對應用程式記憶體的消耗是乙個問題。

資料庫Sharding的基本思想和切分策略

資料庫Sharding的基本思想和切分策略

資料庫Sharding的基本思想和切分策略

資料庫Sharding的基本思想和切分策略

相關推薦