Facebook圖片存儲系統Haystack——存小文件，本質上是將多個小文件合併爲一個大文件來下降io次數，meta data裏存偏移量

轉自：http://yanyiwu.com/work/2015/01/04/Haystack.html

一篇14頁的論文Facebook-Haystack， 看完以後個人印象裏就四句話：

• 由於【傳統文件系統的弊端】
• 由於【緩存沒法解決長尾問題】
• 因此【多個圖片信息(Needle)存在同一個文件(SuperBlock)中】
• 因此【顯著提升性能】

傳統文件系統的弊端

傳統的 POSIX 文件系統不適合高性能的圖片存儲， 主要緣由是基於該文件系統來存儲的話，是講每一個圖片存儲成某目錄下的一個文件， 每次讀取文件的時候須要有N次磁盤IO，當目錄下文件數是K級別是， 讀取一次文件須要超過10次的文件IO，即便目錄下的文件數是0.1K級別時， 也須要3次的文件IO（1:讀取目錄元數據,2:讀取inode,3:讀取文件內容）。

緩存沒法解決長尾問題

圖片存儲的應用場景如圖：

在 PhotoStorage 以前還有一些 CDN 保駕護航， CDN 就是靠緩存吃飯的，對於那些熱門的圖片都能被 CDN 很好的緩存下來， 因此須要訪問的 PhotoStorage 通常都是非熱門圖片， 因此在這樣的場景之下， 在 PhotoStorage 改進緩存顯然是沒法解決問題的。 你懂的，緩存對於長尾問題基本上都是一籌莫展的。 由於若是緩存能解決的問題，就不叫長尾問題了。

多個圖片信息存在同一個文件中

每次讀取一個圖片須要屢次磁盤IO的緣由是由於一個圖片存成一個文件， 文件系統裏面每次讀取文件須要先讀取文件的元信息等，致使屢次磁盤IO， 而當咱們將多個圖片信息存在同一個文件中， 固然這個文件會很大， 而後在內存中存儲該圖片存儲在文件中的偏移地址和圖片大小， 因此每次讀取圖片的時候， 根據偏移地址直接讀取讀取， 大部分狀況下能作到只須要一次磁盤IO便可。 從而顯著提升性能。

轉載請註明出處: Facebook圖片存儲系統Haystack

 

 

基於這個思想，haystack 設計者繞過了 POSIX 文件系統這塊，把 haystack 變成了一個 KV FS，即 NOFS。每一個圖片對應一個 FID，再也不單獨存放文件系統中，而是同一個物理卷 Volume 圖片所有寫入一個文件中，由 Volume Server 內存維護 FID : <Volume Machine, Offset, Size> 映射關係，Volume Server 內存中維護打開的文件句柄，讀取圖片時只需一次 IO 順序讀操做。

haystack架構圖

架構比較簡單，分爲三部份：Haystack Directory, Haystack Cache, Haystack Store

Directory: 即所謂的 Meta Server

1. 生成 FID，維護 logical volume 與 physical volume 映射關係，解決上傳時的負載均衡問題。

2. 新加入的 Store Server 要在這裏註冊。

3. 維護 logical volume 的 read-only 屬性，只讀的 logical volume 再也不接受 upload 請求。

4. 決定請求走 CDN 仍是內部 Haystack Cache Server.

Cache: 所謂的內部 CDN

1. 對圖片 FID 採用一致性 hash 算法保存。

2. 只緩存用戶請求，而不是來自 CDN 的請求。

3. 只緩存 write-enabled store 圖片，因爲上傳的時間序，至關於只緩存最新生成的圖片。好比說用戶剛上傳的圖片，可能就會存到 Cache 中預熱。

Store: 最終落地存儲服務

1. 圖片順序追加到一個大文件中，內存中維護圖片在文件中的 Offset 和 Size 的索引信息。

2. 爲了解決重啓快速加載問題，索引信息會單獨保存到一個 Index File 中。