從 Shard 到 Sharding
"Shard" 這個詞英文的意思是"碎片"，而作為數據庫相關的技術用語，似乎最早見於大型多人在線角色扮演游戲(MMORPG)中。"Sharding" 姑且稱之為"分片"。
Sharding 不是一門新技術，而是一個相對簡樸的軟件理念。如您所知，MySQL 5 之後才有了數據表分區功能，那麼在此之前，很多 MySQL 的潛在用戶都對 MySQL 的擴展性有所顧慮，而是否具備分區功能就成了衡量一個數據庫可擴展性與否的一個關鍵指標(當然不是唯一指標)。數據庫擴展性是一個永恆的話題，MySQL 的推廣者經常會被問到：如在單一數據庫上處理應用數據捉襟見肘而需要進行分區化之類的處理，是如何辦到的呢? 答案是：Sharding。
Sharding 不是一個某個特定數據庫軟件附屬的功能，而是在具體技術細節之上的抽象處理，是水平擴展(Scale Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是為突破單節點數據庫服務器的 I/O 能力限制，解決數據庫擴展性問題。
事關數據庫擴展性
說起數據庫擴展性，這是個非常大的話題。目前的商業數據都有自己的擴展性解決方案，在過去相對來說比較成熟，但是隨著互聯網的高速發展，不可避免的會帶來一些計算模式上的演變，這樣很多主流商業系統也難免暴露出一些不足之處。比如 Oracle 的 RAC 是采用共享存儲機制，對於 I/O 密集型的應用，瓶頸很容易落在存儲上，這樣的機制決定後續擴容只能是 Scale Up(向上擴展) 類型，對於硬件成本、開發人員的要求、維護成本都相對比較高。
Sharding 基本上是針對開源數據庫的擴展性解決方案，很少有聽說商業數據庫進行 Sharding 的。目前業界的趨勢基本上是擁抱 Scale Out，逐漸從 Scale Up 中解放出來。
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 是能夠跨數據庫，甚至跨越物理機器的。(見對比表格)
Sharding 策略
數據 Sharding 的策略與分區表的方式有很多類似的地方，有基於表、ID 范圍、數據產生的時間或是SOA 下理念下的基於服務等眾多方式可選擇。而與傳統的表分區方式不同的是，Sharding 策略和業務結合的更為緊密，成功的 Sharding 必須對自己的業務足夠熟悉，進行眾多可行性分析的基礎上進行，"業務邏輯驅動"。
Sharding 實現案例分析：Digg 網站
作為風頭正勁的 Web 2.0 網站之一的 Digg.com，雖然用戶群龐大，但網站數據庫數據並非海量，去年同期主數據大約只有 30GB 的樣子，現在應該更大一些，但應該不會出現數量級上增長，數據庫軟件采用 MySQL 5.x。Digg.com的 IO 壓力非常大，而且是讀集中的應用(98%的 IO 是讀請求)。因為提供的是新聞類服務，這類數據有其自身特點，最近時間段的數據往往是讀壓力最大的部分。
根據業務特點，Digg.com 根據時間范圍對主要的業務數據做 Sharding，把不到 10% 的"熱"數據有效隔離開來，同時對這部分數據用以更好的硬件，提供更好的用戶體驗。而另外 90% 的數據因用戶很少訪問，所以盡管訪問速度稍慢一點，對用戶來說，影響也很小。通過 Sharding，Digg 達到了預期效果。
現有的 Sharding 軟件簡介
現在 Sharding 相關的軟件實現其實不少，基於數據庫層、DAO 層、不同語言下也都不乏案例。限於篇幅，作一下簡要的介紹。
MySQL Proxy + HSCALE
一套比較有潛力的方案。其中 MySQL Proxy (http://forge.mysql.com/wiki/MySQL_Proxy) 是用 Lua 腳本實現的，介於客戶端與服務器端之間，扮演 Proxy 的角色，提供查詢分析、失敗接管、查詢過濾、調整等功能。目前的 0.6 版本還做不到讀、寫分離。HSCALE 則是針對 MySQL Proxy 插件，也是用 Lua 實現的，對 Sharding 過程簡化了許多。需要指出的是，MySQL Proxy 與 HSCALE 各自會帶來一定的開銷，但這個開銷與集中式數據處理方式單條查詢的開銷還是要小的。
Hibernate Shards
這是 Google 技術團隊貢獻的項目(http://www.hibernate.org/414.Html)，該項目是在對 Google 財務系統數據 Sharding 過程中誕生的。因為是在框架層實現的，所以有其獨特的特性：標准的 Hibernate 編程模型，會用 Hibernate 就能搞定，技術成本較低;相對彈性的 Sharding 策略以及支持虛擬 Shard 等。
Spock Proxy
這也是在實際需求中產生的一個開源項目。Spock(http://www.spock.com/)是一個人員查找的 Web 2.0 網站。通過對自己的單一 DB 進行有效 Sharding化 而產生了Spock Proxy(http://spockproxy.sourceforge.Net/ ) 項目，Spock Proxy 算得上 MySQL Proxy 的一個分支，提供基於范圍的 Sharding 機制。Spock 是基於 Rails 的，所以Spock Proxy 也是基於 Rails 構建，關注 RoR 的朋友不應錯過這個項目。
HiveDB
上面介紹了 RoR 的實現，HiveDB (http://www.hivedb.org/)則是基於Java 的實現，另外，稍有不同的是，這個項目背後有商業公司支持。
PL/Proxy
前面幾個都是針對 MySQL 的 Sharding 方案，PL/Proxy 則是針對 PostgreSQL 的，設計思想類似 Teradata 的 Hash 機制，數據存儲對客戶端是透明的，客戶請求發送到 PL/Proxy 後，由這裡分布式存儲過程調用，統一分發。 PL/Proxy 的設計初衷就是在這一層充當"數據總線"的職責，所以，當數據吞吐量支撐不住的時候，只需要增加更多的 PL/Proxy 服務器即可。大名鼎鼎的 Skype 用的就是 PL/Proxy 的解決方案。
Pyshards
http://code.google.com/p/pyshards/wiki/Pyshards 這是個基於 Python的解決方案。該工具的設計目標還有個 Re-balancing 在裡面，這倒是個比較激進的想法。目前只支持 MySQL 數據庫。
結束語
Sharding 是一項仍處於高速發展中的"老"技術，隨著 Web 2.0 的發展，Sahrding逐漸從比較"虛"的概念變成比較"實"的運用思路，開放源代碼軟件大潮也給 Sharding 注入新的活力，相信會有越來越多的項目采用 Sharding 技術，也會有更多成熟的 Sharding 方案和數據庫附加軟件湧現。
你的站點 Sharding 了麼?
--EOF--
另，本周末我講參加這個活動：體驗基於OpenSolaris的Web/企業應用，做一個題為《設計可擴展的面向互聯網應用的MySQL數據庫》的簡單分享。歡迎杭州朋友光臨指導。
