海量小文件問題綜述

轉載自:http://www.taocloudx.com/index.php?a=shows&catid=4&id=15

海量小文件LOSF問題是工業界和學術界公認的難題,分析了LOSF問題的由來以及典型的應用場景,並簡要闡述了當前文 件系統在LOSF優化方面的進展。重點分析LOSF問題的根本原因,並給出具體的優化方法和策略,期望對LOSF問題的研究和優化實踐提供一定的理論指 導。

 

1、LOSF問題概述

在互聯網(尤其是移動互聯網)、物聯網、雲計算、大數據等高速發展的大背景下,數據呈現爆炸式地增長。根據IDC的預測,到2020年產生的數據量 將達到40ZB,而之前2011年6月的預測是35ZB。然而,社會化網絡、移動通信、網絡視頻音頻、電子商務、傳感器網絡、科學實驗等各種應用產生的數 據,不僅存儲容量巨大,而且還具有數據類型繁多、數據大小變化大、流動快等顯著特點,往往能夠產生千萬級、億級甚至十億、百億級的海量小文件,而且更多地 是海量大小文件混合存儲。由於在元數據管理、訪問性能、存儲效率等方面面臨巨大的挑戰性,因此海量小文件(LOSF,lots of small files)問題成爲了工業界和學術界公認的難題。

 

通常我們認爲大小在1MB以內的文件稱爲小文件,百萬級數量及以上稱爲海量,由此量化定義海量小文件問題,以下簡稱LOSF。LOSF應用在目前實 際中越來越常見,如社交網站、電子商務、廣電、網絡視頻、高性能計算,這裏舉幾個典型應用場景。著名的社交網站Facebook存儲了600億張以上的圖 片,推出了專門針對海量小圖片定製優化的Haystack進行存儲。淘寶目前應該是最大C2C電子商務網站,存儲超過200億張圖片,平均大小僅爲 15KB,也推出了針對小文件優化的TFS文件系統存儲這些圖片,並且進行了開源。歌華有線可以進行圖書和視頻的在線點播,圖書每頁會掃描成一個幾十KB 大小的圖片,總圖片數量能夠超過20億;視頻會由切片服務器根據視頻碼流切割成1MB左右的分片文件,100個頻道一個星期的點播量,分片文件數量可達到 1000萬量級。動漫渲染和影視後期製作應用,會使用大量的視頻、音頻、圖像、紋理等原理素材,一部普通的動畫電影可能包含超過500萬的小文件,平均大 小在10-20KB之間。金融票據影像,需要對大量原始票據進行掃描形成圖片和描述信息文件,單個文件大小爲幾KB至幾百KB的不等,文件數量達到數千萬 乃至數億,並且逐年增長。

 

目前的文件系統,包括本地文件系統、分佈式文件系統和對象存儲系統,都是主要針對大文件設計的,比如XFS/EXT4、Lustre、 GlusterFS、GPFS、ISLION、GFS、HDFS,在元數據管理、數據佈局、條帶設計、緩存管理等實現策略上都側重大文件,而海量小文件應 用在性能和存儲效率方面要大幅降低,甚至無法工作。針對LOSF問題,出現一些勇敢的挑戰者。EXT4主要對EXT3進行了兩方面的優化,一是inode 預分配,這使得inode具有很好的局部性特徵,同一目錄文件inode儘量放在一起,加速了目錄尋址與操作性能。因此在小文件應用方面也具有很好的性能 表現。二是extent/delay/multi的數據塊分配策略,這些策略使得大文件的數據塊保持連續存儲在磁盤上,數據尋址次數大大減少,顯著提高I /O吞吐量。因此,EXT4對於大小文件綜合性能表現比較均衡。Reiserfs對小文件作了優化,並使用B* tree組織數據,加速了數據尋址,大大降低了open/create/delete/close等系統調用開銷。Reiserfs的tail package功能可以對一些小文件不分配inode,而是將這些文件打包,存放在同一個磁盤分塊中。對於小於1KB的小文件,Rerserfs可以將數 據直接存儲在inode中。因此, Reiserfs在小文件存儲的性能和效率上表現非常出色。Facebook 推出了專門針對海量小文件的文件系統Haystack,通過多個邏輯文件共享同一個物理文件、增加緩存層、部分元數據加載到內存等方式有效的解決了 Facebook海量圖片存儲問題。淘寶推出了類似的文件系統TFS(Tao File System),通過將小文件合併成大文件、文件名隱含部分元數據等方式實現了海量小文件的高效存儲。FastDFS針對小文件的優化類似於TFS。國防 科學技術大學對Lustre進行了小文件優化工作,在OST組件中設計並實現了一種分佈獨立式的小文件Cache結構:Filter Cache,通過擴展Lustre的OST端的數據通路,在原有數據通路的基礎上,增加對小對象I/O的緩存措施,以此來改善Lustre性能。

 

