有中心的存儲設(shè)計：Hadoop

Hadoop的設(shè)計目標(biāo)是存大文件、做offline分析、可伸縮性好。Hadoop的元數(shù)據(jù)存儲節(jié)點（NameNode節(jié)點）屬于主從式存儲模式，盡量將數(shù)據(jù)加載到內(nèi)存，能提高對數(shù)據(jù)的訪問性能。另外，放棄高可用，可進一步提高元數(shù)據(jù)的響應(yīng)性能（NameNode的變更不是同步更新到從機，而是通過定期合并的方式來更新）。

Hadoop具有以下幾方面優(yōu)點：

1. 為大文件服務(wù)。例如在塊大小為64MB時，10PB文件只需要存儲1.6億條數(shù)據(jù)，如果每條200Byte，那么需要32GB左右的內(nèi)存。而元信息的QPS也不用太高，如果每次QPS能提供一個文件塊的讀寫，那么1000QPS就能達到512Gb/s的讀寫速度，滿足絕大部分數(shù)據(jù)中心的需求。
2. 為offline業(yè)務(wù)服務(wù)。高可用服務(wù)可以部分犧牲。
3. 為可伸縮性服務(wù)。可以伸縮存儲節(jié)點，元信息節(jié)點無需伸縮。

然而有如此設(shè)計優(yōu)點的Hadoop為什么不適合在公有云領(lǐng)域提供服務(wù)呢？

1. 元信息容量太小。在公有云平臺上，1.6億是個非常小的數(shù)字，單個熱門互聯(lián)網(wǎng)應(yīng)用的數(shù)據(jù)都不止這些。1.6億條數(shù)據(jù)占用32GB內(nèi)存，100億條數(shù)據(jù)需要2000GB內(nèi)存，這時Hadoop就完全扛不住了。
2. 元信息節(jié)點無法伸縮。元信息限制在單臺服務(wù)器，1000QPS甚至是優(yōu)化后的15000QPS的單機容量遠不能達到公有云的需求。
3. 高可用不完美。就是前面所提到的NameNode問題，在業(yè)務(wù)量太大時，Hadoop支撐不住。

因此，做有中心的云存儲時，通常的做法是完全拋棄掉原先的單中心節(jié)點設(shè)計，引入一些其他的設(shè)計。

常見的是WRN算法，為數(shù)據(jù)準(zhǔn)備多個樣本，寫入W份才成功，成功讀取R份才算成功，W+R大于N（其中N為總副本數(shù)）。這樣就解決了之前提到的高可用問題，任何一個副本宕機，整個系統(tǒng)的讀寫都完全不受影響。

在這個系統(tǒng)里，利用這種技術(shù)有以下幾個問題需要注意：

1. W，R，N選多少合適。第一種選擇2，2，3，一共三副本，寫入兩份成功，讀取時成功讀取兩份算成功。但是其中一臺機器下線的話，會出現(xiàn)數(shù)據(jù)讀不出來的情況，導(dǎo)致數(shù)據(jù)不可用。第二種選擇4，4，6或者6，6，9，能夠容忍單機故障。但機器越多，平均響應(yīng)時間越長。
2. 失敗的寫入會污染數(shù)據(jù)。比如4，4，6的場景，如果寫入只成功了3份，那么這次寫入是失敗的。但如果寫入是覆蓋原來的元數(shù)據(jù)，就意味著現(xiàn)在有三份正確的數(shù)據(jù)，有三份錯誤的數(shù)據(jù)，無法判斷哪份數(shù)據(jù)正確，哪份數(shù)據(jù)錯誤?；乇艿姆椒ㄊ菍懭霐?shù)據(jù)帶版本（不覆蓋，只是追加），即往數(shù)據(jù)庫里面插入新數(shù)據(jù)。有些云存儲的使用方法是對一個文件進行反復(fù)的修改，比如用M3U8文件直播。隨著直播進程的開始不停地更改文件，大概5秒鐘一次，持續(xù)一個小時文件會被修改720次。這時候從數(shù)據(jù)庫讀取文件信息時，就不再是讀1條記錄，而是每臺讀取720條記錄，很容易導(dǎo)致數(shù)據(jù)庫出現(xiàn)性能瓶頸。

下面，我們簡單總結(jié)一下以Hadoop為代表的有中心的存儲設(shè)計速存在的問題：

基于數(shù)據(jù)庫的分布式存儲設(shè)計：GridFS和HBase

GridFS

GridFS基于MongoDB，相當(dāng)于一個文件存儲系統(tǒng)，是一種分塊存儲形式，每塊大小為255KB。數(shù)據(jù)存放在兩個表里，一個表是chunks，加上元信息后單條記錄在256KB以內(nèi)；另一個表是files，存儲文件元信息。

GridFS的優(yōu)點如下所述。

1. 可以一次性滿足數(shù)據(jù)庫和文件都需要持久化這兩個需求。絕大部分應(yīng)用的數(shù)據(jù)庫數(shù)據(jù)需要持久化，用戶上傳的圖片也要做持久化，GridFS用一套設(shè)施就能滿足，可以降低整個運維成本和機器采購成本。
2. 擁有MongoDB的全部優(yōu)點：在線存儲、高可用、可伸縮、跨機房備份。
3. 支持Range GET，刪除時可以釋放空間（需要用MongoDB的定期維護來釋放空間）。

