今天看了“Database Sharding at Netlog, with MySQL and PHP”一文，和去年我們討論擴(kuò)展的思路很類似（不過(guò)這種分布式擴(kuò)展，計(jì)算，存儲(chǔ)的思路都很類似），但是這片文章的作者是在日益爆炸式增長(zhǎng)的用戶數(shù)據(jù)下實(shí)踐的分享，因此這里將文中的一些思想記錄下來(lái)分享一下。
Netlog擁有4000萬(wàn)活躍用戶，每個(gè)月有超過(guò)5000萬(wàn)的獨(dú)立用戶訪問(wèn)網(wǎng)站，每個(gè)月有5億多的PV。數(shù)據(jù)量應(yīng)該算是比較大的。作者是Jurriaan Persyn，他從一個(gè)開(kāi)發(fā)者角度而非DBA或者SA角度來(lái)談Netlog是如何通過(guò)數(shù)據(jù)切分來(lái)提高網(wǎng)站性能，橫向擴(kuò)展數(shù)據(jù)層的。原文在：http://www.jurriaanpersyn.com/archives/2009/02/12/database-sharding-at-netlog-with-mysql-and-php/
首先，還是先談到關(guān)于數(shù)據(jù)庫(kù)在數(shù)據(jù)日益龐大的情況下一個(gè)演變過(guò)程。
第一階段：讀寫同在一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器
第二階段：讀寫分離（可以解決讀寫比例均衡或者讀居多的情況，但是帶入了數(shù)據(jù)復(fù)制同步的問(wèn)題）
第三階段：部分?jǐn)?shù)據(jù)獨(dú)立部署結(jié)合讀寫分離。（部分?jǐn)?shù)據(jù)根據(jù)其業(yè)務(wù)獨(dú)立性情況，可以將所有的數(shù)據(jù)獨(dú)立存儲(chǔ)到數(shù)據(jù)庫(kù)服務(wù)器，分擔(dān)數(shù)據(jù)讀寫壓力，前提是要求數(shù)據(jù)具有較高的業(yè)務(wù)獨(dú)立性）
第四階段：數(shù)據(jù)分拆結(jié)合讀寫分離（三階段的增強(qiáng)）
第五階段：?jiǎn)栴}出現(xiàn)，分拆也無(wú)法解決數(shù)據(jù)爆炸性增長(zhǎng)，同時(shí)讀寫處于同等比例。
解決問(wèn)題兩種方式：DB Scale up ，DB Scale out。前者投入以及后期擴(kuò)展有限，因此需要進(jìn)行數(shù)據(jù)切分。
上圖就是將photo的數(shù)據(jù)切分到了10臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上。
切分?jǐn)?shù)據(jù)的兩個(gè)關(guān)鍵點(diǎn)：
1． 如何根據(jù)存儲(chǔ)的數(shù)據(jù)內(nèi)容判斷數(shù)據(jù)的存儲(chǔ)歸屬，也就是什么是內(nèi)容的分區(qū)主鍵。
2． 采用什么算法可以根據(jù)不同的主鍵將內(nèi)容存儲(chǔ)到不同的分區(qū)中。
分區(qū)主鍵的選擇還是要根據(jù)自身的業(yè)務(wù)場(chǎng)景來(lái)決定，Netblog選擇的是用戶ID。
采用什么方式將分區(qū)主鍵映射到對(duì)應(yīng)的分區(qū)可以通過(guò)以下四種方式：
1． 根據(jù)數(shù)據(jù)表來(lái)切分。（前提就是數(shù)據(jù)獨(dú)立性較強(qiáng)，和前面提到的三階段類似）
2． 基于內(nèi)容區(qū)間范圍的分區(qū)。（就好比前1000個(gè)用戶的信息存儲(chǔ)在A服務(wù)器，1000-2000存儲(chǔ)在B服務(wù)器）
3． 采用Hash算法結(jié)合虛擬節(jié)點(diǎn)的方式。（這類在memcached等等分布式場(chǎng)景中最常見(jiàn)，其實(shí)也是一個(gè)難點(diǎn)），缺點(diǎn)就是在于動(dòng)態(tài)增加存儲(chǔ)節(jié)點(diǎn)會(huì)導(dǎo)致數(shù)據(jù)部分或者全部失效。
4． 目錄式的分區(qū)。最簡(jiǎn)單也是最直接的方式，key和分區(qū)的對(duì)應(yīng)關(guān)系被保存，通過(guò)查找目錄可以得到分區(qū)信息。適合擴(kuò)展，就是增加查詢損耗。
如何將數(shù)據(jù)分布的盡量均勻，如何平衡各個(gè)服務(wù)器之間的負(fù)載，如何在新增存儲(chǔ)機(jī)器和刪除存儲(chǔ)機(jī)器的時(shí)候不影響原有數(shù)據(jù)，同時(shí)能夠?qū)?shù)據(jù)均攤，都是算法的關(guān)鍵。在分布式系統(tǒng)中DHT（Distribute Hash Table）被很多人研究，并且有很多的論文是關(guān)于它的。
數(shù)據(jù)的橫向切分給應(yīng)用帶來(lái)的問(wèn)題：
1． 跨區(qū)的數(shù)據(jù)查詢變得很困難。（對(duì)于復(fù)雜的關(guān)聯(lián)性數(shù)據(jù)查詢無(wú)法在一個(gè)請(qǐng)求中完成）
2． 數(shù)據(jù)一致性和引用完整性較難保證。（多物理存儲(chǔ)的情況下很難保證兼顧效率、可用性、一致性）
3． 數(shù)據(jù)分區(qū)之間的負(fù)載均衡問(wèn)題。（數(shù)據(jù)本身的不均衡性，訪問(wèn)和讀寫的不均衡性都會(huì)給數(shù)據(jù)分區(qū)的負(fù)載均衡帶來(lái)困難）
4． 網(wǎng)絡(luò)配置的復(fù)雜性。（需要保證服務(wù)器之間的大數(shù)據(jù)量頻繁的交互和同步）
5． 數(shù)據(jù)備份策略將會(huì)變得十分復(fù)雜。
解決這些問(wèn)題當(dāng)前已經(jīng)有的一些開(kāi)源項(xiàng)目：
1． MySql Cluster，解決讀寫分離問(wèn)題已經(jīng)十分成熟。
2． MySql Partitioning，可以將一個(gè)大表拆分為很多小表，提高訪問(wèn)速度，但是限制與這些小表必須在同一臺(tái)服務(wù)器上。
3． HSCALE和Spock Proxy都是建立與MySql Proxy基礎(chǔ)上的開(kāi)源項(xiàng)目，MySql Proxy采用LUA腳本來(lái)進(jìn)行數(shù)據(jù)分區(qū)。
4． HiveDB是MySql分區(qū)框架的java實(shí)現(xiàn)。
5． 另外還有HyperTable,HBase,BigTable等等。
Netblog幾個(gè)需求：
1． 需要靈活的可擴(kuò)展性。對(duì)于存儲(chǔ)增加減少需要能夠動(dòng)態(tài)的及時(shí)實(shí)施，因?yàn)閿?shù)據(jù)量增長(zhǎng)很快，如果策略會(huì)導(dǎo)致數(shù)據(jù)失效或者部署需要重新啟動(dòng)，則就不能滿足需求。
2． 不想引入全新的數(shù)據(jù)層和與原有系統(tǒng)不匹配的抽象層，因?yàn)椴⒉皇撬袛?shù)據(jù)都需要切分，僅僅在需要的情況下通過(guò)API的方式來(lái)透明切分?jǐn)?shù)據(jù)。
3． 分區(qū)的主鍵需要可配置。
4． 需要封裝API，對(duì)開(kāi)發(fā)人員透明數(shù)據(jù)切分的工作。
Netblog Sharding的實(shí)現(xiàn)
上圖就是Netblog的Sharding的結(jié)構(gòu)圖，主要分成了三部分：Shard，Sharddb，Sharddbhost。Shard就是一個(gè)表，里面存放了部分用戶數(shù)據(jù)。Sharddb是一個(gè)表的組合就像一個(gè)虛擬的DB。Sharddbhost是具體的存儲(chǔ)分區(qū)。Shard，Sharddb可以根據(jù)負(fù)載的情況被移動(dòng)到不同的host中去。
對(duì)于Shard的管理，Netblog采用的是目錄查詢的管理方式。目錄信息也存儲(chǔ)在MySql中，同時(shí)會(huì)通過(guò)互備，Memcache，集群來(lái)確保安全性和高效性。
Shard Table API采用了多一層的映射模式來(lái)適合各種不同屬性的查詢情況。數(shù)據(jù)和記錄在數(shù)據(jù)庫(kù)中存儲(chǔ)除了UserID以外還有對(duì)應(yīng)的ItemID，ItemID的作用就是定義了具體獲取數(shù)據(jù)的字段信息，例如關(guān)聯(lián)照片表時(shí)，ItemID就是PhotoId，關(guān)聯(lián)視頻表時(shí)，ItemID就是videoID。
一個(gè)獲取用戶id為26博客信息的范例：
1．Where is user 26?
User 26 is on shard 5.
2．On shard 5; Give me all the $blogIDs ($itemIDs) of user 26.
That user's $blogIDs are: array(10,12,30);
3．On shard 5; Give me all details about the items array(10,12,30) of user 26.
Those items are: array(array('title' => "foo", 'message' => "bar"), array('title' => "milk", 'message' => "cow"));
對(duì)于Shard的管理Netblog采取的措施主要有這些：
1． 服務(wù)器之間的負(fù)載均衡根據(jù)用戶數(shù)，數(shù)據(jù)庫(kù)文件大小，讀寫次數(shù)，cpu load等等作為參數(shù)來(lái)監(jiān)控和維護(hù)。根據(jù)最后的結(jié)果來(lái)遷移數(shù)據(jù)和分流數(shù)據(jù)。
2． 移動(dòng)數(shù)據(jù)時(shí)會(huì)監(jiān)控用戶是否在操作數(shù)據(jù)，防止不一致性。
3． 對(duì)于數(shù)據(jù)庫(kù)的可用性，采用集群，master-master，master-slave復(fù)制等手段。
最后通過(guò)三種技術(shù)來(lái)解決三個(gè)問(wèn)題：
1． Memcached解決shard多次查詢的效率問(wèn)題。
根據(jù)上面的范例可以看到，一次查詢現(xiàn)在被分割成為了三部分：shard查詢，item查詢，最終結(jié)果查詢。通過(guò)memcached可以緩存三部分內(nèi)容，由前到后數(shù)據(jù)的穩(wěn)定性以及命中率逐漸降低，同時(shí)通過(guò)結(jié)合有效期（內(nèi)容存儲(chǔ)時(shí)效）和修改更新機(jī)制（add,update,delete觸發(fā)緩存更新），可以極大地解決效率問(wèn)題。甚至通過(guò)緩存足夠信息減少大量的數(shù)據(jù)庫(kù)交互。
2． 并行計(jì)算處理。
由于數(shù)據(jù)的分拆，有時(shí)候需要得到對(duì)于多Shard數(shù)據(jù)處理的結(jié)果匯總，因此就會(huì)將一個(gè)請(qǐng)求分拆為多個(gè)請(qǐng)求，分別交由多個(gè)服務(wù)器處理，最后將結(jié)果匯總。（類似于Map-reduce）
3． 采用Sphinx全文搜索引擎解決多數(shù)據(jù)分區(qū)數(shù)據(jù)匯總查詢，例如察看網(wǎng)站用戶的最新更新情況或者最熱門日至。這個(gè)采用單獨(dú)系統(tǒng)部署，通過(guò)建立全局信息索引，來(lái)查詢數(shù)據(jù)情況。
以上是技術(shù)上的全部?jī)?nèi)容，作者在最后的幾個(gè)觀點(diǎn)十分值得學(xué)習(xí)，同時(shí)也不僅僅限于數(shù)據(jù)切分，任何框架設(shè)計(jì)都可以參考。
“Don't do it, if you don't need to!" (37signals.com)
"Shard early and often!" (startuplessonslearned.blogspot.com)
看起來(lái)矛盾的兩句話，卻是說(shuō)出了對(duì)于數(shù)據(jù)切分的一些考慮。
首先在沒(méi)有必要的情況下就不要考慮數(shù)據(jù)切分，切分帶來(lái)的復(fù)雜性直接影響可用性，可維護(hù)性和一致性。在能夠采用Scale up的情況下，可以選擇Scale up降低框架復(fù)雜度。
另一方面，如果發(fā)現(xiàn)了業(yè)務(wù)增長(zhǎng)情況出現(xiàn)必須要擴(kuò)展的趨勢(shì)，那么就要盡早著手去實(shí)施和規(guī)劃擴(kuò)展的工作，并且在切分和擴(kuò)展過(guò)程中要不斷地去優(yōu)化和重構(gòu)。
后話：
其實(shí)任何架構(gòu)設(shè)計(jì)首要就是簡(jiǎn)單直接，不過(guò)度設(shè)計(jì)，不濫竽充數(shù)。其實(shí)就是要平衡好：可用性、高效性、一致性、可擴(kuò)展性這四者之間的關(guān)系。良性循環(huán)、應(yīng)時(shí)應(yīng)事作出取舍和折中。用的好要比學(xué)會(huì)用更重要，更關(guān)鍵。