對於LOSF而言,IOPS/OPS是關鍵性能衡量指標,造成性能和存儲效率低下的主要原因包括元數據管理、數據佈局和I/O管理、Cache管 理、網絡開銷等方面。從理論分析以及上面LOSF優化實踐來看,優化應該從元數據管理、緩存機制、合併小文件等方面展開,而且優化是一個系統工程,結合硬 件、軟件,從多個層面同時着手,優化效果會更顯著。

 

2、LOSF問題根源

衡量存儲系統性能主要有兩個關鍵指標,即IOPS和數據吞吐量。IOPS (Input/Output Per Second) 即每秒的輸入輸出量 ( 或讀寫次數 ) ,是衡量存儲系統性能的主要指標之一。 IOPS 是指單位時間內系統能處理的 I/O 請求數量,一般以每秒處理的 I/O 請求數量爲單位, I/O 請求通常爲讀或寫數據操作請求。隨機讀寫頻繁的應用,如 OLTP(OnlineTransaction Processing) ,IOPS 是關鍵衡量指標。另一個重要指標是數據吞吐量(Throughput),指單位時間內可以成功傳輸的數據數量。對於大量順序讀寫的應用,如 VOD(VideoOn Demand),則更關注吞吐量指標。

 

傳統磁盤本質上一種機械裝置,如FC,SAS, SATA磁盤,轉速通常爲5400/7200/10K/15K rpm不等。影響磁盤的關鍵因素是磁盤I/O服務時間,即磁盤完成一個I/O請求所花費的時間,它由尋道時間、旋轉延遲和數據傳輸時間三部分構成。因此可 以計算磁盤的IOPS= 1000 ms/ (Tseek + Troatation + Ttransfer),如果忽略數據傳輸時間,理論上可以計算出磁盤的最大IOPS。當I/O訪問模式爲隨機讀寫時,尋道時間和旋轉延遲相對於順序讀寫要明顯增加,磁盤IOPS遠小於理論上最大值。定義有效工作時間Pt= 磁盤傳輸時間/磁盤I/O服務時間,由此可知隨機讀寫單個文件效率要低於連續讀寫多個文件。對於磁盤文件系統來說,無論讀寫都存在元數據操作。以EXTx 文件系統寫數據爲例,向磁盤寫入數據進行大量的元數據操作,包括更新inode目錄、目錄、inode和數據塊位圖等。定義有效數據讀寫率Pd=所需數據/實際磁盤讀寫數據,其中實際磁盤讀寫數據爲磁盤元數據與所需數據之和。當操作連續大文件時,對元數據的操作開銷可被龐大的數據操作開銷分攤,但小文件的有效讀寫率小於大文件的,當小文件數量急劇增加時,對大量元數據的操作會嚴重影響系統的性能。

 

從上面對磁盤介質的分析可以看出,磁盤最適合順序的大文件I/O讀寫模式,但非常不適合隨機的小文件I/O讀寫模式,這是磁盤文件系統在海量小文件 應用下性能表現不佳的根本原因。前面已經提到,磁盤文件系統的設計大多都側重於大文件,包括元數據管理、數據佈局和I/O訪問流程,另外VFS系統調用機 制也非常不利於LOSF,這些軟件層面的機制和實現加劇了LOSF的性能問題。

 

(1)  元數據管理低效

