作為歡聚集團(tuán)旗下品牌,BIGO當(dāng)前的業(yè)務(wù)涵蓋直播,短視頻和社交,目前已經(jīng)服務(wù)于全球150個(gè)國(guó)家4億用戶。BIGO的產(chǎn)品業(yè)務(wù)特性決定了其對(duì)海量小文件的存儲(chǔ)需求,如內(nèi)容審核截圖,用戶社交溝通過程中發(fā)送的小文件,用戶的頭像等。目前BIGO每天會(huì)新增約幾十億個(gè)小文件,占用約30TB存儲(chǔ)空間。對(duì)于海量小文件存儲(chǔ),如何在保證高性能的同時(shí)降低存儲(chǔ)的成本,成為BIGO存儲(chǔ)團(tuán)隊(duì)必須解決的問題。

01海量小文件存儲(chǔ)的挑戰(zhàn)

為了解決海量小文件的存儲(chǔ)問題,必須采用分布式存儲(chǔ),目前分布式存儲(chǔ)主要采用兩種架構(gòu):集中式元數(shù)據(jù)管理架構(gòu)和去中心化架構(gòu)。

(1)集中式元數(shù)據(jù)架構(gòu):

典型的集中式元數(shù)據(jù)架構(gòu)的分布式存儲(chǔ)有GFS,HDFS,MooseFs等。其采用的典型架構(gòu)如下圖1所示:

此架構(gòu)主要包含3個(gè)部分:

1)客戶端:主要用于提供訪問分布式存儲(chǔ)系統(tǒng)的接口;

2) 元數(shù)據(jù)服務(wù)器:主要用于存放分布式存儲(chǔ)系統(tǒng)的命名空間和文件的一些元數(shù)據(jù)信息。

3)存儲(chǔ)服務(wù)器: 主要負(fù)責(zé)存儲(chǔ)文件的具體數(shù)據(jù)。

使用集中式的元數(shù)據(jù)管理的方式,其主要優(yōu)點(diǎn)如下:

1) 元數(shù)據(jù)的操作性能高: 存儲(chǔ)系統(tǒng)的命令空間和文件的元數(shù)據(jù)都存放在元數(shù)據(jù)服務(wù)器上,元數(shù)據(jù)操作如list directory和create file等元數(shù)據(jù)的操作性能會(huì)比較高;

2) 擴(kuò)容時(shí)不需要數(shù)據(jù)遷移:元數(shù)據(jù)服務(wù)器上存放有所有文件的位置信息,在集群需要擴(kuò)容增加新的節(jié)點(diǎn)時(shí),這些位置信息不需要變動(dòng),因此集群在擴(kuò)容時(shí)不需要進(jìn)行數(shù)據(jù)遷移。

其主要缺點(diǎn)如下:

1) 元數(shù)據(jù)節(jié)點(diǎn)是瓶頸:客戶端在訪問文件數(shù)據(jù)之前通常都需要到元數(shù)據(jù)節(jié)點(diǎn)上查詢文件的位置信息,因此元數(shù)據(jù)節(jié)點(diǎn)不可避免地成為了整個(gè)系統(tǒng)的性能瓶頸。

2) 文件的數(shù)量受限:為了提高性能,元數(shù)據(jù)節(jié)點(diǎn)中的數(shù)據(jù)一般都會(huì)保存到內(nèi)存中,而元數(shù)據(jù)節(jié)點(diǎn)的內(nèi)存不是無限增長(zhǎng)的。

基于以上缺點(diǎn),集中式的元數(shù)據(jù)管理方式非常不適合于海量小文件的存儲(chǔ)。

(2)    去中心化架構(gòu):

為了解決集中式元數(shù)據(jù)架構(gòu)的問題,去中心化架構(gòu)的分布式存儲(chǔ)產(chǎn)生,典型的去中心化分布式存儲(chǔ)有GlusterFs,Ceph等。其采用的典型的架構(gòu)如下圖2所示:

此架構(gòu)主要包含3個(gè)部分:

1) 客戶端: 主要用于提供訪問分布式存儲(chǔ)系統(tǒng)的接口。

2) 存儲(chǔ)服務(wù)器:主要負(fù)責(zé)存儲(chǔ)文件的具體數(shù)據(jù)和元數(shù)據(jù)。

