DB分庫分表的基本思想和切分策略是怎樣的

DB分庫分表的基本思想和切分策略是怎樣的，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

一、基本思想

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不同的是每個結點的查詢可以并行執行，因此很多時候它的速度要比單一大表快很多。但如果結果集很大，對應用程序內存的消耗是一個問題。

關于垂直切分Vertical Sharding的粒度

垂直切分的粒度指的是在做垂直切分時允許幾級的關聯表放在一個shard里.這個問題對應用程序和sharding實現有著很大的影響.

關聯打斷地越多，則受影響的join操作越多，應用程序為此做出的妥協就越大，但單表的路由會越簡單，與業務的關聯性會越小，就越容易使用統一機制處理.在此方向上的極端方案是：打斷所有連接，每張表都配有路由規則，可以使用統一機制或框架自動處理.比如amoeba這樣的框架，它的路由能且僅能通過SQL的特征(比如某個表的id)進行路由.

反之，若關聯打斷地越少，則join操作的受到的限制就小，應用程序需要做出的妥協就越小，但是表的路由就會變復雜，與業務的關聯性就越大，就越難使用統一機制處理，需要針對每個數據請求單獨實現路由.在此方向上的極端方案是：所有表都在一個shard里，也就是沒有垂直切分，這樣就沒有關聯被打斷.當然這是非常極端的，除非整個數據庫很簡單，表的數量很少.

實際的粒度掌控需要結合“業務緊密程度”和“表格數據量”兩個因素綜合考慮，一般來說：

• 若劃歸到一起的表格關系緊密，且數據量并不大，增速也非常緩慢，則適宜放在一個shard里，不需要再進行水平切分;

• 若劃歸到一起的表格數據量巨大且增速迅猛，則勢必要在垂直切分的基礎上再進行水平切分，水平切分就意味著原單一shard會被細分成多個更小的shard，每一個shard存在一個主表(即會以該表ID進行散列的表)和多個相之相關的關聯表。

總之，垂直切分的粒度在兩個相反的方向上呈現優勢與劣勢并存并相互博弈的局面.架構師需要做的是結合項目的實際情況在兩者之間取得收益化的平衡.

看完上述內容，你們掌握DB分庫分表的基本思想和切分策略是怎樣的的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！