由於小文件數據內容較少,因此元數據的訪問性能對小文件訪問性能影響巨大。當前主流的磁盤文件系統基本都是面向大文件高聚合帶寬設計的,而不是小文 件的低延遲訪問。磁盤文件系統中,目錄項(dentry)、索引節點(inode)和數據(data)保存在存儲介質的不同位置上。因此,訪問一個文件需 要經歷至少3次獨立的訪問。這樣,併發的小文件訪問就轉變成了大量的隨機訪問,而這種訪問對於廣泛使用的磁盤來說是非常低效的。同時,文件系統通常採用 Hash樹、 B+樹或B*樹來組織和索引目錄,這種方法不能在數以億計的大目錄中很好的擴展,海量目錄下檢索效率會明顯下降。正是由於單個目錄元數據組織能力的低效, 文件系統使用者通常被鼓勵把文件分散在多層次的目錄中以提高性能。然而,這種方法會進一步加大路徑查詢的開銷。

 

(2)  數據佈局低效

磁盤文件系統使用塊來組織磁盤數據,並在inode中使用多級指針或hash樹來索引文件數據塊。數據塊通常比較小,一般爲1KB、2KB或 4KB。當文件需要存儲數據時,文件系統根據預定的策略分配數據塊,分配策略會綜合考慮數據局部性、存儲空間利用效率等因素,通常會優先考慮大文件I/O 帶寬。對於大文件,數據塊會盡量進行連續分配,具有比較好的空間局部性。對於小文件,尤其是大文件和小文件混合存儲或者經過大量刪除和修改後,數據塊分配 的隨機性會進一步加劇,數據塊可能零散分佈在磁盤上的不同位置,並且會造成大量的磁盤碎片(包括內部碎片和外部碎片),不僅造成訪問性能下降,還導致大量 磁盤空間浪費。對於特別小的小文件,比如小於4KB,inode與數據分開存儲,這種數據佈局也沒有充分利用空間局部性,導致隨機I/O訪問,目前已經有 文件系統實現了data in inode。

 

(3)  I/O訪問流程複雜

Linux等操作系統採用VFS或類似機制來抽象文件系統的實現,提供標準統一訪問接口和流程,它提供通用的Cache機制,處理文件系統相關的所 有系統調用,與具體文件系統和其他內核組件(如內存管理)交互。VFS可以屏蔽底層文件系統實現細節,簡化文件系統設計,實現對不同文件系統支持的擴展。 VFS通用模型中有涉及四種數據類型:超級塊對象(superblock object)、索引結點對象(inode object)、文件對象(file object)和目錄項對象(dentry object),進程在進行I/O訪問過程中需要頻繁與它們交互(如下圖所示)。

進程與VFS對象交互

典型的I/O讀寫流程是這樣:open()àseek()àread()/write()àclose()。其中,文件的open()操作是一項復 雜的工作, 文件的打開操作流程大致是這樣的: 首先在當前進程的文件描述表fdtale中分配一個空的文件描述符fd , 然後在filp_cachep中創建一個file struct , 調用do_path_lookup()找到文件的inode ,取出inode的文件操作方法file_operations賦給file struct ,並調用f->f_op->open()執行打開的操作;最後根據文件描述符fd將file安裝在當前進程文件描述表fdtable對應的位 置。這樣在之後的read()/write()文件操作時, 只需要根據文件描述符fd,就可以在當前進程的描述表中找到該文件的file對象,然後調用f->f_op操作方法對文件進行操作。用戶空間使用路 徑名來表示文件,而內核中對文件的操作是依據上述四種數據類型對象,因此在open()過程中需要進行路徑查找do_path_lookup,將路徑名進 行分量解析,轉換成對應文件在內核中內部表示。這個工作相當重要,並且非常佔用系統開銷,尤其是大量頻繁open比較深目錄下的文件。

 

對於小文件的I/O訪問過程,讀寫數據量比較小,這些流程太過複雜,系統調用開銷太大,尤其是其中的open()操作佔用了大部分的操作時間。當面對海量小文件併發訪問,讀寫之前的準備工作佔用了絕大部分系統時間,有效磁盤服務時間非常低,從而導致小I/O性能極度低下。