去中心化架構(gòu)沒有單獨(dú)的元數(shù)據(jù)節(jié)點(diǎn)去保存文件的命名空間和元數(shù)據(jù),元數(shù)據(jù)依然存儲(chǔ)在存儲(chǔ)節(jié)點(diǎn)上,文件的尋址一般采用DHT(一致性HASH)的方式計(jì)算。此架構(gòu)一般會(huì)將多個(gè)存儲(chǔ)節(jié)點(diǎn)進(jìn)行邏輯分組,組內(nèi)復(fù)制保證數(shù)據(jù)可靠性,因此會(huì)有可選的中心端服務(wù)器保存整個(gè)集群的存儲(chǔ)節(jié)點(diǎn)以及分組信息。例如Ceph使用Ceph monitor保存整個(gè)集群的成員和狀態(tài)信息(不保存文件信息),而GlusterFs選擇將這些信息存放在所有的存儲(chǔ)節(jié)點(diǎn)上。

使用去中心化的的方式,其主要優(yōu)點(diǎn)如下:

1)無單點(diǎn)的性能瓶頸: 沒有單獨(dú)的元數(shù)據(jù)節(jié)點(diǎn),客戶端可以直接通過Hash的方式尋址文件,直接到存儲(chǔ)節(jié)點(diǎn)上訪問。

2) 文件的數(shù)量幾乎不受限制: 沒有單獨(dú)的元數(shù)據(jù)節(jié)點(diǎn),理論上文件的數(shù)量不受中心端節(jié)點(diǎn)容量的限制。

3) 讀寫性能更高: 讀寫請(qǐng)求不用到元數(shù)據(jù)節(jié)點(diǎn)上尋址而采用Hash計(jì)算的方式,理論上性能更高。

從以上優(yōu)點(diǎn)可以得出去中心化的架構(gòu)還是比較適合海量小文件的存儲(chǔ)。由于GlusterFs的存儲(chǔ)節(jié)點(diǎn)采用Linux本地文件系統(tǒng)存儲(chǔ)數(shù)據(jù),沒有對(duì)小文件的讀寫進(jìn)行優(yōu)化,而Ceph從Jewel版本開始引入BlueStore存儲(chǔ)引擎,對(duì)海量小文件的讀寫有較大的優(yōu)化,因此我們選擇使用Ceph存儲(chǔ)海量小文件。

Ceph相對(duì)其他的分布式存儲(chǔ)更適合海量小文件的存儲(chǔ),但還是有幾個(gè)問題待解決:

1) Index數(shù)據(jù)量太大:海量小文件會(huì)導(dǎo)致bucket index中的數(shù)據(jù)量增長(zhǎng)過快,從而導(dǎo)致bucket index需要經(jīng)常resharding,而在bucket index resharding過程中會(huì)阻塞讀寫請(qǐng)求,對(duì)于大多數(shù)不需要list bucket的場(chǎng)景,此問題可以通過使用indexless bucket解決。對(duì)于必須bucket index的場(chǎng)景,增加了順序分布的bucket index優(yōu)化解決方案,此方案不在本文的討論范圍內(nèi),會(huì)在后面的文章中進(jìn)行介紹。

2) 擴(kuò)容時(shí)需要數(shù)據(jù)遷移:Ceph在數(shù)據(jù)擴(kuò)容的過程中,需要對(duì)文件的位置進(jìn)行重新哈希,并會(huì)帶來大量的數(shù)據(jù)遷移操作,數(shù)據(jù)遷移過程中會(huì)帶來巨大的性能損耗。同時(shí)海量小文件的數(shù)據(jù)遷移會(huì)耗費(fèi)較長(zhǎng)的時(shí)間,如果在此過程中磁盤故障或機(jī)器故障,數(shù)據(jù)恢復(fù)的時(shí)間將不確定,會(huì)帶來極大的數(shù)據(jù)安全風(fēng)險(xiǎn)。

3) 存儲(chǔ)效率問題:Ceph默認(rèn)的最小分配單元為64KB,而當(dāng)前小文件的平均size為15KB。為了提高存儲(chǔ)效率,可以將最小分配單元調(diào)整為4KB(讀寫性能會(huì)隨之降低)。當(dāng)使用糾刪碼的方式存儲(chǔ)存儲(chǔ)小文件,如(4+2)的糾刪碼,此時(shí)文件的最小分配單元變?yōu)? * 4KB = 24KB。為了提高存儲(chǔ)效率而采用糾刪碼的方式存儲(chǔ)小文件,反而更加浪費(fèi)存儲(chǔ)資源。

