分布式存儲的元數(shù)據(jù)設(shè)計李道兵 七?牛云存儲 2015-04 北京引?子? ?面試新?人時最經(jīng)常被問到的?一句話：七?牛的云存儲真的是?自?己寫的么，是不是基于 的？? ?無中?心的存儲設(shè)計: ? 有中?心的存儲設(shè)計： ? 基于數(shù)據(jù)庫的存儲設(shè)計: , hbase ? 繞過問題的存儲設(shè)計: ? 設(shè)計??目標(biāo) ? 兼容 POSIX ?文件系統(tǒng): 你的應(yīng)?用程序?無需修改就可以放到 上來運?行 ? ?無中?心節(jié)點: 性能瓶頸沒有了，單點故障也沒有了 ? 擴(kuò)展能?力: ?大容量存儲都需要這個 ? 我們在這?里不討論 POSIX 兼容的優(yōu)劣，集中通過 來討論?無中?心節(jié)點設(shè)計中普遍遇到的?一些難點? 是?一系列?無中?心存儲的設(shè)計的代表 ? ?無中?心暗?示著我們可以通過內(nèi)容的 key 推算出來這個 key 的存儲位置 ? 在絕?大部分實踐中，在這種設(shè)計下如果出現(xiàn)單盤故障，處理模式如下 ? 去掉壞盤，換上新盤 ? 從?老盤拷?貝數(shù)據(jù)到新盤 ? 這個模式最?大的問題是修復(fù)時間，4T盤在 100MB/s 的修復(fù)速度下需要?至少 11 個?小時，這么?長的修復(fù)時間會導(dǎo)致數(shù)據(jù)的可靠性降低（在這11個?小時內(nèi)另外兩塊盤的損壞概率） ? 另外?一種修復(fù)模式是在讀的時候發(fā)現(xiàn)有壞塊，然后觸發(fā)修復(fù)，在這種模式下修復(fù)只會更糟糕。
? 如何回避掉這個問題呢？ ? 引?入中間層記錄分區(qū)和物理設(shè)備的關(guān)系，這樣磁盤損壞不?用等換盤就可以開始修復(fù) ? ?一個磁盤分成多個區(qū)，每個區(qū)可以到不同的盤上去修復(fù)，那么可以?大幅度縮短修復(fù)時間，?比如分到 50 個區(qū)（每個區(qū) 80GB), 那么修復(fù)時間就可以縮?小到 13分鐘左右。? 擴(kuò)容 ? 在?無中?心設(shè)計中，擴(kuò)容往往伴隨著數(shù)據(jù)的再平衡，再平衡會帶來如下的挑戰(zhàn) ? ??網(wǎng)絡(luò)擁塞：可以使?用獨?立的遷移??網(wǎng)絡(luò)來改善 ? 遷移時間?長且遷移期間數(shù)據(jù)讀寫邏輯變得更復(fù)雜：多加測試改善代碼質(zhì)量? 不?支持異構(gòu)存儲 ? ?比如?小?文件經(jīng)常伴隨著很?高的 iops 需求，針對?小?文件我們可以引?入SAS或者SSD盤來得到更?高的 iops, 但對于?無中?心存儲來講，這種?方法很難實施。 ? 類似的異構(gòu)需求還包括某些客戶數(shù)據(jù)只想存兩份，?而其他客戶數(shù)據(jù)則想多存?幾份的情況，這些在?無中?心存儲中都是很難解決的。 ? ?小?文件的問題針對讀取的部分可以通過緩存層來改善，但對于?高頻率的寫?入沒有太好的解決?方案 ? 這?兒也存在?一個基于 hash 碰撞的攻擊?方案，不過影響不?大。
? 數(shù)據(jù)不?一致的問題 ? ?比如我們要覆蓋?一個 key，但在覆蓋過程中出現(xiàn)意外，導(dǎo)致只覆蓋了三個副本中的兩個或者?一個。這個時候就很容易讀到錯誤的數(shù)據(jù)。 ? 在寫?入?文件時，先寫臨時?文件，最后再重命名能改善這個問題，但仍然不完美。? 問題總結(jié) ? 壞盤修復(fù)問題：元數(shù)據(jù)+分區(qū)可以改善這個問題 ? 擴(kuò)容動作?大: 忍 ? ?小?文件?高IOPS: 劣勢，集群?足夠?大的話可以靠規(guī)模來抗住 ? 數(shù)據(jù)不?一致的問題: 復(fù)雜度會變?高? 設(shè)計??目標(biāo) ? ?大?文件 ? 使?用 ? 可伸縮 ? 元數(shù)據(jù)()設(shè)計 ? 主備模式，各?一臺機(jī)器 ? 數(shù)據(jù)盡量加載到內(nèi)存，提?高性能 ? 放棄?高可?用，進(jìn)?一步提?高元數(shù)據(jù)的性能 ( 的變更不是同步更新到從機(jī)，?而是通過定期合并的?方式來更新） 優(yōu)點? 為?大?文件服務(wù): ? 意味著 不會太?大，?比如 64M 的塊?大?小, 10PB ?文件只需要存儲 億條數(shù)據(jù)，如果每條數(shù)據(jù) 200B, 那么需要 32GB 左右的內(nèi)存。
? 元信息的 qps 也不?用太?高，如果每次 qps 能提供?一個?文件塊的讀寫，那么 就能達(dá)到 512Gb/s 的讀寫速度存儲系統(tǒng)元數(shù)據(jù)圖譜化，滿?足絕?大部分?jǐn)?shù)據(jù)中?心的需求。 ? 為業(yè)務(wù)服務(wù): ?高可?用可以部分犧牲 ? 為可伸縮服務(wù): 伸縮的是存儲節(jié)點，元信息節(jié)點?無需伸縮。 為什么不能當(dāng)公有云？? 元信息容量太??。?億條數(shù)據(jù)就占掉 32GB，100億的數(shù)據(jù)需要 內(nèi)存，這個完全沒法接受 ? 元信息節(jié)點?無法伸縮: 元信息限制在單臺， 甚?至 的單機(jī)容量遠(yuǎn)不能達(dá)到公有云的需求。 ? ?高可?用不完美: 問題其他有中?心設(shè)計? WRN算法 ? 寫?入了 W 份才算成功 ? 讀取時成功讀取 R 份才算成功 ? W + R > N (其中N 為總副本數(shù)）圖片來自：莫華楓的《云存儲的?黑暗面：元數(shù)據(jù)保障》WRN算法? W,R,N 的選擇 ? ?比如2,2,3這種情況，寫?入兩份就算成功，但如果其中?一臺機(jī)器下線，這個數(shù)據(jù)就可能讀不出來了 ? 所以446 或者 669 這樣的選擇會更好。
但機(jī)器越多，響應(yīng)會越差。WRN算法? 失敗的寫?入會污染數(shù)據(jù) ? ?比如 446 的場景，如果寫?入只成功了3份，那么這次寫?入是失敗的，但如果是覆蓋寫?入，那么也就意味著現(xiàn)在有三份正確的數(shù)據(jù)，三份錯誤的數(shù)據(jù)，哪?一個是正確就?無從判別了。 ? 寫?入數(shù)據(jù)帶版本(不覆蓋，只是追加)能改善這個問題，但帶來了?一個攻擊點：反復(fù)覆蓋同?一個?文件，導(dǎo)致數(shù)據(jù)庫出現(xiàn)性能瓶頸有元數(shù)據(jù)的存儲? ? 不是?高可?用 ? 容量不?足 ? WRN?支持的元數(shù)據(jù) ? 響應(yīng)性差 ? 有丟失數(shù)據(jù)可能性 (覆蓋寫) / 有攻擊點 (帶版本寫)基于數(shù)據(jù)庫的分布式存儲?方案? (基于 ) ? HBase ? HBase + ? 基于 ? 分塊存儲，每塊?大?小為255KB ? 數(shù)據(jù)直接放在兩個表?里邊 ? : 存儲數(shù)據(jù)，加上元信息后單條記錄在 256KB 以內(nèi) ? files: 存儲?文件元信息 優(yōu)點? 兩個需求（數(shù)據(jù)庫和?文件都需要持久化），?一次滿?足 ? 擁有的全部優(yōu)點: 在線存儲，?高可?用，可伸縮(*)，跨機(jī)房備份，… ? ?支持 Range GET，刪除時可以釋放空間(需要?用 的定期維護(hù)來釋放空間) 的缺點? oplog 耗盡: ? oplog 是 上?一個固定?大?小的表，?用于記錄 上的每?一步操作， 的 的同步依賴于 oplog。
? ?一般情況下 oplog 在 5GB-50GB 附近，?足夠?支撐 24 ?小時的數(shù)據(jù)庫修改操作。 ? 但如果?用于 ，?幾個?大?文件的寫?入就會導(dǎo)致 oplog 迅速耗盡，很容易引發(fā) 機(jī)器沒有跟上，需要?手?工修復(fù)，?而且 的修復(fù)?非常費?力。 ? 簡單來說就是防沖擊能?力差，這個跟數(shù)據(jù)庫的設(shè)計思路有關(guān)。 ? 除了前?面提到?手?工修復(fù)的問題外，沖擊還會造成主從數(shù)據(jù)庫差異拉?大，對于讀寫分離，或者雙寫后再返回的場景帶來不?小的挑戰(zhàn)。 的缺點? 濫?用內(nèi)存 ? 使?用 mmap 來把磁盤?文件映射到內(nèi)存存儲系統(tǒng)元數(shù)據(jù)圖譜化，對于 來說，?大部分場景都是?文件只需讀寫?一次，對于這種場景沒法做優(yōu)化，內(nèi)存浪費巨?大，會擠出那些需要正常使?用內(nèi)存的數(shù)據(jù)。 ? 設(shè)計阻抗失配帶來的另外?一個問題。 的缺點? 伸縮性 ? 需要伸縮性就必須引?入 ? 的情況下你需要使?用 作為 key ? 如果你不修改程序的話 是遞增的，也就是說所有的寫?入都會壓?入同?一個集群，?而不是均勻分散。
? 在這種情況下你需要改寫你的驅(qū)動，引?入?一個新的 ?生成?方法。 ? 另外， 在?高容量?高壓?力下的運維很痛苦（?大家可以參考百度??網(wǎng)盤組之前的?一些 PPT)? 低壓?力: 沒問題，挺好?用的 ? 中壓?力: 如果單臺機(jī)器能抗住你的存儲，建議分離數(shù)據(jù)庫和, 使?用獨?立的機(jī)器資源 ? ?高壓?力: 不建議使?用 ? 前?面提到 因為 容量問題所以不合適?用來做?小?文件存儲，那么 HBase 是否合適呢？HBase 的優(yōu)點? 伸縮性，?高可?用都在底層幫你解決了 ? 容量很?大,?幾乎沒有上限。HBase 缺點? 微妙的可?用性問題 ? ?首先是 的?高可?用問題 ? HBase 的數(shù)據(jù)放在 上， 會有分裂的問題，在分裂和合并的過程中，這個 會不可?用 ? 我們可以采?用預(yù)分裂來回避這個問題，但這就要求 預(yù)先知道整體規(guī)模，并且key 的分布是近均勻的 ? 在多租戶的場景下，key 均勻分布很難做到（除?非舍棄掉 key 必須按順序這個需求）HBase 的缺點? ?大?文件?支持 ? 10MB以上的?大?文件?支持不好 ? ?一個改良?方案是把數(shù)據(jù)拼裝成?大?文件，然后 hbase 只存儲?文件名， 和 size ? 這個改良?方案其實挺實?用的，不過如果要做到空間回收就需要補很多開發(fā)了。
HBase?方案? HBase存元數(shù)據(jù)， 存數(shù)據(jù)算?一個可?用?方案，但是 ? 是 設(shè)計的，的?高可?用考慮不充分 ? HBase的 分拆和合并會造成短暫的不可?用，如果可以的話最好做預(yù)拆，但預(yù)拆也有問題 ? 如果對可?用性要求低的話問題不?大繞過問題也是解決問題的?方式: ? : ? 的問題是 壓?力過?高，那么 的思路就是給 減壓。 ? 減壓的?方法就是把 的信息編碼到key?里邊 ? 范例URL: /M00/00/00/- ? 也就是說 只需做?一件事情，把 翻譯成具體的機(jī)器名字 的優(yōu)點? 結(jié)構(gòu)簡單，元數(shù)據(jù)節(jié)點壓?力低 ? 擴(kuò)容簡單，擴(kuò)容后數(shù)據(jù)?無需重新平衡 缺點? 不能?自定義 key: 這個對多租戶是致命的打擊，?自?己使?用也會減低靈活性 ? 修復(fù)速度: ? 磁盤鏡像分布，修復(fù)速度取決于磁盤寫?入速度，?比如 4TB 的盤, 100MB/s 的寫?入速度，那么需要?至少 11個?小時 ? ?大?文件容易造成沖擊 ? ?首先是?文件?大?小有限制(不能超過磁盤?大??。?? 其次是?大?文件沒有分?片，導(dǎo)致?大?文件的讀寫都由單塊盤來承擔(dān)，所以對磁盤的??網(wǎng)絡(luò)沖擊很?大優(yōu)點 缺點?無中?心設(shè)計 ?無?高壓?力節(jié)點修復(fù)慢，擴(kuò)容難 ?無異構(gòu)?支持 數(shù)據(jù)不?一致 有中?心設(shè)計 擴(kuò)容，修復(fù)更靈活 中?心節(jié)點難設(shè)計基于數(shù)據(jù)庫的設(shè)計 簡單，易上?手 設(shè)計失配?容量有限 中?心壓?力?小，易擴(kuò)容 key不能隨便重命名 ?大?文件?支持差Q&A