對於大多數分佈式文件系統而言,通常將元數據與數據兩者獨立開來,即控制流與數據流進行分離,從而獲得更高的系統擴展性和I/O併發性。數據和I /O訪問負載被分散到多個物理獨立的存儲節點,從而實現系統的高擴展性和高性能,每個節點使用磁盤文件系統管理數據,比如XFS、EXT4、XFS等。因 此,相對於磁盤文件系統而言,每個節點的小文件問題是相同的。由於分佈式的架構,分佈式文件系統中的網絡通信、元數據服務MDC、Cache管理、數據布 局和I/O訪問模式等都會對IOPS/OPS性能產生影響,進一步加劇LOSF問題。

 

(1)  網絡通信開銷

相對於磁盤文件系統,分佈式文件系統客戶端與MDC和I/O服務器之間增加了網絡連接,通常爲延遲較大的TCP/IP網絡。元數據和數據訪問都經過網絡傳輸,增加了RPC網絡通信開銷,擴大了小文件訪問延時。

 

(2)  MDC管理

由於分佈式文件系統將元數據和數據分開存儲,在讀寫小文件之前,需要通過與MDC進行通信獲取位置信息。和磁盤文件系統相比,這一過程相當於額外增加一次網絡傳輸開銷和元數據服務訪問開銷。這對小文件I/O來說,開銷影響非常大。

 

(3)  數據佈局和I/O訪問模式

對於大文件,分佈式文件系統往往採用條帶化技術對文件進行切片,併發發在多個數據服務器上進行存儲,以此來提高用戶對文件訪問的併發性,從而提高對 大文件的訪問性能。而對於小文件,由於其不利於條帶化,一般採用將單個文件存儲在單個數據服務器上的策略。但當小文件數量達到一定程度後,對小文件的大量 地重複訪問將會給數據服務器帶來性能上的負擔和I/O瓶頸問題。

 

分佈式文件系統客戶端在訪問小文件I/O時,採用大文件請求相同的方式,爲每個文件訪問請求分別建立連接或者RPC請求。TCP/IP網絡在延遲和傳輸效率方面比較低,這種I/O訪問模式非常不利於小文件,I/O效率低下。

 

(4)  Cache管理

分佈式文件系統的Cache設計對小文件I/O性能作用不明顯,用戶訪問小文件時需要額外的I/O帶寬。客戶端Cache通常只對本機有效,不同客 戶端訪問同一個文件數據時,每個用戶都需要把數據複製到本地Cache中。對於小文件I/O操作來說,訪問的文件內容只佔頁內很少一部分,但也需要整個物 理頁從I/O服務端的磁盤讀入操作系統的文件緩存再訪問。從服務端讀取數據並緩存至Client端的Cache中這一過程需要額外的流量,小文件I/O越 頻繁,需要的額外總流量就越多,系統的總體I/O性能就越低。

 

總結一下,通過以上的分析我們可以看出,不管是磁盤文件系統還是分佈式文件系統,LOSF問題主要源自元數據管理、數據佈局、Cache管理、 I/O訪問流程、網絡開銷等幾個方面。因此,針對問題的根源可以施行特定的優化措施,優化思路大體分爲兩種:一是減少數據訪問次數,二是減少數據訪問時 間。具體來講,可以從合併小文件、增大Cache命中率、優化元數據管理等方面提高訪問效率,從而達到優化海量小文件存儲的效果。同時,可以結合硬件和應 用優化,進一步增強優化效果。

 

3、LOSF優化策略

海量小文件由於數量巨大,而且通常需要進行共享和併發訪問,目前通常採用分佈式系統進行存儲,包括分佈式文件系統和分佈式對象存儲系統,每個存儲節 點底層採用磁盤文件系統進行管理。因此這裏重點介紹分佈式存儲系統的LOSF優化策略。前面我們已經提到,Haystack, TFS, FastDFS, Lustre等分佈式存儲系統在LOSF方面的優化工作實踐,結合上面對LOSF問題根源的剖析,我們認爲硬件優化、Cache管理優化、小文件合併存 儲、元數據管理優化等是幾種行之有效的優化方法。當然,性能優化沒有黃金法則,必須是在對現有系統充分的測試和分析的基礎上,有針對性地選擇合適的優化策 略,方能有實質性優化效果。

 

3.1硬件優化

