sharding的優點 更高的可用性.即避免單點失效.
更快的查詢:每個數據組中更少的數據意味著更快的查詢.
更大的寫入帶寬: 不需要對master資料庫進行串列寫操作,可并行寫入提高吞吐量.
負載平衡: 并行的後端意味著你可以同時做更多的工作.你可以處理更多的用戶負荷,尤其是寫入數據時,因為有并行的用戶貫穿你的系統,你可以對web伺服器進行負載平衡,它通過不同的網路路徑訪問shard,這些不同的路徑由彼此分離的多個CPU處理,這些CPU使用分離的RAM緩存和分離的磁碟IO路徑來進行工作.
從 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 的解決方案.