為了解決Ceph存儲(chǔ)海量小文件的問題,需要設(shè)計(jì)一個(gè)滿足以下目標(biāo)的系統(tǒng):

1) 高性能:分布式存儲(chǔ)系統(tǒng)需要承載終端用戶的讀寫需求,低延時(shí)地滿足用戶對(duì)數(shù)據(jù)的存取需求,是任何分布式存儲(chǔ)系統(tǒng)的重要目標(biāo)。

2)擴(kuò)容時(shí)避免大量的數(shù)據(jù)遷移: 避免大量的數(shù)據(jù)遷移操作增加對(duì)存儲(chǔ)系統(tǒng)的負(fù)載,從而影響存儲(chǔ)系統(tǒng)對(duì)終端用戶的服務(wù)質(zhì)量,也是該系統(tǒng)設(shè)計(jì)的重要目標(biāo)。

3) 加快故障恢復(fù)速度: 機(jī)器故障或磁盤故障會(huì)導(dǎo)致數(shù)據(jù)遷移,海量小文件導(dǎo)致故障恢復(fù)緩慢,故障恢復(fù)的時(shí)間越長(zhǎng),在此期間其他機(jī)器或磁盤發(fā)生故障的概率越大,數(shù)據(jù)丟失的風(fēng)險(xiǎn)越大,因此加快故障的恢復(fù)速度也是系統(tǒng)設(shè)計(jì)的目標(biāo)之一。

4) 提升存儲(chǔ)效率: 海量的小文件會(huì)占用大量的存儲(chǔ)資源,同時(shí)大量的文件經(jīng)過一段時(shí)間后就會(huì)變成冷數(shù)據(jù),如何提升存儲(chǔ)效率降低存儲(chǔ)成本也是系統(tǒng)設(shè)計(jì)的目標(biāo)之一。

02系統(tǒng)設(shè)計(jì)

目前業(yè)界解決海量小文件存儲(chǔ)主要有以下的解決幾種優(yōu)化方式:

1) 硬件優(yōu)化: 海量小文件的讀寫請(qǐng)求,瓶頸一般在機(jī)械硬盤上。硬件優(yōu)化主要是采用支持隨機(jī)讀寫的SSD硬盤代替機(jī)械硬盤,可以顯著提高海量小文件的讀寫性能。但是考慮到成本因素,在數(shù)據(jù)量很大的情況下SSD硬盤一般只會(huì)在系統(tǒng)做作為Cache存在。

2) 文件元數(shù)據(jù)管理優(yōu)化:分布式存儲(chǔ)系統(tǒng)中文件的元數(shù)據(jù)包含文件的位置信息,文件的size,創(chuàng)建時(shí)間等。在讀寫小文件之前,都需要先得到文件的元數(shù)據(jù)信息,例如需要得到文件的位置信息才能到對(duì)應(yīng)的存儲(chǔ)節(jié)點(diǎn)上讀寫文件數(shù)據(jù),只有拿到文件的size才能知道需要讀取數(shù)據(jù)的長(zhǎng)度。為了減小訪問元數(shù)據(jù)的開銷,應(yīng)該盡量減少元數(shù)據(jù)的數(shù)量,元數(shù)據(jù)的數(shù)量越少,cache命中率越高,性能越高。

3) 小文件合并成大文件: 通過將大量的小文件合并成一個(gè)大文件,可以顯著減少文件的數(shù)量,也就減少了元數(shù)據(jù)的數(shù)量,元數(shù)據(jù)的查詢會(huì)更快。對(duì)于大文件機(jī)械硬盤可以做到順序讀寫,可以顯著降低硬盤的負(fù)載。

本系統(tǒng)結(jié)合以上的方式設(shè)計(jì)了一種基于雙層存儲(chǔ)池的小文件合并優(yōu)化方案解決Ceph海量小文件存儲(chǔ)的問題,其系統(tǒng)設(shè)計(jì)如下圖3所示:

系統(tǒng)分為兩級(jí)存儲(chǔ)池,分別是高性能SSD副本存儲(chǔ)池和大容量(副本/EC)存儲(chǔ)池。可以配置不同的存儲(chǔ)策略,將不同bucket或不同size的文件寫到不同的存儲(chǔ)池上。對(duì)于海量小文件優(yōu)先寫到高性能存儲(chǔ)池中,這樣可以保證小文件讀寫的高性能。

