Facebook存儲65億張照片的存儲框架

Facebook存儲65億張照片的存儲框架

 

從未用過Facebook，可是仍是對Facebook應對大容量的非結構化數據存儲方案感興趣。本文是經過在線網絡廣播(webcast)經本人翻譯得來的，所以，本人並不能確保本文中敘述的內容與原文webcast不存在誤差。

 

本文嚴禁在未徵得本人贊成的狀況下以任何形式進行轉載。本人直接受在郵件中的轉載申請，如需轉載，請發送郵件至 betteryou@126.com。

 

Facebook概況

?         Facebook目前擁有65億張照片，每張照片分別會保存爲4~5種尺寸的文件，因此大概會有300億個文件，大約佔據540TB的存儲空間。

?         Facebook平均的請求流量是475,000張圖片/秒；其中，關於概況(Profile)的照片請求量大約是200,000張/秒。

?         Facebook每週大約會收到1億次上載請求。

因此，Facebook須要在海量的數據存儲中高效讀取和存儲數據。Facebook目前有25名開發工程師負責開發，他們大部分的工做都集中在如何讓Facebook的數據庫性能更優化，如何讓Facebook的數據庫可擴展性更好，等等方面的工做上。

 

目前，Facebook擁有數千臺服務器(雖然webcast的片子上有一則新聞說已經達到10,000臺服務器，但webcast上Jason仍是說的是數千臺??thousands of servers)，這些服務器大部分都有明確的分工，各司其職；使用MySQL數據庫；PHP運行在Apache上，而且用C開發了一些擴展和封裝；在Facebook的應用層和數據庫層之間，他們使用了Memcached技術，做爲緩存。

 

小貼士：何謂Memcached？

Memcached是首先由Danga Interactive爲Live Journal開發的通用分佈式內存緩存系統。它一般經過將對象和數據緩存至內存的方法來加快動態數據庫驅動網站的速度，減小了數據庫訪問的次數。Memcached缺乏安全認證特性，這就意味着它必須在正確配置的防火牆內運行。Memcached的API提供了分佈在多臺計算機上的巨大哈希表(Hash Table)。當哈希表滿了以後，新插入的數據會使用LRU算法(最近最少使用算法)將較老的數據擦洗掉。YouTube、LiveJournal、Wikipedia、SourceForge、Facebook、NYTimes.com等知名網站都使用了Memcached。

 

 

Facebook當前存儲架構

 

注：我暫且稱之爲當前存儲架構，緣由有二：第一是webcast的PPT當中出現的是」State of the World」字樣，代表如今的情況；第二是新的存儲架構Haystack並未在webcast中明確表示已經進入生產環境。如描述有錯誤，歡迎各位積極指正。

 

Facebook的存儲架構須要應對兩方面的問題：讀和寫。咱們分開來觀察。

 

寫：

 

 

當用戶須要上載照片，也就是對Facebook的存儲進行寫入操做的時候，Facebook會指定一臺上載服務器來進行工做。上載服務器會對上載的照片進行處理，每張照片會按照4~5種不一樣的尺寸進行存儲。

 

讀：

 

當用戶須要對照片進行讀取時，架構會稍微複雜一些：

 

 

 

當用戶點擊某張照片後，請求將經過HTTP傳到CDN (Content Delivery Network)，CDN中已經緩存了一些照片，若是請求的照片在CDN中，就能夠將照片返回給用戶。若是照片未在CDN中，那麼就有兩種狀況發生。

• 若是請求的是普通照片，則請求會傳遞到不一樣的照片服務器(Photo Server)，照片服務器去讀取後臺Netapp存儲的數據。
• 若是請求的是基本資料(Profile)上的照片，那麼讀取該照片的請求會到一個叫「Cachr」，Cachr是一個超輕量級的服務器，專門負責緩存基本資料相關的照片。若是在Cachr中依然沒有找到照片，就須要經過照片服務器(Photo Server)去讀取後臺Netapp存儲的數據了。

 

目前，Facebook的Cachr可擴展性和穩定性良好，對基本資料(Profile)上照片的請求大概在200,000次/秒，佔總請求數量的一半還強，Facebook大約有40個Cachr節點，運行了4年多，並未出現大問題。照片服務器(Photo Server)採用文件處理緩存(File Handle Cache)技術，旨在提升照片的讀取性能。

 

架構上的問題

 

剛纔簡單介紹了整個Facebook存儲架構，但這個架構存在着一些問題：

• 第一，不管是Netapp仍是別的文件系統都會形成元數據(metadata)爆炸性增加。他們使用一個文件一個元數據(metadata)的方式，並且每一個文件系統都強制使用目錄等層次性結構，這樣就勢必增長了與真正所需數據無關的內容。因此，對於Facebook來講，大約須要進行3次磁盤IO才能成功讀取一張圖片(在剛剛設計之初，IO的次數須要達到15次，因此3次已是很是優化的結果了)。
• 第二，正是因爲對文件系統中圖片讀取的代價增大，因此Facebook不得不更加依賴於高效的數據緩存來解決磁盤IO形成的矛盾。目前，Facebook的CDN中的基本資料訪問命中率達99.8%，普通圖片的訪問命中率達92%，這樣才下降了對文件系統的訪問量

 

Haystack

 

Facebook引入Haystack的緣由是爲了減小元數據(metadata)的使用。對於Haystack來講，能夠將一些圖片捆綁在一塊兒，而後這些文件統一使用一個單獨的元數據(metadata)。那麼這樣的話，怎麼可以保證真正從這些文件中讀取到真正須要的數據呢？Haystack使用獨立索引文件來對文件系統的數據創建索引。因此這樣的話，就能夠經過索引裏的鍵(Key)指向所須要的圖片文件了。一般，1GB的圖片數據須要RAM中的1M元數據(metadata)內存緩存。由於Haystack能確保索引內容確定駐留在RAM中，因此Facebook就能確保對每張圖片的IO次數最多爲1次。

 

Haystack的存儲模式

 

Haystack在磁盤上表現爲一系列重複的數據塊，包含數據頭(Header)和數據段(Segment)兩個部分。下圖是Facebook中使用Haystack的存儲方式。

 

下圖是Haystack中的索引狀況：

其中，start表明了在Haystack文件系統中該文件的起始地址，length就是文件的長度。

 

新的存儲架構

 

若是放棄使用Netapp，轉而使用Haystack，那麼Facebook的讀取場景就會發生必定的變化。咱們從新來觀察一下：

 

寫：

 

讀取：

 

原webcast觀看：Facebook ? Needle in a Haystack: Efficient Storage of Billions of Photos