小議資料庫橫向切分

橫向切分

Database Sharding，有的叫拆分，有的叫切片，還有的叫分區，不管了，都是一個意思。我採用切分的叫法，因為這更接近於應用的思維。

 

在資料庫層對資料進行橫向切分（Horizantal Sharding），這在NoSQL（如MongoDB,CouchDB,SimpleDB）中已經實現，微軟要在SQL Azure中實現，此前是通過ADO.net實現的。

 

橫向切分，縮短了索引的長度，同時也帶來了insert/update/delete的速度提升。行切片的基準大多是日期，通過將“舊”的資料從物理上移開，既最佳化了儲存，也給索引瘦了身。從架構上也避免了資料的無線增長，可以保持資料一直處於一個“適中”的狀態。

 

橫向切分（也叫行切分）的策略，在NoSQL中給了實現，但是在RDBMS中實現它並非易事。因為切分一般都是基於資料庫群集來做的，傳統資料庫顯然從架構上更獨立，切分策略只能適用於多台資料庫執行個體才能擷取想要的效率，而NoSQL也是因為其本身提供了橫向擴充的架構。

 

橫向切分的策略有很多種，有的根據ID來模數切分，有的根據日期來切分，還有的根據映射表來提供更複雜的切分規則。

 

每一種橫向切分策略的選擇，都是基於具體的業務需要的，而不能有一絲一毫脫離於業務實際。按Jeffrey Zhao的觀點是，資料庫切分(Database Sharding)一旦使用，就沒有了後退的餘地了。即便成了杯具，也要將杯具進行到底的。

 

自動切分和手動切分

上面提到的MongoDB具有自動切分的特點，這種自動切分，給無線擴充帶來了一副美好的藍圖，從架構上是這樣的。但是也存在問題，那就是在擴充時容易導致磁碟片段和記憶體片段。而且多個sharding node的cpu資源和記憶體資源未必能夠得到很好的利用（http://blog.nosqlfan.com/html/841.html）。就目前的實踐來看，自動切分恐怕還沒有到足夠成熟的地步。可以有理由任務，在目前手動切分還是要優於自動切分的，除了自動切分還存在一些理論上的問題之外，還有一個性價比的問題。

 

切分原則

每一種切分策略，都會有一堆的細節問題需要考慮。切分要考慮如下幾點：

1） 是否解除了業務操作的瓶頸

2） 避免跨sharding node的資料關聯

3） 易於擴充sharding node

4） 充分利用sharding node的資源（CPU和Memory）

5） 避免在擴充時移動資料

 

第一點是最直接的出發點，沒有這一點，也就不會有接下來的三點。

第二點避免跨sharding node的關聯，在某種程度上也就是業務資料邊界，反映在RDBMS上就是外鍵約束。如果存在跨sharding node的資料關聯，那麼不但不能實現1）的目標，甚至會加重瓶頸，這就是要求要具體問題具體分析的原因。

第三點考慮了長期的增長性帶來的問題持續加重的問題，如果不能擴充，那麼現在的切分只是暫時的，權宜的，過了一段時間，這種架構上的調整又會遇到瓶頸，顯然這是不可接受的。

第四點是為了充分利用伺服器寶貴的資源，避免不必要的浪費，這個在任何時候都是需要考慮的問題之一。

第五點是避免因為擴充所帶來的資料變動，這個比較流行的做法是通過一致性雜湊演算法（Consistent Hash）來解決。一致性雜湊不僅僅解決避免資料移動的問題，還解決了一個sharding node的單點故障問題。不管有多少個節點，都能夠自動均勻地儲存，並提供冗餘儲存，防止單點故障。

 

那麼這些切分策略如何呢？

例如按ID模數切分，那ID是用int/bigint呢，還是uniqueidentifier呢，或是自訂的varchar呢？如果用int/bigint，是自增呢，還是採用ID generation呢？如果是自增，在擴充sharding node的時候，如何解決模的改變所帶來的問題呢？（一種以ID特徵為依據的資料分區（Sharding）策略）。

 

按照ID模數切分，一般是自動切分的需要。雖然它將所有當前的業務資料均勻儲存在多個sharding node上，但可以均衡每個節點的計算壓力。但是如果要按時間段來即時統計業務資料的話，那麼這種方式可能就是夢魘了。只能走資料採礦的路子了，基於slave節點在後台做資料分析。

 

如果按照時間段切分的話，那麼一段時間內所有的資料都儲存到一個節點之上，那麼一個sharding node只是使用了儲存，而沒有考慮其計算壓力，從負載平衡上來講，就浪費資源了。隨著時間的推移，需要定時擴充sharding node，因此也就不需要使用一致性雜湊那種美妙的模型了。但是在很多業務上，不可否認時間段對於業務資料來說是一種天然的切分標準。但是在解決因為訪問壓力帶來的瓶頸這一問題上，它並不能充分的利用切分帶來的負載平衡的效果。

 

如果切分的標準非常複雜，可能是基於多個欄位，那麼可能就需要一個映射表來存放規則及資料了。這個沒有相關的經驗。

 

總結

切分有風險，行動需謹慎。充分考察切分帶來的效果，以及可能遇到的問題。