海量小文件存儲

[轉自:http://www.fuchaoqun.com/2009/04/deal-with-tons-of-small-files/]

Web2.0網站，數據內容以幾何級數增長，尤其是那些小文件，幾K～幾百K不等，數量巨多，傳統的文件系統處理起來很是吃力，很多網站在scaling的過程中都遇到了這樣的問題：磁盤IO過高；備份困難；單點問題，容量和讀寫無法水平擴展，還存在故障的可能。

YouTube也碰到這樣的問題，每一個視頻有4個縮微圖，這樣的話縮微圖數量是視頻數量的四倍，想象一下YouTube有多少視頻，看一下他們遇到的問題：

• 大量的磁盤尋址，在操作系統層面出現inodes cache和page cache的問題
• 單個目錄文件數限制，尤其是Ext3文件系統，采用目錄分級的做法，最新的Linux Kernel 2.6優化了Ext3文件系統，單目錄能存儲的文件數提高了100倍，但是把所有的文件存一個目錄不是一個好的方法
• 高RPS（requests per second每秒請求數），因為一個頁面可能要顯示60個縮微圖
• 高負載下Apache性能差
• Apache前面加一層Squid，能抗一會，但負載上來之后，性能下降厲害，由300RPS降到20RPS
• 嘗試lighttpd，但是lighttpd是單線程，多線程的話也有問題，線程之間緩存不能共享
• 加一臺服務器的話需要24小時，因為文件數太多了
• 存在“冷卻”的問題，重啟服務器后需要6～10個小時才能緩存好

YouTube的解決方案是Google的BigTable，一般人沒戲。（原文參見：http://www.hfadeel.com/Blog/?p=127）

Facebook也遇到了同樣的問題，他們的方案參見：http://www.dbanotes.net/arch/facebook_photos_arch.html，他們經歷了三個階段：

NFS共享，掛一個盤陣，APP服務器通過NFS讀寫

加一個中間層Cachr：eventHttp + memcached(lighttpd + mod_memcache實現同樣的功能)，后端還是通過NFS連盤陣

Haystacks，詳細的去讀這里（E文）。

對于一般的網站來說，實用的方案有哪些呢？

一、NFS共享

是的，這個有很多問題，但實施成本低，很多公司都在用（我們也在用），在不是那么多文件，不是那么高并發的情況下還是很不錯的，設置Hash目錄，不要讓一個目錄下文件數過多，對于一般的網站來說足夠用了。

備份確實是一個問題，如果不是海量的話，根據文件更新時間每天增量備份＋周期性的全量備份應該可以。

二、文件存數據庫

真有人這么做，手機之家用MySQL建了256個表來存儲超過1T的文件，前端加一個多級緩存（具體未知，也許就是memcached也許還是文件），數據庫做數據備份用，他們用起來覺得還不錯。

或者覺得MySQL太重，試試key->value的數據庫，比如BDB，Tokyo Cabinet等。

三、分布式文件系統

開源的很多，好看簿用的是MogileFS，與memcached師出同門。傲游用MFS來存儲用戶的收藏夾文件，詳細文章參見：分布式文件系統MFS(moosefs)實現存儲共享(一) 、(二)，據說數百萬輕松處理。

分布式文件系統好處是可以均衡讀寫壓力，數據可靠性大大增加，某個數據節點掛了也沒事。

還不行？自己DIY一個去吧，豆瓣就這么做的，TokyoCabinet做為底層存儲，封裝了一個memcached協議接口（與Tokyo Tyrant何異？），一致性哈希，應用程序根據哈希規則在node中讀寫數據:

DoubanFS結構圖，版權由charlee所有

轉載于:https://www.cnblogs.com/mazhenyu/archive/2013/03/16/2963292.html

總結

以上是生活随笔為你收集整理的海量小文件存储的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。