開來源資料庫 Sharding 技術 (Share Nothing)

標籤：blog   http   java   os   strong   io   資料   for   

原文地址

從 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 ，每個使用者如果抽象成一個資料對象，完全可以隔離儲存區 (Isolated Storage)在任何一個地方，資料對象是 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 了麼?