設計Facebook圖片存儲系統

爲何 Facebook 要本身作圖片存儲？

• PB級別的Blob數據量
• 傳統的基於NFS的設計（每一個圖像存儲爲文件）都存在元數據瓶頸：龐大的元數據嚴重限制了元數據命中率。
  • 如下是細節解釋：

對於圖片應用程序，圖片的權限等大多數元數據是無用的，從而浪費了存儲空間。然而，更大的開銷在於，必須將文件的元數據從磁盤讀入內存中才能找到文件自己。雖然對於小規模存儲來講這微不足道，但當乘以數十億的照片和數PB的數據時，那麼訪問元數據將是吞吐量的瓶頸。

解決方案

經過把數以十萬計的圖像彙集到單個Haystack存儲文件中，從而消除了元數據負荷。

結構

數據佈局

索引文件（用於快速加載內存）+ 包含不少圖片的haystack存儲文件。

索引文件佈局

儲存文件

CRUD操做

• 增: 寫入存儲文件，而後異步寫入索引文件，由於創建索引並非關鍵的步驟。
• 刪: 經過在標誌字段中標記已刪除的位來進行軟刪除。經過緊湊操做執行硬刪除。
• 改: 在更新時，只能追加 (append-only)，若是遇到了重複的鍵，應用程序能夠選擇具備最大偏移量的鍵去改和讀。
• 查: 讀取操做（偏移量，健，備用鍵，Cookie 以及數據大小）

用例

上傳

下載

本文首發於硅谷io