垂直切分Vertical Sharding的粒度

關于垂直切分Vertical Sharding的粒度

本文大部分參考bluishglc的部落格。

垂直切分的粒度指的是在做垂直切分時允許幾級的關聯表放在一個shard裡．這個問題對應用程式和sharding實作有着很大的影響．

關聯打斷地越多，則受影響的join操作越多，（因為資料在不同的shard裡面，要使用join，order，groupby的前提是資料能merge到一起，進行統一的處理。但現在資料是被劃分到了不同的shard裡面，針對資料做了切分的table，是不能直接在SQL中使用join，order，groupby，必須在邏輯中處理此類操作）應用程式為此做出的妥協就越大，但單表的路由會越簡單，與業務的關聯性會越小，就越容易使用統一機制處理．在此方向上的極端方案是：打斷所有連接配接，每張表都配有路由規則，可以使用統一機制或架構自動處理．比如amoeba這樣的架構，它的路由能且僅能通過SQL的特征（比如某個表的id）進行路由．

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

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

若劃歸到一起的表格關系緊密，且資料量并不大，增速也非常緩慢，則适宜放在一個shard裡，不需要再進行水準切分;

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

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