然后通過配置策略,開啟合并功能將高性能存儲(chǔ)池中的小文件合并成大文件存儲(chǔ)到大容量存儲(chǔ)池中。當(dāng)大容量存儲(chǔ)池中的空閑空間不足時(shí),增加新的存儲(chǔ)節(jié)點(diǎn)創(chuàng)建新的大容量存儲(chǔ)池,而不是對(duì)已有的存儲(chǔ)池進(jìn)行擴(kuò)容,這樣可以避免大量的數(shù)據(jù)遷移操作對(duì)終端用戶的讀寫請(qǐng)求產(chǎn)生影響。

對(duì)于大容量存儲(chǔ)池,可以通過EC方式存儲(chǔ),提升已合并的文件的存儲(chǔ)效率。由于存儲(chǔ)的是大文件,最小分配單元可以調(diào)整的比較大,如:128KB,這樣可以減小BlueStore中的元數(shù)據(jù)的數(shù)量,提升性能。

03

對(duì)于以上的系統(tǒng)設(shè)計(jì),在具體實(shí)現(xiàn)上主要包含以下幾個(gè)關(guān)鍵問題。

3.1 小文件的合并方式

將大文件看做一個(gè)Volume,每個(gè)小文件占其中的一個(gè)部分空間,如下圖4所示:

將小文件順序的追加到Volume中,每個(gè)小文件在Volume中分成3個(gè)部分:

1) Header: 保存文件的一些元數(shù)據(jù)信息,如文件名,文件size,文件的校驗(yàn)信息,在Volume中的offset。

2)Data: 小文件的實(shí)際數(shù)據(jù)內(nèi)容。

3)Footer: 保存固定的magic,做校驗(yàn)用。

3.2 數(shù)據(jù)從高性能存儲(chǔ)池遷移到大容量存儲(chǔ)池

將數(shù)據(jù)從高性能存儲(chǔ)池遷移到大容量存儲(chǔ)的具體方式,如下圖5所示:

存儲(chǔ)網(wǎng)關(guān)的操作日志會(huì)記錄當(dāng)前存儲(chǔ)網(wǎng)關(guān)上的操作,操作日志按照bucket和時(shí)間存放,遷移工具可以按照不同的bucket策略(如延遲遷移的時(shí)間間隔)去讀取當(dāng)前bucket的操作日志文件。具體的遷移流程可分成4個(gè)步驟:

1) 讀取操作日志: 根據(jù)bucket的遷移策略,讀取操作日志文件并解析每個(gè)操作,得到文件的名稱和一些操作信息。為了支持并行的遷移,可以將文件名通過hash方式放到多個(gè)隊(duì)列中。

2) 讀取文件內(nèi)容: 從隊(duì)列中的得到待處理的文件名,從高性能存儲(chǔ)池中讀取文件的數(shù)據(jù)。

3) 小文件數(shù)據(jù)寫到大容量存儲(chǔ)池: 從大容量存儲(chǔ)池中申請(qǐng)一個(gè)Volume,將當(dāng)前的小文件追加到Volume中,按照Header,Data,Footer的順序遷移文件。

4) 刪除高性能存儲(chǔ)池中的文件數(shù)據(jù): 刪除高性能存儲(chǔ)池中的文件數(shù)據(jù),只是將數(shù)據(jù)清空,保留文件的元數(shù)據(jù)信息,并在元數(shù)據(jù)中添加當(dāng)前小文件在Volume中的位置信息,方便后面讀取數(shù)據(jù)時(shí)的檢索。

3.3 文件讀取

在文件的數(shù)據(jù)被遷移到大容量存儲(chǔ)池后,存儲(chǔ)網(wǎng)關(guān)讀取數(shù)據(jù)的流程也會(huì)隨之變化,如下圖6所示:

     此時(shí)文件的數(shù)據(jù)內(nèi)容存儲(chǔ)在大容量存儲(chǔ)池中,文件的元數(shù)據(jù)和文件內(nèi)容的位置信息存放在高性能存儲(chǔ)池中,因此在讀取數(shù)據(jù)內(nèi)容之前,存儲(chǔ)網(wǎng)關(guān)要先到高性能存儲(chǔ)池中讀取文件的位置信息。從讀取流程上看,相對(duì)于直接在大容量存儲(chǔ)池中存儲(chǔ)小文件增加了一次網(wǎng)絡(luò)往返的開銷,但是該方案有以下幾個(gè)優(yōu)點(diǎn):