如果不考慮成本問題,硬件優化是最爲直接有效的優化方法,按照減少數據訪問時間的優化思路,採用更高性能的硬件來提高LOSF性能。比如,使用速度 更快的SSD作爲全部或部分存儲介質,部分部署時作爲分層存儲或者Cache加速,可以顯著提高隨機讀寫場景下的IOPS/OPS性能;採用處理能力更強 或更多的CPU,可以提高系統的I/O處理速度和併發性;配置更大空容量的內存,以空間換時間,有效提高數據緩存命中率;採用延遲更小、帶寬更高的網絡設 備優化網絡傳輸效率,比如萬兆網絡或InfiniBand網絡;部署多路徑I/O通道提高數據吞吐量和併發訪問,如LAN網絡和SAN網絡。硬件優化的目 標是消除I/O物理通道上的瓶頸,保證理論上的性能最大化,爲軟件層面的優化工作做鋪墊。值得一提的是,硬件設備在性能上要做到匹配,尤其是磁盤和網絡, 否則容易導致性能瓶頸或者成本浪費。

 

3.2Cache管理

Cache技術廣泛應用於存儲系統的各個領域,比如CPU L1/L2 Cache、文件系統、分佈式存儲系統等。Cache技術主要通過空間換時間的策略,利用數據訪問的時間和空間局部性,儘量提高數據訪問的緩存命中率,從 而提高系統的性能。存儲系統中的Cache位於最低層存儲介質之上,其中緩存了應用程序需要的數據子集。對子集中的數據的讀寫先在Cache中異步進行, 然後異步存儲到低層穩定的介質上。Cache技術通過這種異步的數據I/O模式來解決程序中的計算速度和數據存儲速度不匹配的鴻溝,減少了訪問底層存儲介 質的次數,使存儲系統的性能大大提高。增大Cache容量可以緩存更多的數據,減小cache的容量失效,從而顯著提高Cache命中率。但cache的 命中率並不隨着容量呈線性增長,當cache容量達到一定閾值時,再增大容量命中率並不會顯著提高,因此要根據成本和實際需要來選擇cache容量。

 

分佈式存儲系統中,多個存儲節點、元數據服務以及客戶端都通過物理網絡互聯,客戶端和服務器端都會進行數據緩存。根據節點上Cache資源工作方式 的不同,分佈式存儲系統中的Cache分爲分佈獨立式 Cache和協作式Cache。分佈獨立式Cache中,每個存儲節點上的文件系統Cache只負責緩存本節點上的I/O數據,Cache中數據的一致性 和Cache資源分配等工作由本節點上的Cache管理器負責。這種Cache管理簡單,不影響系統的整體結構,系統增刪存儲節點後,也不需要做額外的 Cache配置和管理工作。協作式Cache中,每個存儲節點上的Cache不僅負責緩存本節點上的I/O數據,還負責緩存其他節點上的Cache數據。 協作式Cache需要各節點之間能夠快速的通信,因此存儲節點之間的網絡帶寬必須足夠大。協作式Cache能夠充分利用Cache資源,構造容量更大的全 局Cache,可以實現Cache資源的負載均衡。兩種Cache方式相比較,分佈獨立式Cache簡單、擴展性高,協作式Cache管理複雜、對網絡要 求高,但是Cache命中率能夠大幅提高,對分佈式存儲系統整體性能提高更加明顯。另外,分佈式存儲系統中客戶端緩存會減弱服務器端緩存的局部性,導致基 於局部性的LRU緩存替換算法效果不佳,或者多級cache系統部重複緩存。因此,在緩存替換算法方面需要進行特別的優化設計,綜合考慮訪問最近性、時間 局部性、空間局部性、文件關聯等因素。

 

