網址: http://www.dbanotes.net/arch/facebook_photos_arch.html
好幾個地方看到這個 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，比如不影響圖片質量的情況下減小圖片尺寸。
--EOF--