1) 大量的熱數(shù)據(jù)已經(jīng)在高性能存儲(chǔ)池中完成了讀取操作,遷移到大容量存儲(chǔ)中的一般是冷數(shù)據(jù),讀取的請(qǐng)求會(huì)少很多。

2)  文件元數(shù)據(jù)的讀取還是在高性能存儲(chǔ)池中進(jìn)行的,性能相對(duì)直接在大容量存儲(chǔ)池中好很多。

3) 該方案大容量存儲(chǔ)池BlueStore的分配單元較大,BlueStore的元數(shù)3.4文件的刪除和空間回收

文件的刪除需要?jiǎng)h除文件的數(shù)據(jù)內(nèi)容和文件的元數(shù)據(jù)兩個(gè)部分,文件的元數(shù)據(jù)在高性能存儲(chǔ)池中存放可以直接刪除,而文件的數(shù)據(jù)內(nèi)容只是大容量存儲(chǔ)池中Volume的一部分,不能直接刪除回收存儲(chǔ)空間,因此將文件的刪除和空間回收分開進(jìn)行。

在服務(wù)終端用戶的刪除請(qǐng)求時(shí),在Volume中找到對(duì)應(yīng)的文件Header,并寫入一個(gè)刪除標(biāo)記,表示文件已經(jīng)刪除不能訪問,并修改當(dāng)前Volume的有效size信息(實(shí)際存在的文件的size總和),后續(xù)作為開始空間回收的判斷依據(jù)。如下圖7所示:

假設(shè)紅色的Header表示當(dāng)前的文件已經(jīng)被標(biāo)記為刪除。根據(jù)空間回收策略,如有效空間相對(duì)Volume存儲(chǔ)空間的占比小于50%,表明已經(jīng)刪除的空間占比超過50%,此時(shí)需要對(duì)Volume進(jìn)行Compaction操作,方法如下:

1) 掃描整個(gè)Volume里面的每個(gè)文件,如果已經(jīng)刪除直接跳過這個(gè)文件。

2) 如果是沒有被刪除的文件,將文件的內(nèi)容追加到新的Volume中,并修改高性能存儲(chǔ)池中文件的元數(shù)據(jù),修改位置信息重新指向新Volume中的位置。

3) 整個(gè)Volume掃描完成,有效文件遷移完畢后,刪除當(dāng)前的Volume大文件。

除了文件刪除操作,文件修改操作也需要回收老的數(shù)據(jù)內(nèi)容占用的空間,采用類似的方法。在處理修改的操作日志時(shí),將舊數(shù)據(jù)內(nèi)容的Header標(biāo)記為刪除,在后續(xù)Compaction操作時(shí)回收這部分?jǐn)?shù)據(jù)空間。

04評(píng)價(jià)

為了驗(yàn)證此設(shè)計(jì)方案的優(yōu)化效果,在相同的網(wǎng)絡(luò)環(huán)境上搭建了兩套分布式存儲(chǔ)系統(tǒng):

優(yōu)化前系統(tǒng):

1) 3臺(tái)服務(wù)器,每臺(tái)部署5個(gè)機(jī)械硬盤存儲(chǔ)節(jié)點(diǎn),最小分配單元4KB。

2) 在15個(gè)存儲(chǔ)節(jié)點(diǎn)上創(chuàng)建一個(gè)大容量3副本存儲(chǔ)池。

優(yōu)化后系統(tǒng):

1) 3臺(tái)服務(wù)器,每臺(tái)部署5個(gè)機(jī)械硬盤存儲(chǔ)節(jié)點(diǎn)和一個(gè)SATA SSD存儲(chǔ)節(jié)點(diǎn),最小分配單元64KB。

2) 在15個(gè)存儲(chǔ)節(jié)點(diǎn)上創(chuàng)建一個(gè)大容量3副本存儲(chǔ)池,在3個(gè)SATA SSD存儲(chǔ)節(jié)點(diǎn)上創(chuàng)建一個(gè)高性能3副本存儲(chǔ)池。

3) 設(shè)置高性能存儲(chǔ)池中的小文件在寫入2小時(shí)后,自動(dòng)遷移到大容量存儲(chǔ)池中,大容量存儲(chǔ)池中的volume size默認(rèn)為4MB。

