好幾個地方看到這個 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 億張。
儲存寫入
儘管這麼大的量，似乎寫入並不是問題。如上圖，是直接通過 nfs 寫的。
讀取圖中的 cachr 這個元件，應該是用來訊息通知(基於調整過的 evhttp的嘛)，memcached 作為後端儲存。web 伺服器是 lighttpd，用於 fhc (檔案處理 cache)，後端也是 memcached。facebook 的 memcached 伺服器數量差不多世界上最大了，人家連 mysql 伺服器還有兩千臺呢。
haystacks --大海撈針
這麼大的資料量如何進行索引? 如何快速定位檔案? 這是通過 haystacks 來做到的。haystacks 是使用者層抽象機制，簡單的說就是把元資料的進行有效的儲存管理。傳統的方式可能是通過 db 來做，facebook 是通過檔案系統來完成的。通過 get / post 進行讀/寫操作，應該說，這倒也是個比較有趣的思路，如果感興趣的話，看一下 get / post 請求的方法或許能給我們點啟發。
總體來看，facebook 的處理還是採用成本偏高的方法來做的。技術含量貌似並不大。不清楚是否對作 tweak，比如不影響質量的情況下減小尺寸。
--eof--
海量資料處理
1 有一千萬條簡訊，有重複，以文字檔案的形式儲存，一行一條，有 重複。請用5分鐘時間，找出重複出現最多的前10條。方法1 可以用雜湊表的方法對1千萬條分成若干組進行邊掃瞄邊建雜湊表。第一次掃瞄，取首位元組，尾位元組，中間隨便兩位元組作為hash code，插入到hash table中。並記錄其位址和...
海量資料處理
給定a b兩個檔案，各存放50億個url，每個url各占用64位元組，記憶體限制是4g，如何找出a b檔案共同的url？答案 可以估計每個檔案的大小為5g 64 300g，遠大於4g。所以不可能將其完全載入到記憶體中處理。考慮採取分而治之的方法。遍歷檔案a，對每個url求取hash url 1000...
海量資料處理
分而治之 hash對映 hash統計 堆 快速 歸併排序 300萬個查詢字串中統計最熱門的10個查詢。針對此類典型的top k問題，採取的對策往往是 hashmap 堆。hash統計 先對這批海量資料預處理。具體方法是 維護乙個key為query字串，value為該query出現次數的hashtab...