數據 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 的解決方案。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