可以從以下幾個(gè)方面評(píng)價(jià)該設(shè)計(jì)方案的優(yōu)化效果:

4.1熱數(shù)據(jù)的讀寫性能

在海量小文件數(shù)據(jù)還沒有遷移到大容量存儲(chǔ)池之前的性能比較。

(1) 寫入性能:

如下圖8所示,分別在多種不同并發(fā)情況下寫入1000萬20KB文件的性能測(cè)試結(jié)果:

     由于高性能存儲(chǔ)池采用的存儲(chǔ)硬件是SATA SSD,雖然高性能存儲(chǔ)池只有3個(gè)存儲(chǔ)節(jié)點(diǎn),大容量存儲(chǔ)池有15個(gè)存儲(chǔ)節(jié)點(diǎn),優(yōu)化后系統(tǒng)的寫入QPS依然達(dá)到優(yōu)化前的3倍。

(2) 讀取性能:

如下圖9所示,分別在多種不同并發(fā)情況下讀取1000萬 20KB文件的性能測(cè)試結(jié)果:

可以看到優(yōu)化后系統(tǒng)的讀取QPS相對(duì)優(yōu)化前提高20%～30%,沒有達(dá)到寫入的優(yōu)化效果主要是存儲(chǔ)節(jié)點(diǎn)緩存的作用。

4.2冷數(shù)據(jù)的讀取性能

數(shù)據(jù)在高性能存儲(chǔ)池中寫入后,按照策略數(shù)據(jù)變冷會(huì)遷移到大容量存儲(chǔ)池中,優(yōu)化前和優(yōu)化后(小文件合并之后)的讀取性能對(duì)比結(jié)果如下圖10所示:

     由于小文件合并之后,文件的讀取需要先到高性能存儲(chǔ)池中讀取元數(shù)據(jù),然后到大容量存儲(chǔ)池中讀取文件的數(shù)據(jù),實(shí)際上多經(jīng)過了一次網(wǎng)絡(luò)RTT,因此會(huì)導(dǎo)致一定的讀取性能下降,從結(jié)果看讀取QPS下降了約12%。后續(xù)系統(tǒng)會(huì)采用性能更好的NVME SSD搭建高性能存儲(chǔ)池進(jìn)行測(cè)試。

4.3存儲(chǔ)效率提升

在優(yōu)化后的系統(tǒng)中,在小文件合并前與合并后,存儲(chǔ)資源的使用情況如下圖11所示:

合并前最小存儲(chǔ)單元是64KB,因此一個(gè)20KB的文件也需要占用64KB的存儲(chǔ)空間,而且是3副本,因此不算元數(shù)據(jù)需要的存儲(chǔ)空間是:64KB * 3 * 10000000 = 1831GB。

合并之后的Volume size是4MB,1個(gè)20KB的文件,只需要占據(jù)20KB的數(shù)據(jù)存儲(chǔ)空間加上少量元數(shù)據(jù)的存儲(chǔ)空間,因此不算元數(shù)據(jù)需要的存儲(chǔ)空間是:20KB * 3 * 10000000 = 572GB。

因此合并之后的存儲(chǔ)效率是合并之前存儲(chǔ)效率的3倍多。

4.4故障恢復(fù)速度

同樣的1000萬文件,下線1個(gè)存儲(chǔ)節(jié)點(diǎn),此時(shí)會(huì)導(dǎo)致數(shù)據(jù)遷移恢復(fù)數(shù)據(jù),完全采用默認(rèn)的配置,優(yōu)化前和優(yōu)化后耗費(fèi)的數(shù)據(jù)恢復(fù)時(shí)間如下圖12所示:

由于優(yōu)化后大容量存儲(chǔ)池中只存放大文件,因此其恢復(fù)速度比較快,從結(jié)果看優(yōu)化后的故障恢復(fù)速度是優(yōu)化前的16倍。

05結(jié)論

本文分析了使用Ceph存儲(chǔ)海量小文件的挑戰(zhàn)和一些問題,并從硬件優(yōu)化,元數(shù)據(jù)管理優(yōu)化和小文件合并優(yōu)化幾個(gè)層面考慮并設(shè)計(jì)實(shí)現(xiàn)了一套基于雙層存儲(chǔ)池的小文件合并優(yōu)化分案,通過比較可以發(fā)現(xiàn)新方案在讀寫性能,存儲(chǔ)效率以及故障恢復(fù)速度上都有較大的提升。