Cache技術利用了數據訪問的時間局部性,對訪問過的數據進行暫時的保留。但由於緩衝空間大小以及更新算法的制約,當數據頻繁更新時。緩存帶來的 性能改善不再顯著。對於小文件,可以根據局部性原理和I/O訪問行爲,預測最近可能訪問的文件集合,提前預讀到Cache系統中,通過減少文件讀取時間提 高存儲系統性能。許多系統把數據訪問請求當作是獨立的事件,實際上數據請求並非完全隨機,而是由用戶或程序的行爲驅動的,存在特定的訪問模式。而這種模式 常常被緩存系統所忽略。預取是主動緩存技術,它利用了數據的空間局部性,對將來可能發生的數據請求進行預測,在訪問之前取出並緩存,以備用戶訪問,從而減 少訪問延遲。預測技術主要通過對數據本體或歷史訪問記錄的分析,構造合適的預測模型,據此對未來的訪問進行預測。用戶執行應用程序去訪問數據,連續訪問的 不同文件之間必然存在一定的關聯。當用戶以先前大致相同的順序去請求數據時,或多或少會訪問相同的文件集合,尤其對同一個用戶來說。正確的預測可以提高系 統的性能,而錯誤的預測不僅會造成緩存空間和I/O帶寬的浪費,而且會增加正常訪問的延時。

 

3.3 小文件合併存儲

小文件合併存儲是目前優化LOSF問題最爲成功的策略,已經被包括Facebook Haystack和淘寶TFS在內多個分佈式存儲系統採用。它通過多個邏輯文件共享同一個物理文件,將多個小文件合併存儲到一個大文件中,實現高效的小文 件存儲。爲什麼這種策略對LOSF效果顯著呢?

 

首先,減少了大量元數據。通過將大量的小文件存儲到一個大文件中,從而把大量的小文件數據變成大文件數據,減少了文件數量,從而減少了元數據服務中 的元數據數量,提高了元數據的檢索和查詢效率,降低了文件讀寫的I /O操作延時,節省了大量的數據傳輸時間。LOSF元數據開銷所佔比重大,大幅減少元數據,將直接導致性能的顯著提升。合併後的大文件存儲在磁盤文件系統 之上,同時也大大降低了磁盤文件系統在元數據和I/O方面的壓力,這點可以改善每個節點的存儲性能。小文件的元數據和數據會一併存儲在大文件中,並形成索 引文件,訪問時通過索引進行定位。索引文件採用預加載到Cache的策略,可以實現隨機讀寫小文件只需要一次I/O。

 

其次,增加了數據局部性,提高了存儲效率。磁盤文件系統或者分佈式文件系統中,文件的元數據和數據存儲在不同位置。採用合併存儲機制後,小文件的元 數據和數據可以一併連續存儲大文件中,這大大增強了單個小文件內部的數據局部性。小文件合併過程中,可以利用文件之間的空間局部性、時間局部性以及關聯, 儘量將可能連續訪問的小文件在大文件中進行連續存儲,增強了小文件之間的數據局部性。這直接降低了磁盤上隨機I/O比率,轉換成了順序I/O,能夠有效提 高I/O讀寫性能。另外,小文件單獨存儲會形成外部和內部碎片,而合併存儲後存儲碎片將大大降低,這極大提高了LOSF存儲效率。

 

再次,簡化了I/O訪問流程。採用小文件合併存儲後,I/O訪問流程發生了極大變化,主要體現在存儲節點磁盤文件系統上。根據之前的闡述,磁盤文件 系統讀寫一個小文件,最大的系統消耗在open系統調用,需要進行路徑查找do_path_lookup,將路徑名進行分量解析,轉換成對應文件在內核中 內部表示。這個過程非常佔用系統開銷,尤其是深目錄下的文件。而經過合併,很多小文件共享一個大文件,open操作轉換成了開銷小很多的seek操作,根 據索引定位到大文件內部相應位置即可,也不需要在內核中創建相關VFS數據對象,這節省了原先絕大部分的系統開銷。

 

大文件加上索引文件,小文件合併存儲實際上相當於一個微型文件系統。這種機制對於WORM(Write Once Read Many)模式的分佈式存儲系統非常適合,而不適合允許改寫和刪除的存儲系統。因爲文件改寫和刪除操作,會造成大文件內部的碎片空洞,如果進行空間管理並 在合適時候執行碎片整理,實現比較複雜而且產生額外開銷。如果不對碎片進行處理,採用追加寫的方式,一方面會浪費存儲容量,另一方面又會破壞數據局部性, 增加數據分佈的隨機性,導致讀性能下降。此外,如果支持隨機讀寫,大小文件如何統一處理,小文件增長成大文件,大文件退化爲小文件,這些問題都是在實際處 理時面臨的挑戰。

 

