Sharding簡介
定義
事關資料庫擴展性 說起資料庫擴展性，這是個非常大的話題。目前的商業數據都有自己的擴展性解決方案，在過去相對來說比較成熟，但是隨著網際網路的高速發展，不可避免的會帶來一些計算模式上的演變，這樣很多主流商業系統也難免暴露出一些不足之處。比如 Oracle 的 RAC 是採用共享存儲機制，對於I/O 密集型的套用，瓶頸很容易落在存儲上，這樣的機制決定後續擴容只能是 Scale Up（向上擴展） 類型，對於硬體成本、開發人員的要求、維護成本都相對比較高 。
用途
Sharding 基本上是針對開源資料庫的擴展性解決方案，很少有聽說商業資料庫進行 Sharding 的。目前業界的趨勢基本上是擁抱Scale Out，逐漸從 Scale Up 中解放出來。
解釋
分片（sharding）的核心理念基於一個想法：資料庫大小以及資料庫上每單元時間內的交易數呈線型增長，查詢資料庫的回響時間（response time）以指數方式增長。
另外，在一個地方創建和維護一個大型資料庫的成本會成指數增長，因為資料庫將需要高端的計算機。相反地，數據碎片可以分布到大量便宜得多的商用伺服器上。就硬體和軟體要求而言，數據碎片相對來說沒什麼限制。
在某些情況中，資料庫分片（sharding）可以很簡單地完成。按地理位置拆分用戶資料庫就是一個常見的例子。位於東海岸的用戶被分到一台伺服器上，在西海岸的用戶被分在另一台伺服器上。假設沒有用戶有多個地理位置，這種分區很易於維護和創建規則。
但是數據分片（sharding）在某些情況下會是更為複雜的過程。例如，一個資料庫持有很少結構化數據，分片它就可能非常複雜，並且結果碎片可能會很難維護。
Sharding 的套用場景
概述
任何技術都是在合適的場合下能發揮應有的作用。 Sharding 也一樣。在線上遊戲、IM、BSP 都是比較適合 Sharding 的套用場景。其共性是抽象出來的數據對象之間的關聯數據很小。比如IM ，每個用戶如果抽象成一個數據對象，完全可以獨立存儲在任何一個地方，數據對象是 Share Nothing 的；再比如 Blog 服務提供商的站點內容，基本為用戶生成內容(UGC)，完全可以把不同的用戶隔離到不同的存儲集合，而對用戶來說是透明的。
簡介
這個"Share Nothing" 是從資料庫集群中借用的概念，舉例來說，有些類型的數據粒度之間就不是 "Share Nothing" 的，比如類似交易記錄的歷史表信息，如果一條記錄中既包含賣家信息與買家信息，如果隨著時間推移，買、賣家會分別與其它用戶繼續進行交易，這樣不可避免的兩個買賣家的信息會分布到不同的 Sharding DB 上，而這時如果針對買賣家查詢，就會跨越更多的 Sharding ，開銷就會比較大。
Sharding 並不是資料庫擴展方案的銀彈，也有其不適合的場景，比如處理事務型的套用就會非常複雜。對於跨不同DB的事務，很難保證完整性，得不償失。所以，採用什麼樣的 Sharding 形式，不是生搬硬套的。
Sharding與資料庫分區(Partition)的區別
有的時候，Sharding 也被近似等同於水平分區(Horizontal Partitioning)，網上很多地方也用水平分區來指代 Sharding，但我個人認為二者之間實際上還是有區別的。的確，Sharding 的思想是從分區的思想而來，但資料庫分區基本上是數據對象級別的處理，比如表和索引的分區，每個子數據集上能夠有不同的物理存儲屬性，還是單個資料庫範圍內的操作，而 Sharding 是能夠跨資料庫，甚至跨越物理機器的。
