Sharding 策略
數據 Sharding 的策略與分區表的方式有很多類似的地方有基於表ID 范圍數據產生的時間或是SOA理念下的基於服務等眾多方式可選擇而與傳統的表分區方式不同的是Sharding 策略和業務結合的更為緊密成功的 Sharding 必須對自己的業務足夠熟悉進行眾多可行性分析的基礎上進行業務邏輯驅動
Sharding 實現案例分析Digg 網站
作為風頭正勁的 Web 網站之一的 Diggcom雖然用戶群龐大但網站數據庫數據並非海量去年同期主數據大約只有 GB 的樣子現在應該更大一些但應該不會出現數量級上增長數據庫軟件采用 MySQL xDiggcom的 IO 壓力非常大而且是讀集中的應用(%的 IO 是讀請求)因為提供的是新聞類服務這類數據有其自身特點最近時間段的數據往往是讀壓力最大的部分
根據業務特點Diggcom 根據時間范圍對主要的業務數據做 Sharding把不到 % 的熱數據有效隔離開來同時對這部分數據用以更好的硬件提供更好的用戶體驗而另外 % 的數據因用戶很少訪問所以盡管訪問速度稍慢一點對用戶來說影響也很小通過 ShardingDigg 達到了預期效果
現有的Sharding 軟件簡介
現在 Sharding 相關的軟件實現其實不少基於數據庫層DAO 層不同語言下也都不乏案例限於篇幅作一下簡要的介紹
MySQL Proxy + HSCALE
一套比較有潛力的方案其中 MySQL Proxy (http://forgemysqlcom/wiki/MySQL_Proxy) 是用 Lua 腳本實現的介於客戶端與服務器端之間扮演 Proxy 的角色提供查詢分析失敗接管查詢過濾調整等功能目前的 版本還做不到讀寫分離HSCALE 則是針對 MySQL Proxy 插件也是用 Lua 實現的對 Sharding 過程簡化了許多需要指出的是MySQL Proxy 與 HSCALE 各自會帶來一定的開銷但這個開銷與集中式數據處理方式單條查詢的開銷還是要小的
Hibernate Shards
這是 Google 技術團隊貢獻的項目（http://wwwhibernateorg/html）該項目是在對 Google 財務系統數據 Sharding 過程中誕生的因為是在框架層實現的所以有其獨特的特性標准的 Hibernate 編程模型會用 Hibernate 就能搞定技術成本較低相對彈性的 Sharding 策略以及支持虛擬 Shard 等
Spock Proxy
這也是在實際需求中產生的一個開源項目Spock（http://wwwspockcom/）是一個人員查找的 Web 網站通過對自己的單一 DB 進行有效 Sharding化 而產生了Spock Proxy(http://spockproxysourceforgenet/ ) 項目Spock Proxy 算得上 MySQL Proxy 的一個分支提供基於范圍的 Sharding 機制Spock 是基於 Rails 的所以Spock Proxy 也是基於 Rails 構建關注 RoR 的朋友不應錯過這個項目
HiveDB
上面介紹了 RoR 的實現HiveDB (http://wwwhivedborg/)則是基於Java 的實現另外稍有不同的是這個項目背後有商業公司支持
PL/Proxy
前面幾個都是針對 MySQL 的 Sharding 方案PL/Proxy 則是針對 PostgreSQL 的設計思想類似 Teradata 的 Hash 機制數據存儲對客戶端是透明的客戶請求發送到 PL/Proxy 後由這裡分布式存儲過程調用統一分發 PL/Proxy 的設計初衷就是在這一層充當數據總線的職責所以當數據吞吐量支撐不住的時候只需要增加更多的 PL/Proxy 服務器即可大名鼎鼎的 Skype 用的就是 PL/Proxy 的解決方案
[] []
From:http://tw.wingwit.com/Article/program/SQL/201311/16327.html