3.4元數據管理優化

分佈式存儲系統架構大致分兩種,即有中心架構和無中心架構。在有中心架構的分佈式存儲系統中,通常有一個元數據服務器MDC來統一管理元數據。而在 無中心的架構中,元數據會分散存儲於各個存儲節點上,通過一致性Hash等算法進行管理和定位。客戶端在讀寫小文件數據之前,需要通過與MDC或存儲節點 進行通信獲取位置信息,這一過程相當於額外增加一次網絡傳輸開銷和元數據服務訪問開銷。這對小文件I/O來說,開銷影響非常大,尤其是對於延遲較大的網絡 而言。因此,元數據管理優化主要從減少元數據量、減少元數據訪問次數、提高元數據檢索效率等幾個方面着手。

 

對於單個小文件,元數據包括位置信息、名稱、guid、屬主、大小、創建日期、訪問日期、訪問權限等信息。在分佈式存儲系統中,根據訪問接口和語義 需要,可以對元數據進行精簡,保留足夠的元數據即可,從而達到減少元數據的目的。比如,TFS/FastDFS通過在文件命名中隱含位置信息等部分元數 據,對象存儲系統可以不需要訪問日期、訪問權限等元信息,從而節省了元數據量。這帶來的好處是,可以減少元數據通信延遲,相同容量的Cache可以緩存更 多的元數據,從而提高元數據的訪問效率。

 

前面剛剛提到TFS/FastDFS在文件名中隱含了位置信息,無需與MDC或存儲節點交互就能夠對文件進行定位,減少了一次元數據訪問。元數據操 作在小文件整個I/O過程佔了大部分時間,對於大量併發元數據操作,可以對多個RPC請求進行合併,從而大幅減少元數據訪問次數。最爲重要的,可以在客戶 端對元數據進行緩存,利用Cache中元數據訪問的時間局部性,結合預讀策略, 顯著減少元數據訪問次數。每一次元數據訪問都會產生可觀的網絡開銷,因此降低元數據訪問次數,能夠有效提高元數據操作效率。

 

在MDC上或者存儲節點上,元數據最終持久化存儲在數據庫、KV存儲系統、磁盤文件系統目錄上,甚至是單個文件中。同時,爲了提高訪問性能,會將部 分或者全部元數據緩存在Cache中。爲了達到高效的元數據檢索,需要考慮大容量內存和快速磁盤(比如SAS磁盤或SSD),Cache系統採用可擴展性 Hash等高效數據結構組織緩存的元數據。同時,還可以通過多級索引、BloomFilter等減少元數據操作過程的I/O訪問次數,進一步加快元數據訪 問速度。

 

4、總結

隨着互聯網、物聯網、雲計算、大數據等技術的發展,海量小文件LOSF問題成爲了學術界和工業界研究的熱點。Facebook和Taobao等緊密 結合各自的業務應用特點,在海量小圖片存儲系統優化方面取得了非常不錯的成績,成功支撐了數百億級別的線上圖片存儲。由於LOSF優化需要深入結合業務數 據特點,優化效果才能顯著,因此優化策略和方法難以普遍適用,不可推而廣之。本文從LOSF問題的源起談起,重點分析LOSF問題根源,然後給出優化策略 和方法,提出硬件優化、Cache管理優化、小文件合併存儲、元數據管理優化等是幾種行之有效的優化方法,期望對LOSF問題的研究和優化實踐提供一定的 理論和方法指導,而非具體的實踐技術。值得一提的是,性能優化沒有黃金法則,必須是在對現有系統充分的測試和分析的基礎上,有針對性地選擇合適的優化策 略,方能有實質性優化效果。

 

5、參考資料

[1] Findinga needle in Haystack: Facebook’s photo storage

[2]FaceBook vs Taobao圖片存儲解決方案

[3] 分佈式文件系統小文件性能優化技術研究與實現

[4] 海量小文件存儲文件系統研究綜述

發佈了112 篇原創文章 · 獲贊 187 · 訪問量 192萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章