關於垂直切分Vertical Sharding的粒度

關於垂直切分Vertical Sharding的粒度

2011-03-24 18:23  2381人閱讀  評論(1)  收藏  舉報

sharding thread join 框架 數據庫 sql

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

 

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

 

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

 

實際的粒度掌控須要結合「業務緊密程度」和「表格數據量」兩個因素綜合考慮，通常來講：

• 若劃歸到一塊兒的表格關係緊密，且數據量並不大，增速也很是緩慢，則適宜放在一個shard裏，不須要再進行水平切分;

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

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