大量小文件存儲,如何選擇存儲方案?

半溪


海量小文件是業界難題,甚至有專門的名詞,LOSF(lots of samll file)。通常我們認為大小在1MB以內的文件稱為小文件,百萬級數量及以上稱為海量文件,由此量化定義海量小文件。

在互聯網(尤其是移動互聯網)、物聯網、雲計算、大數據等高速發展的大背景下,數據呈現爆炸式地增長。海量小文件的應用在生活中已越來越常見,社會化網絡、移動通信、網絡視頻音頻、電子商務、傳感器網絡、科學實驗等各種應用產生的數據,不僅存儲容量巨大,而且數據類型繁多、數據大小變化幅度大、流動快等顯著特點,往往能夠產生千萬級、億級甚至十億、百億級的海量小文件。如何構建高效存儲訪問和備份恢復的小文件管理是目前海量數據存儲所面臨的一個重要問題。

對於LOSF而言,IOPS/OPS是關鍵性能衡量指標,造成性能和存儲效率低下的主要原因包括海量文件的元數據管理、存儲介質性能限制等方面。

元數據來說,雖然小文件得數據量小,但是每個數據的元數據量不變。導致文件系統的元數據量非常龐大,因此元數據對於小文件得訪問效率影響非常大。磁盤文件系統使用塊來組織磁盤數據,並在inode中存儲索引文件數據塊。數據塊通常比較小,一般為1KB、2KB或4KB。當文件需要存儲數據時,文件系統根據預定的策略分配數據塊,分配策略會綜合考慮數據局部性、存儲空間利用效率等因素,通常會優先考慮大文件I/O帶寬。對於特別小的小文件,比如小於4KB,inode與數據分開存儲,這種數據佈局也沒有充分利用空間局部性,導致隨機I/O訪問。

隨著目前存儲技術的發展,可以從存儲介質(硬盤 or SSD)、存儲方式(對象 or 文件系統)兩個主要角度出發做針對小文件場景的方案選擇:

1、存儲介質方案選擇:從機械硬盤到SSD

SSD無疑是從存儲介質層面提升海量小文件存儲性能的利器。單盤幾萬的IOPS,甚至採用nvme協議後能達到單盤幾十萬的IOPS,高IOPS能非常好的提升海量小文件檢索效率。奈何SSD價格還是高高在上,無法大規模普及。但隨著NAND flash的發展,SSD取代機械硬盤是肯定的事。

但是光從存儲介質層面入手還不能完全解決問題。由於目前的文件系統往往是針對大文件設計的,比如ext3,btrfs,ntfs等文件系統在大文件時表現往往可以,但是海量小文件場景時性能也會出現下降。這種情況其實是文件系統跟不上硬件的性能,只有針對海量小文件做了特殊優化的文件系統配合高性能的SSD才能夠更好的解決該問題。

2、數據存儲方式方案選擇

(1)對象存儲

對象存儲是近幾年新發展出來的全新存儲使用協議。對象存儲最明顯的特點就是,一般無用戶使用界面,不像常見的posix協議的文件系統可以直接操作文件。用戶存儲文件和獲取文件採用url的方式。可以比如,存儲一個數據的時候用put,獲取用get。對象存儲不像文件系統一樣可以無縫兼容各種業務程序,而是需要業務程序調整自己的讀寫接口為對象標準,從而給實際落地應用帶來了一定的門檻。

對象存儲目前有多種開源版本:swift,ceph,minio等。

對象存儲,也叫做基於對象的存儲,是用來描述解決和處理離散單元的方法的通用術語,這些離散單元被稱作為對象。就像文件一樣,對象包含數據,但是和文件不同的是,對象在一個層結構中不會再有層級結構。每個對象都在一個被稱作存儲池的扁平地址空間的同一級別裡,一個對象不會屬於另一個對象的下一級。

比如Ceph通過Crush算法做數據分佈。不使用文件系統時,系統無需配置元數據服務(MDS),這時系統無需管理龐大的元數據,避免了元數據服務成為瓶頸;

但是由於機械硬盤的本身限制,往往在使用的時候,都會配置SSD盤作為緩存盤提供系統整體IOPS。同時業務系統也得由於使用對象存儲系統而修改IO讀寫的訪問接口,這對於很多用戶來說是很難以接受的方案。

(2)分佈式文件系統

文件系統作為平常最常見的存儲方式,還是受廣大的用戶喜歡。但是傳統NAS具有機頭瓶頸,海量小IO的併發下性能會很差。分佈式存儲發展起來後,通過橫向擴展,方便的解決傳統存儲帶來的瓶頸問題。

一般來說文件系統一定需要元數據,每次數據的讀寫都會涉及到元數據的訪問或者修改。所以元數據服務器的還是會成為分佈式文件系統處理海量小文件時的瓶頸。

目前一般廠家的產品會採用多種方式來解決分佈式文件系統面臨海量小文件的場景:

1) 元數據節點集群技術:通過將文件系統的元數據進行分佈式存儲,讓多臺元數據節點同時提供元數據存儲和檢索服務,能夠大幅度提升元數據的併發檢索效率。

2) 小文件聚合技術:此技術是目前場景下使用比較好的一種方法。比如淘寶的TFS和Facebook的hashstack,都採用了類似的技術,提供海量圖片的訪問。通過將多個小文件聚合成一個大文件進行存儲實現高效的文件存儲。聚合的方式大大減少了系統的元數據操作,而且將小文件的讀寫方式從隨機變為了順序更好的發揮磁盤的性能。這種方式非常適合一次寫入後數據讀寫少量的場景,因為數據聚合後的讀需要先定位大文件,然後從大文件中定位小文件。寫入的時候便沒有這種消耗。

3) 緩存技術:Cache技術其實廣泛的應用各種場景。類似hashstack進行了多級的緩存,在分佈式存儲中,將元數據儘可能的緩存在內存中能大大提高元數據的訪問效率。但是當數據讀寫頻繁時,緩存的命中比較考量算法。

3、總結

隨著數字世界的不斷龐大,海量小文件場景越來越常見。我們也看到業界很多產品通過各種方式的優化,支持百億級別的數據訪問。但是LOSF問題是公認的難題,需要針對不同的業務場景進行專門的優化,一個產品沒法吃遍天下。也希望大家有更多的想法可以一起分享,歡迎評論留言。



神行科技


關鍵看怎麼使用這些文件。

像網站那樣上傳後不要求使用原文件名,由後臺自動重新命名,讀取時都是明確指定文件鏈接,沒有遍歷操作,一次讀取整個文件的場景的。可以使用那種對文件名進行hash運算,按算法結果決定存儲位置的文件系統。讀取時對文件名進行hash就能確定該從哪裡讀取。避免了普通文件系統搜索文件分配表這樣低效率的操作。使用對象存儲也是一個不錯的辦法,相當於存儲到一個數據庫中。可以利用數據庫的內存緩存和索引優化提高讀取速度。

如果想用傳統posix規範文件系統那樣隨機讀取文件數據,需要保留原文件名,需要目錄和遍歷功能的情況。可以使用帶元數據服務的文件系統。這個元數據服務相當於數據庫形式的文件分配表,存儲了各文件的存儲位置。讀取文件時就先向元數據服務器查詢出該從哪裡取出文件,再從相應位置取出文件。


nohead


1、Raid02、固態硬盤3、Fat32:拷貝大量小文件(如拷貝照片、文檔轉移等)速度很快,但不支持存儲單個大於4GB的文件。NTFS:支持大文件存儲,管理性能比Fat32強很多,但是拷貝大量小文件時速度較慢。


分享到:


相關文章: