Sharding

事關數據庫擴展性　説起數據庫擴展性，這是個非常大的話題。目前的商業數據都有自己的擴展性解決方案，在過去相對來説比較成熟，但是隨着互聯網的高速發展，不可避免的會帶來一些計算模式上的演變，這樣很多主流商業系統也難免暴露出一些不足之處。比如 Oracle 的 RAC 是採用共享存儲機制，對於I/O 密集型的應用，瓶頸很容易落在存儲上，這樣的機制決定後續擴容只能是 Scale Up（向上擴展） 類型，對於硬件成本、開發人員的要求、維護成本都相對比較高。

Sharding 基本上是針對開源數據庫的擴展性解決方案，很少有聽説商業數據庫進行 Sharding 的。目前業界的趨勢基本上是擁抱Scale Out，逐漸從 Scale Up 中解放出來。

分片（sharding）的核心理念基於一個想法：數據庫大小以及數據庫上每單元時間內的交易數呈線型增長，查詢數據庫的響應時間（response time）以指數方式增長。

另外，在一個地方創建和維護一個大型數據庫的成本會成指數增長，因為數據庫將需要高端的計算機。相反地，數據碎片可以分佈到大量便宜得多的商用服務器上。就硬件和軟件要求而言，數據碎片相對來説沒什麼限制。

在某些情況中，數據庫分片（sharding）可以很簡單地完成。按地理位置拆分用户數據庫就是一個常見的例子。位於東海岸的用户被分到一台服務器上，在西海岸的用户被分在另一台服務器上。假設沒有用户有多個地理位置，這種分區很易於維護和創建規則。

但是數據分片（sharding）在某些情況下會是更為複雜的過程。例如，一個數據庫持有很少結構化數據，分片它就可能非常複雜，並且結果碎片可能會很難維護。 ^[1] 

任何技術都是在合適的場合下能發揮應有的作用。 Sharding 也一樣。聯機遊戲、IM、BSP 都是比較適合 Sharding 的應用場景。其共性是抽象出來的數據對象之間的關聯數據很小。比如IM ，每個用户如果抽象成一個數據對象，完全可以獨立存儲在任何一個地方，數據對象是 Share Nothing 的；再比如 Blog 服務提供商的站點內容，基本為用户生成內容(UGC)，完全可以把不同的用户隔離到不同的存儲集合，而對用户來説是透明的。

這個"Share Nothing" 是從數據庫集羣中借用的概念，舉例來説，有些類型的數據粒度之間就不是 "Share Nothing" 的，比如類似交易記錄的歷史表信息，如果一條記錄中既包含賣家信息與買家信息，如果隨着時間推移，買、賣家會分別與其它用户繼續進行交易，這樣不可避免的兩個買賣家的信息會分佈到不同的 Sharding DB 上，而這時如果針對買賣家查詢，就會跨越更多的 Sharding ，開銷就會比較大。

Sharding 並不是數據庫擴展方案的銀彈，也有其不適合的場景，比如處理事務型的應用就會非常複雜。對於跨不同DB的事務，很難保證完整性，得不償失。所以，採用什麼樣的 Sharding 形式，不是生搬硬套的。

有的時候，Sharding 也被近似等同於水平分區(Horizontal Partitioning)，網上很多地方也用水平分區來指代 Sharding，但我個人認為二者之間實際上還是有區別的。的確，Sharding 的思想是從分區的思想而來，但數據庫分區基本上是數據對象級別的處理，比如表和索引的分區，每個子數據集上能夠有不同的物理存儲屬性，還是單個數據庫範圍內的操作，而 Sharding 是能夠跨數據庫，甚至跨越物理機器的。