分享照片是Facebook上最流行的的功能之一。截至目前，用戶已經上傳超過15億張照片，這使得Facebook成爲最大的照片共享網站。對於每一個上傳的照片，Facebook都生成並存儲四個大小不同的圖像，從而轉化爲共60億張照片，總容量超過1.5PB。目前以每週220萬新照片的速度增長，相當於每週要額外增加25TB存儲。在高峯期每秒需要傳輸55萬照片。這些數字對Facebook的照片存儲基礎設施的一個重大的挑戰。
舊的 NFS 照片架構
老的照片系統架構分以下幾個層：
- 上傳層接收用戶上傳的照片並保存在 NFS 存儲層。
- 照片服務層接收 HTTP 請求並從 NFS 存儲層輸出照片。
- NFS存儲層建立在商業存儲系統之上。
- Cachr: 一個緩存服務器，緩存 Facebook 的小尺寸用戶資料照片。
- NFS文件句柄緩存：部署在照片輸出層，以降低 NFS 存儲層的元數據開銷。
新的照片架構將輸出層和存儲層合併爲一個物理層，建立在一個基於HTTP 的照片服務器上，照片存儲在一個叫做haystack 的對象庫，以消除照片讀取操作中不必要的元數據開銷。新架構中，I/O 操作只針對真正的照片數據（而不是文件系統元數據）。haystack 可以細分爲以下幾個功能層：
- HTTP 服務器
- 照片存儲
- Haystack 對象存儲
- 文件系統
- 存儲空間
在下面的介紹中，我們會對於上述的每個功能層做詳細的講述。
存儲空間Haystack 部署在商業存儲刀片服務器上，典型配置爲一個2U的服務器，包含：
- 兩個4核CPU
- 16GB – 32GB 內存
- 硬件 RAID，含256-512M NVRAM 高速緩存
- 超過12個1TB SATA 硬盤
每個刀片服務器提供大約10TB的存儲能力，使用了硬件 RAID-6, RAID 6在保持低成本的基礎上實現了很好的性能和冗餘。不佳的寫性能可以通過RAID控制器和NVRAM緩存回寫解決，寫由於讀取大多是隨機的，NVRAM緩存是完全用於寫入的。
Haystack 對象庫是建立在10TB容量的單一文件系統之上。
圖片讀取請求需要在讀取系統調用這些文件的位置偏移，但是爲了執行讀取操作，文件系統必須先找到實際物理捲上的數據。文件系統中的每個文件都被一個叫做inode結構標識。inode包含了一個磁盤上邏輯文件偏移和物理區塊偏移的映射。在使用的特殊類型文件系統時大文件塊映射可能相當大。
基於文件系統的區塊爲給個邏輯區塊和大文件保存映射。這些信息通常不適合保存在inode的緩存中，而是存儲在在間接地址塊。所以在讀取文件的時候必須按照特定的流程。這裏可以多個是間接地址塊，所以一個讀取會產生多個I/O取決於是否間接地址塊被緩存。
該系統只爲連續範圍的區塊保持映射。一個連續的大文件的塊映射可以只由一個範圍的標識，這樣是適應inode的系統需求的。但是，如果該文件是一個被切割的不連續的塊的話，他的塊地圖可能非常的大。以上可以通過文件系統主動爲大的物理文件分配大塊的空間來減少碎片。
目前使用的文件系統爲XFS，一個很大程度提供高效的文件預分配系統。
Haystack
對象存儲
Haystack
是一個簡單的日誌結構（只能追加），存儲着其內部數據對象的指針。一個 Haystack 包括兩個文件，包括指針和索引。下面的圖片將描述haystack存儲文件的佈局：
haystack最前面的8K存儲是被超級塊佔用。緊隨超級塊是針，每針組成的一個頭部，數據和尾部：
一個針被他的<offset key=”" alternate=”" cookie=”">元組標識，其中的偏移量爲其在haystack存儲的偏移。Haystack不在任何健值上做限制，即允許可以有重複鍵針。下圖顯示了索引文件的佈局：
在haystack存儲文件中有每針相應的的索引記錄，並且包含針索引記錄的順序必須和haystack存儲文件相關的針的順序相匹配。按照規定索引文件的最低需求是找到一個特定的針在haystack存儲文件的元數據。載入和組織索引記錄到一個有效的查找數據結構是Haystack程序的責任。索引文件是不是很關鍵，因爲如果需要它可以從haystack存儲文件重建。索引的主要職責是讓針元數據無需通過較大的Haystack存儲文件，快速加載到內存中。原因是其可以讓索引編程原來存儲的1%。
Haystack 寫操作
Haystack 寫操作同步將指針追加到 haystack 存儲文件，當指針積累到一定程度，就會生成索引寫到索引文件。由於索引文件是不是很關鍵，爲了能有更快的性能所以採用異步的方式進行寫入。
爲了降低硬件故障帶來的損失，索引文件還會定期寫到存儲空間中。在崩潰或突然斷電的情況下，將haystack恢復處理器存儲中任何殘缺的針和截斷haystack存儲中最後一個有效的針。接下來，它會把丟失的針的索引記錄 寫到haystack文件的最後。
Haystack不允許重寫現有的針偏移，如果一個針數據需要被重寫，那麼新版本必須使用相同的<key alternate=”" key=”" cookie=”">元組。應用程序會自動分辨出這兩個相同的鍵，有最大偏移的便是最新的那一個。
Haystack 讀操作
傳到 haystack 讀操作的參數包括指針的偏移量，健，備用鍵，Cookie 以及數據大小。Haystack爲數據大小添加頭部和尾部的長度，然後根據數據尺寸從文件中讀取整個指針。讀取操作成功的關鍵就是作爲參數傳遞的健，備用鍵，Cookie是否匹配，數據是否通過了校驗，並且針沒有被刪除掉。（見下文）
Haystack 刪除操作
刪除操作比較簡單 – 只需要在 Haystack 存儲的指針字段中的“刪除”位標記一下即可。並且，相關的索引記錄不會做任何的修改。是最終的應用程序引用到的是一個刪除的針。像這樣一個讀取刪除針的操作將會返回一個相應的錯誤給應用程序。空間對已刪除的針不做任何的回收，只有這樣，才能使 haystack 的空間非常的緊湊。（見下文）
照片存儲服務器
照片存儲服務器負責接受 HTTP 請求，並轉換成相應的 Haystack 操作。爲了儘量減少服務器檢索照片時的I/O操作，該服務器維護着全部 Haystack 中文件索引的緩存。服務器啓動時，系統就會將這些索引讀到緩存中。由於每個節點都有數百萬張照片，必須保證索引的容量不會超過服務器的物理內存。在內存中僅需要保存查找照片所需的少量元數據即可。
對於用戶上傳的圖片，系統分配一個64位的獨立ID，照片接着被縮放成4種不同尺寸，每種尺寸的圖像擁有相同的隨機 Cookie 和64位的密鑰，圖片尺寸描述（大，中，小，縮略圖）被存在代用key 中。接着上傳服務器通知照片存儲服務器將這些資料連同圖片存儲到 haystack 中。
每張圖片的索引緩存包含以下數據：
由於Google的開源 sparse hash data 結構對於每個條目只有2bit的開銷，所以Haystack使用它來保證內存中的索引緩存儘可能小。
照片存 儲的寫/修改操作
寫操作將照片數據寫到 Haystack 存儲並更新內存中的索引。如果該索引記錄中包含了相同的鍵，那麼這是一次對現有的照片進行修改的操作。並且只要修改索引記錄中的偏移來反應新圖像在haystack存儲文件的位置。照片存儲始終假定，如果有重複的圖像（圖像具有相同的鍵），有較大的偏移量的那個存儲是有效的。
照片存儲的讀操作
傳遞給一個讀操作的參包括Haystack ID，照片的 Key, 尺寸以及 Cookie。服務器事先在緩存中按照照片的Key和所需文件的偏移進行查找。如果找到了它，並向haystack發出讀取詞圖像的請求。按照上面說的，haystack的刪除操作並不更新它的索引記錄，因此添加到內存中的索引可以包含以前刪除的照片的內容。當閱讀以前的刪除的照片失敗後，系統將在內存的索引中色繪製詞圖片的偏移量爲0.
照片存儲的刪除操作
通知 Haystack 執行刪除操作之後，內存中的索引緩存會被更新，將偏移量設置爲0，表示照片已被刪除。
重新整理（壓縮）
重新整理（壓縮）是一種回收刪除和重複的針（針使用相同的Key）的在線操作。它會通過複製針跳過任何重複或刪除的條目創建一個新的 haystack。一旦此操作完成它就回去替換掉內存中的文件和結構。
HTTP 服務器
Http 框架使用的是簡單的基於開源的libevent庫的 evhttp 服務器。使用多線程，每個線程都可以單獨處理一個 HTTP 請求。因爲我們的系統消耗大多是I/O操作，HTTP服務器的性能並不很重要。
結束語
Haystack 是一個基於 HTTP 的對象存儲，包含指向實體數據的指針，該架構消除了文件系統元數據的開銷，並實現將全部索引直接存儲到緩存，以最小的 I/O 操作實現對照片的存儲和讀取。
本文作者爲Facebook的工程師Peter Vajgel, Doug Beaver 和 Jason Sobel， 由標點符進行翻譯。
原文鏈接（E文）：http://www.facebook.com/note.php?note_id=76191543919&ref=mf
轉發原文：http://www.biaodianfu.com/facebook-efficient-storage-of-billions-of-photos.html