Facebook 海量資料處理）

好幾個地方看到這個 Facebook - Needle in a Haystack: Efficient Storage of Billions of Photos，是 Facebook 的 Jason Sobel 做的一個 PPT，揭示了不少比較有參考價值的資訊。【也別錯過我過去的這篇Facebook 的PHP效能與擴充性】

圖片規模

作為世界上最大的 ">SNS 網站之一，Facebook 圖片有多少? 65 億張原始圖片，每張圖片存為 4-5 個不同尺寸，這樣總計圖片檔案有 300 億左右，總容量 540T，天! 峰值的時候每秒鐘請求 47.5 萬個圖片 (當然多數通過 ">CDN) ，每周上傳 1 億張圖片。

圖片儲存

前一段時間說 Facebook 伺服器超過 10000 台，現在開啟不止了吧，Facebook 融到的大把銀子都用來買硬體了。圖片是儲存在 Netapp NAS上的，採用 ">NFS 方式。

圖片寫入

儘管這麼大的量，似乎圖片寫入並不是問題。如，是直接通過 ">NFS 寫的。

圖片讀取

">CDN 和 Cachr 承擔了大部分訪問壓力。儘管 Netapp 裝置不便宜，但基本上不承擔多大的訪問壓力，否則吃不消。CDN 針對 Profile 圖象的命中率有 99.8%，普通圖片也有 92% 的命中率。命中丟失的部分采由 Netapp 承擔。

圖中的 Cachr 這個組件，應該是用來訊息通知(基於調整過的 evhttp的嘛)，Memcached 作為後端儲存。Web 圖片伺服器是 Lighttpd，用於 FHC (檔案處理 Cache)，後端也是 Memcached。Facebook 的 Memcached 伺服器數量差不多世界上最大了，人家連 MYSQL 伺服器還有兩千台呢。

Haystacks --大海撈針

這麼大的資料量如何進行索引? 如何快速定位檔案? 這是通過 Haystacks 來做到的。Haystacks 是使用者層抽象機制，簡單的說就是把圖片中繼資料的進行有效儲存管理。傳統的方式可能是通過 DB 來做，Facebook 是通過檔案系統來完成的。通過 GET / POST 進行讀/寫操作，應該說，這倒也是個比較有趣的思路，如果感興趣的話，看一下 GET / POST 請求的方法或許能給我們點啟發。

總體來看，Facebook 的圖片處理還是採用成本偏高的方法來做的。技術含量貌似並不大。不清楚是否對圖片作 Tweak，比如不影響圖片品質的情況下減小圖片尺寸。