GridFS的缺點如下所述：

1. oplog耗盡。oplog是MongoDB上一個固定大小的表，用于記錄MongoDB上的每一步操作，MongoDB的ReplicaSet的同步依賴于oplog。一般情況下oplog在5GB～50GB附近，足夠支撐24小時的數(shù)據(jù)庫修改操作。但如果用于GridFS，幾個大文件的寫入就會導(dǎo)致oplog迅速耗盡，很容易引發(fā)secondary機器沒有跟上，需要手工修復(fù)，大家都知道，MongoDB的修復(fù)非常費時費力。簡單來說，就是防沖擊能力差，跟數(shù)據(jù)庫的設(shè)計思路有關(guān)，畢竟不是為文件存儲設(shè)計的。除了手工修復(fù)的問題，沖擊還會造成主從數(shù)據(jù)庫差異拉大，對于讀寫分離，或者雙寫后再返回等使用場景帶來不小的挑戰(zhàn)。
2. 濫用內(nèi)存。MongoDB使用MMAP將磁盤文件映射到內(nèi)存。對于GridFS來說，大部分場景都是文件只需讀寫一次，對這種場景沒法做優(yōu)化，內(nèi)存浪費巨大，會擠出那些需要正常使用內(nèi)存的數(shù)據(jù)（比如索引）。這也是設(shè)計阻抗失配帶來的問題。
3. 伸縮性問題。需要伸縮性就必須引入MongoDB Sharding，需要用files_id作Sharding，如果不修改程序，files_id遞增，所有的寫入都會壓入最后一組節(jié)點，而不是均勻分散。在這種情況下，需要改寫驅(qū)動，引入一個新的files_id生成方法。另外，MongoDBSharding在高容量壓力下的運維很痛苦。MongoDB Sharding需要分裂，分裂的時候響應(yīng)很差，會導(dǎo)致整個服務(wù)陷入不可用的狀態(tài)。

對GridFS的總結(jié)如下：

HBase

前面提到Hadoop因為NameNode容量問題，所以不適合用來做小文件存儲，那么HBase是否合適呢？

HBase有以下優(yōu)點：

1. 伸縮性、高可用都在底層解決了。
2. 容量很大，幾乎沒有上限。

但缺點才是最關(guān)鍵的，HBase有以下缺點。

1. 微妙的可用性問題。首先是Hadoop NameNode的高可用問題。其次，HBase的數(shù)據(jù)放在Region上，Region會有分裂的問題，分裂和合并的過程中Region不可用，不管用戶這時是想讀數(shù)據(jù)還是寫數(shù)據(jù)，都會失敗。雖然可以用預(yù)分裂回避這個問題，但這就要求預(yù)先知道整體規(guī)模，并且key的分布是近均勻的。在多用戶場景下，key均勻分布很難做到，除非舍棄掉key必須按順序這個需求。
2. 大文件支持。HBase對10MB以上的大文件支持不好。改良方案是將數(shù)據(jù)拼接成大文件，然后HBase只存儲文件名、offset和size。這個改良方案比較實用，但在空間回收上需要補很多開發(fā)的工作。

應(yīng)對方案是HBase存元數(shù)據(jù)，Hadoop存數(shù)據(jù)。但是，Hadoop是為offline設(shè)計的，對NameNode的高可用考慮不充分。HBase的Region分拆和合并會造成短暫的不可用，如果可以，最好做預(yù)拆，但預(yù)拆也有問題。如果對可用性要求低，那么這種方案可用。

繞過問題的存儲設(shè)計：FastDFS

Hadoop的問題是NameNode壓力過高，那么FastDFS的思路是給NameNode減壓。減壓方法是將NameNode的信息編碼到key中。對于范例URL:group1/M00/00/00/rBAXr1AJGF_3rCZAAAAEc45MdM850_big.txt來說，NameNode只需要做一件事，將group1翻譯成具體的機器名字，不用關(guān)心key的位置，只要關(guān)心組的信息所在的位置，而這個組的信息就放在key里面，就繞過了之前的問題。

FastDFS的優(yōu)點如下：

1. 結(jié)構(gòu)簡單，元數(shù)據(jù)節(jié)點壓力低。
2. 擴容簡單，擴容后無需重新平衡。

FastDFS的缺點如下：

1. 不能自定義key，這對多租戶是致命的打擊，自己使用也會降低靈活性。
2. 修復(fù)速度：磁盤鏡像分布，修復(fù)速度取決于磁盤寫入速度，比如4TB的盤，100MB/s的寫入速度，至少需要11個小時。
3. 大文件沖擊問題沒有解決。首先，文件大小有限制（不能超過磁盤大?。?；其次，大文件沒有分片，導(dǎo)致大文件的讀寫都由單塊盤承擔(dān)，所以對磁盤的網(wǎng)絡(luò)沖擊很大。

結(jié)語

本文基于七牛首席架構(gòu)師李道兵在QCon會議上的演講內(nèi)容整理而成，著重對幾種存儲設(shè)計進行了比較全面的分析，總結(jié)如下。而關(guān)于分布式存儲的元數(shù)據(jù)設(shè)計還有很多更為細節(jié)的點和經(jīng)驗值得探討，留待日后慢慢與大家交流。

fanz