MUSE：一種面向云存儲系統(tǒng)的高性能元數(shù)據(jù)存儲引擎

段翰聰，向小可，呂鵬程

?

MUSE：一種面向云存儲系統(tǒng)的高性能元數(shù)據(jù)存儲引擎

段翰聰，向小可，呂鵬程

(電子科技大學(xué)計算機(jī)科學(xué)與工程學(xué)院 成都 611731)

該文設(shè)計了一種高性能的面向云存儲系統(tǒng)的元數(shù)據(jù)存儲引擎(MUSE)。首先，其底層物理存儲模塊采用LSM-tree模型的高速key-value存儲引擎LevelDB方案，通過設(shè)計多緩存表和多線程緊湊機(jī)制對該方案進(jìn)行優(yōu)化，使其可以充分利用內(nèi)存和多核CPU并行能力；其次，提出了基于多I/O通道的元數(shù)據(jù)存取調(diào)度機(jī)制。通道之間讀寫操作隔離，聚合多個通道為上層提供高并發(fā)隨機(jī)I/O讀寫能力；MUSE能夠很好地適應(yīng)海量小文件存儲場景，相對于其他元數(shù)據(jù)存儲系統(tǒng)在性能上有顯著的提升。

I/O; LSM-tree; 海量; 元數(shù)據(jù); 性能; 小文件; 存儲引擎

隨著互聯(lián)網(wǎng)服務(wù)數(shù)量和數(shù)據(jù)量的激增，需要存儲的非結(jié)構(gòu)化數(shù)據(jù)量也在快速增長。傳統(tǒng)的存儲方案不能滿足海量文件服務(wù)，因此可擴(kuò)展的分布式存儲系統(tǒng)應(yīng)運(yùn)而生，但是元數(shù)據(jù)的存儲策略一直是分布式存儲系統(tǒng)性能的瓶頸。

從對磁盤介質(zhì)的分析看出，磁盤最適合順序的大文件I/O方式，而不適合隨機(jī)的小文件I/O方式，然而目前大多數(shù)的分布式存儲系統(tǒng)的元數(shù)據(jù)組織都是針對大文件存儲和可靠性[1]進(jìn)行設(shè)計的，因此基于海量小文件的應(yīng)用在性能和存儲效率方面要大幅降低，甚至無法工作。以下是目前存儲系統(tǒng)在海量小文件情況下元數(shù)據(jù)管理存在的問題：

1) 由于文件的inodes在磁盤中隨機(jī)存儲，訪問文件時，路徑中所有目錄分量的inodes都需要被讀取，這將生成大量的磁盤隨機(jī)I/O。

2) 存儲系統(tǒng)元數(shù)據(jù)管理通常采用hash、B+樹來組織索引目錄，這種方法在目錄存在大量文件情況下檢索效率明顯下降，無法做到有效的擴(kuò)展。

3) 本地文件系統(tǒng)使用塊來組織磁盤數(shù)據(jù)，當(dāng)數(shù)據(jù)內(nèi)容尺寸小于數(shù)據(jù)塊的小文件時，造成大量磁盤空間浪費(fèi)、緩存利用率極低。

4) 隨著計算機(jī)硬件的發(fā)展，多CPU核心和多存儲設(shè)備的機(jī)器越來越流行，而當(dāng)前的分布式存儲系統(tǒng)并沒有充分利用多CPU核心和存儲設(shè)備的性能。

本文設(shè)計和實(shí)現(xiàn)了一種存儲系統(tǒng)元數(shù)據(jù)存儲引擎來解決上面的問題，試圖在數(shù)據(jù)存儲體系上提高數(shù)據(jù)訪問的性能，從而適應(yīng)海量小文件的存儲場景。

1 相關(guān)工作

存儲系統(tǒng)元數(shù)據(jù)存儲已經(jīng)有很長的研究歷史，其中一些元數(shù)據(jù)管理的工作是非常有代表性的。

1.1 分布式文件系統(tǒng)元數(shù)據(jù)管理模型

GFS[2]和HDFS[3]的優(yōu)點(diǎn)在于大文件的讀操作、續(xù)寫操作的性能很高。但是，為了不使元數(shù)據(jù)服務(wù)器磁盤I/O成為系統(tǒng)瓶頸，二者都將元數(shù)據(jù)全部保持在內(nèi)存，而這使得內(nèi)存大小成為整個系統(tǒng)擴(kuò)展的瓶頸。并行文件系統(tǒng)如PVFS[4]支持條帶化數(shù)據(jù)分布來獲取高傳輸速度并減小文件元數(shù)據(jù)的大小，同時PVFS使用BerkeleyDB做元數(shù)據(jù)服務(wù)器的底層存儲引擎，而BerkeleyDB采用B+tree作為索引模型；總之，在海量數(shù)據(jù)處理中，傳統(tǒng)的存儲方式將導(dǎo)致非常低的讀寫性能。

1.2 數(shù)據(jù)存儲模型

針對海量小文件場景，ops/sec是衡量元數(shù)據(jù)存儲系統(tǒng)性能最關(guān)鍵的因素，因此可以借鑒數(shù)據(jù)庫的索引組織方式。

關(guān)于單機(jī)數(shù)據(jù)存儲索引模型，最為經(jīng)典的是B+樹模型，它通過降低樹的層次來減少I/O次數(shù)從而提高I/O效率。在B+樹中順序插入大量條目，速度非常快，因?yàn)槊看味紩谧詈笠粋€節(jié)點(diǎn)上順序插入；如果有隨機(jī)的插入、更新、刪除等，會出現(xiàn)大量隨機(jī)I/O，每當(dāng)更新一個條目，則該條目所在的節(jié)點(diǎn)上的其他條目同樣會被I/O，因此在上層隨機(jī)讀取或更新文件時會造成大量無效的隨機(jī)I/O操作。

LSM-tree[5]模型使用基于內(nèi)存的緩沖區(qū)來緩存更新操作，并且更新操作都被當(dāng)做一個標(biāo)記條目插入內(nèi)存，直到某個閾值后批量刷入磁盤，在磁盤文件到達(dá)一定閾值后進(jìn)行緊湊操作：多個舊文件的條目整合，之后按序生成一個新文件到磁盤。批量寫策略使得它比B+樹更加高效。越來越多的數(shù)據(jù)庫使用LSM-tree做索引，其中最著名的分布式系統(tǒng)有BigTable[6][7]和LevelDB[8]。LevelDB是google公司開發(fā)的key-value存儲庫。LevelDB在LSM-tree基礎(chǔ)上做了很多創(chuàng)新來增強(qiáng)讀性能，如引入層次機(jī)制，將緩存的更新條目持久化到磁盤，而磁盤數(shù)據(jù)通過緊湊算法依次從低層刷入高層，因此層次越高生成的文件數(shù)目越少，數(shù)據(jù)越老。通過層次機(jī)制可以限制生成的數(shù)目，并且加速讀操作。同時通過使用Bloom Filter[9]來減少需要搜索持久化文件的數(shù)量。但是如何能結(jié)合現(xiàn)代機(jī)器多核多盤的優(yōu)勢對LSM-tree模型進(jìn)行改進(jìn)，是一個挑戰(zhàn)。

Fractal-tree模型是Buffer-tree[10]的一個變種，它同樣將更新操作看做消息存儲到相應(yīng)節(jié)點(diǎn)的相應(yīng)消息緩沖區(qū)：即更新時候?qū)⑾⒎湃雛oot節(jié)點(diǎn)之后即完成更新操作，當(dāng)root節(jié)點(diǎn)相應(yīng)的消息緩沖區(qū)滿后，消息被自上而下逐步下刷和整理到葉子節(jié)點(diǎn)。但是目前該模型的工程實(shí)現(xiàn)尚不成熟，基于Fractal-tree做索引的產(chǎn)品只有TokuDB[11-13]。

2 設(shè)計與實(shí)現(xiàn)

2.1 系統(tǒng)綜述

本文所述的元數(shù)據(jù)存儲引擎來自于自行研發(fā)的分布式文件系統(tǒng)cloud store(CSTORE)。整個系統(tǒng)由數(shù)據(jù)存儲服務(wù)器、元數(shù)據(jù)存儲服務(wù)器、規(guī)則服務(wù)器、客戶端4個部分組成?？蛻舳送ㄟ^FUSE向用戶提供近似POSIX文件系統(tǒng)接口，訪問文件時客戶端先從元數(shù)據(jù)服務(wù)器MUSE讀取文件元數(shù)據(jù)，然后根據(jù)文件元數(shù)據(jù)信息從數(shù)據(jù)服務(wù)器中獲取具體的文件數(shù)據(jù)，而規(guī)則服務(wù)器負(fù)責(zé)數(shù)據(jù)服務(wù)器集群的負(fù)載均衡。

單機(jī)存儲模型層次如圖1所示，整個元數(shù)據(jù)存儲引擎分為3層：1) Key-Value存儲引擎層；2) 命名空間管理層；3) 通道處理層。當(dāng)網(wǎng)絡(luò)I/O層接收到文件訪問請求，會將請求下發(fā)給通道處理層；通道處理層根據(jù)一定策略將請求分發(fā)給特定管道；特定管道接收到請求后對請求的路徑名進(jìn)行解析，從而定位到文件Inode對應(yīng)的key下發(fā)給key-value存儲引擎層；最后key-value存儲引擎層通過key讀取相應(yīng)的value從而找到該文件的元數(shù)據(jù)。

圖1 單機(jī)存儲模型層次

2.2 Key-Value存儲引擎層

由于LevelDB數(shù)據(jù)索引采用LSM-tree模型，相對于其他模型有很大的性能優(yōu)勢，因此選用LevelDB做底層物理存儲引擎。為了達(dá)到極限性能，在LevelDB原有的基礎(chǔ)上作進(jìn)一步的優(yōu)化。由于LevelDB同一時間只允許有一個緩存表提供服務(wù)，在高速插入條目的情況下，緩存表插入速度與緊湊操作速度相差太大會導(dǎo)致緩存表溢出但還來不及持久化，此時LevelDB會睡眠導(dǎo)致整體性能下降。本文采用開辟多個緩存表來解決這個問題。另外，LevelDB只啟用一個線程進(jìn)行緊湊操作，因此在LevelDB全負(fù)荷運(yùn)行時最多只能利用2個CPU核心，因此將緊湊操作改為多線程，充分利用多核CPU。通過在LevelDB的基礎(chǔ)上進(jìn)行改進(jìn)后形成的key-value存儲引擎作為元數(shù)據(jù)的本地存儲能將元數(shù)據(jù)的更新操作轉(zhuǎn)換為大量結(jié)構(gòu)化數(shù)據(jù)的插入，這極大地減少了磁盤尋道時間。

2.3 命名空間管理層

2.3.1 路徑分割映射

一般通用的場景下，文件的新建、更新、刪除、修改文件名、目錄名、目錄列表都需要得到良好高效的支持，使用LevelDB條目的value域來記錄文件或目錄的元數(shù)據(jù)。普通文件元數(shù)據(jù)信息包括：名稱、版本、權(quán)限、創(chuàng)建時間、修改時間、類型、大小和文件片信息；目錄元數(shù)據(jù)信息主要包括：目錄名稱、權(quán)限、創(chuàng)建時間、修改時間、大小。文件名稱直接反映為用戶命名空間顯示的文件名稱。文件類型主要用于區(qū)分普通文件和目錄。文件塊信息是一個列表，存儲了該文件所有的文件塊信息。每個表項(xiàng)包含這個文件塊的SHA-1校驗(yàn)值，使用這個校驗(yàn)值可以定位到存儲這個塊的數(shù)據(jù)服務(wù)器。

為了加快目錄列表操作，利用LevelDB的key全局排序特性，路徑分割映射策略key、value格式如圖2a所示，將條目的Key格式化為3部分：父目錄Inode號、文件名稱、類型。依次解釋這3個字段的用意為：1) 使用父目錄Inode號作為第一部分意味著同一目錄下的條目在邏輯上會被連續(xù)存儲。2) 第二部分直接設(shè)置為文件名稱而非文件Inode號，因?yàn)樵谕荒夸浵虏豢赡艹霈F(xiàn)文件名相同的多個文件，因此在同一目錄下文件名可以唯一指示一個文件，更重要的是當(dāng)用文件名代替Inode號，可以在列表操作中減少一次路徑分量解析的過程，從而加速列表操作。3)考慮到一些文件或目錄的部分屬性被會比另一部分屬性更加頻繁的被更新，如修改時間、訪問時間和文件大小被修改的次數(shù)遠(yuǎn)遠(yuǎn)大于創(chuàng)建時間、擁有者、訪問權(quán)限等屬性，因此將第三部分設(shè)置為類型字段，類型=1代表需要被頻繁修改的屬性；類型=2代表很少被修改的屬性；類型=3代表永遠(yuǎn)不會被修改的屬性。這樣可以減少每次元數(shù)據(jù)更新時的I/O數(shù)據(jù)量以及日志記錄的數(shù)據(jù)量。

路徑分割映射策略如圖2b所示。讀取路徑為“/foo/bar/file”的文件的元數(shù)據(jù)時，首先會從已知的Inode號為0的root目錄“/”開始逐個解析路徑分量：遍歷key第一部分為“0”的key-value對，直到找到第二部分為“bar”的key-value對，則在其value中讀取“/foo/bar”的Inode號為1，再遍歷key第一部分為“1”的key-value對，直到找到第二部分為“file”的key-value對，即可得到“/foo/bar/file”的元數(shù)據(jù)信息。經(jīng)過測試發(fā)現(xiàn)，這種路徑分割映射方式在一般通用的場景會比傳統(tǒng)的文件系統(tǒng)在性能上有很大的提高。

a. 路徑分割映射策略key、value格式 b. 路徑分割映射策略示例

圖2 路徑分割映射方式的命名空間管理

2.3.2 全路徑映射

當(dāng)文件所在的路徑層次很深時，海量文件處理中路徑分量的解析工作會相當(dāng)繁重，本文提出了另一種路徑映射方法：全路徑映射方法。a 全路徑映射策略key、value格式如圖3a所示，將條目的Key格式化為2部分：文件的完整路徑和類型。依次解釋這2個字段的用意為：1) 使用文件的完整路徑作為Key的第一部分使得可以僅僅訪問LevelDB一次即可得到相應(yīng)文件或目錄的元數(shù)據(jù)，使得可以完全拋棄路徑分量解析的繁重工作。2) 使用類型字段作為第二部分的用意與前面路徑分割映射方式的意圖完全相同。條目Value的值同樣與前面路徑分割映射方式的完全相同。

全路徑映射策略如圖3b所示，在讀取路徑為”/foo/bar/file”的文件的頻繁修改的元數(shù)據(jù)，則直接可以讀取Key為”/foo/bar/file-1”的Value值即可。但是當(dāng)遇到更改某一目錄的文件名操作的請求時，由于該目錄下所有條目的key中都存儲了該目錄的舊目錄名，因此該目錄下的所有條目的key都需要被更新，這無疑是全路徑映射的一個缺點(diǎn)。因此本文建議在目錄深度超過3時需要超高性能且不存在頻繁更改目錄文件名的場景中使用全路徑映射方式，而在一般通用的場景中使用路徑分割映射方式來部署元數(shù)據(jù)服務(wù)器。在本文的系統(tǒng)中默認(rèn)使用路徑分割映射方式，用戶可以在配置文件中修改為全路徑映射方式。

a. 全路徑映射策略key、value格式 b. 全路徑映射策略示例

圖3 全路徑映射方式的命名空間管理

2.4 通道處理層

CPU和磁盤帶寬最容易成為元數(shù)據(jù)服務(wù)器的性能瓶頸，目前很多已存在的系統(tǒng)在設(shè)計上并沒有充分利用多核CPU和多磁盤帶寬，如對數(shù)據(jù)存儲位置沒有太多的考量而直接存儲在磁盤的邏輯分區(qū)，這無疑加重了磁盤的隨機(jī)I/O而導(dǎo)致磁盤性能下降。

本文提出通道機(jī)制來解決這個問題。通道是指將獨(dú)立的CPU核心、獨(dú)立的物理磁盤進(jìn)行綁定而形成的獨(dú)立數(shù)據(jù)存儲管道。每個通道可以獨(dú)立進(jìn)行數(shù)據(jù)I/O，多個I/O通道的讀寫相互隔離。因此，通道中的I/O請求不受其它請求的影響。引入通道機(jī)制后，可以在每個通道上只部署單一底層存儲引擎，最大程度減小磁盤的隨機(jī)I/O。通道方案支持針對服務(wù)器的不同硬件配置信息來指定多個通道共同服務(wù)。

當(dāng)引入了多通道，隨之而來的問題就是通道間的負(fù)載均衡如何保證。這里采用調(diào)度算法[14]，將到來的新建文件元數(shù)據(jù)請求均勻的分散到各個通道，平衡各通道壓力。

3 評估測試

通過一系列的測試用例來評估元數(shù)據(jù)存儲引擎的性能。該引擎將在多個元數(shù)據(jù)服務(wù)器多磁盤環(huán)境下進(jìn)行測試。測試條件如下：元數(shù)據(jù)服務(wù)器MUSE、規(guī)則服務(wù)器、客戶端均運(yùn)行在由8臺服務(wù)器通過GigE NIC相連接而組成的集群中。每臺服務(wù)器由16核心CPU、8塊15 000 RPM的磁盤、16 GB內(nèi)存組成，使用XFS作為本地文件系統(tǒng)。

測試程序使用的是業(yè)界常用的測試文件系統(tǒng)的性能工具IOMeter[15]。

按照如下順序進(jìn)行測試： 1) 單通道下兩種不同命名空間管理方式的性能；2) 多通道下MUSE的性能；3) 與其他元數(shù)據(jù)存儲系統(tǒng)的性能進(jìn)行比較。

3.1 兩種不同命名空間管理方式的性能對比

首先測試單通道元數(shù)據(jù)服務(wù)器的性能。本文分別測試和路徑分割的命名空間管理方式的性能。該項(xiàng)測試統(tǒng)一向單通道服務(wù)器上傳和下載目錄深度為5的0大小的文件，因?yàn)橄蚍植际轿募到y(tǒng)CSTORE上傳0字節(jié)文件，客戶端只會與元數(shù)據(jù)服務(wù)器交互，而不會與數(shù)據(jù)服務(wù)器交互。理論上路徑分割的命名空間管理方式每訪問一個文件至少需要5次磁盤I/O，而全路徑映射命名空間管理方式只需要一次磁盤I/O，兩種不同命名空間管理方式的性能如圖5所示，可看出全路徑映射命名空間管理方式性能是路徑分割命名空間管理方式性能的3倍。由于大量目錄第一次被訪問后被存儲引擎緩存，因此兩者的性能相差只有3倍而非5倍，由此可知，當(dāng)深度更大時，通過路徑分割的命名空間管理訪問一個文件需要更多的訪問次數(shù)，更會加大與全路徑映射命名空間管理方式之間的性能差距。

圖5 兩種不同命名空間管理方式的性能

3.2 多通道擴(kuò)展性和性能

本項(xiàng)測試使用多通道的方式來測量通道的擴(kuò)展性。在這里使用與前面相同的測試用例來測試4通道和8通道情況，并與前面的單通道性能做比較。

多通道MUSE的性能如圖6所示，可看出在相同文件數(shù)量的情況下，4通道每秒元數(shù)據(jù)操作數(shù)超過了單通道每秒操作數(shù)的4倍，這是因?yàn)?通道測試中每個通道只分到總文件量的四分之一的工作負(fù)載；8通道情況與4通道情況類似，只是隨著文件數(shù)量的遞增，性能開始緩慢下降到單通道性能8倍以下，這是由于文件數(shù)量到達(dá)一定很高的閾值，元數(shù)據(jù)向多通道映射造成了性能瓶頸?？傊?，這個結(jié)果論證了單元數(shù)據(jù)服務(wù)器下，多通道的性能基本可以達(dá)到線性擴(kuò)展。

a. 多通道MUSE上傳性能

b. 多通道MUSE查詢性能

圖6 多通道MUSE的性能

3.3 與其他元存儲系統(tǒng)的性能對比

選擇PVFS的元數(shù)據(jù)服務(wù)器manager node(MGR)來與本文的MUSE做對比，因?yàn)镻VFS是一個經(jīng)過實(shí)踐檢驗(yàn)的存儲系統(tǒng)并且有獨(dú)立的元數(shù)據(jù)服務(wù)器。因此在相同環(huán)境下測試MGR(集群)。MUSE與MGR的性能對比如圖7a所示，隨著文件數(shù)量的增加，兩個系統(tǒng)的性能均出現(xiàn)下降，但是MUSE性能依然遠(yuǎn)超MGR。這是因?yàn)镻VFS過分依賴本地文件系統(tǒng)，隨著文件數(shù)量的增多而導(dǎo)致性能急劇下降。而MUSE采用LSM-tree模型做數(shù)據(jù)索引，相對于MGR采用的B+tree模型(MGR使用BerkeleyDB做索引)有很大的性能提升。

最后，由于LevelDB在Ceph最近的版本中被使用做對象存儲模型，因此同樣部署了Ceph的元數(shù)據(jù)服務(wù)器metadata server(MDS，CEPH的元數(shù)據(jù)服務(wù)器)與本文的MUSE做比較(單節(jié)點(diǎn))。MUSE與MDS的性能對比如圖7b所示，MDS在120萬文件訪問操作時候達(dá)到性能最高峰，之后性能下降。雖然MUSE的文件上傳性能下降較嚴(yán)重，但是依然遠(yuǎn)超MDS。這是因?yàn)镸DS為了保證強(qiáng)一致性而導(dǎo)致性能低下，而MUSE在LevelDB的基礎(chǔ)上做了進(jìn)一步的優(yōu)化，而且通過引入多通道來充分利用多核多磁盤服務(wù)器的性能。

4 結(jié) 論

海量小文件的元數(shù)據(jù)管理一直是存儲領(lǐng)域的一個難點(diǎn)。使用LSM-tree模型代替?zhèn)鹘y(tǒng)的B+tree等模型作為元數(shù)據(jù)存儲索引。多緩存表、多線程緊湊操作、多通道可以更大程度上利用現(xiàn)代機(jī)器大內(nèi)存、多CPU、多磁盤的硬件優(yōu)勢；路徑分割映射最大程度上滿足了一般通用場景的性能需求，相對的，全路徑映射的命名空間管理方式則在特定的極少更改目錄名的場景下對命名空間的性能做了極限提升。性能測試表明，在多臺元數(shù)據(jù)服務(wù)器和多磁盤的條件下，MUSE在元數(shù)據(jù)訪問性能方面遠(yuǎn)超其他元數(shù)據(jù)存儲系統(tǒng)。在未來的工作中，將在保證MUSE的性能的前提下，致力于公有云存儲元數(shù)據(jù)安全性的問題。

[1] ZHANG L, ZHU L G, ZENG S F. Metadata update strategy with high reliability[J]. Applied Mechanics and Materials, 2013(411): 382-385.

[2] GHEMAWAT B S, GOBIOFF H, LEUNG S. (2003) The google file system[C]//ACM SIGOPS Operating Systems Review. Indianapolis, USA: [s.n.], 2010.

[3] SHVACHKO K, KUANG H, RADIA S, et al. The hadoop distributed file system[C]//2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST). Incline Village, Nevada, USA: IEEE, 2010:1-10.

[4] CARNS P H, LII W B L, ROSS R B, et al. PVFS: a parallel file system for Linux clusters[C]//Proceedings of the 4th Annual Linux Showcase Conference. Atlanta, Georgia, USA: 2000: 391-430.

[5] O'NEIL P, CHENG E, GAWLICK D, et al. The log-structured merge-tree (LSM-tree)[J]. Acta Informatica, 1996, 33(4): 351-385.

[6] CHANG F, DEAN J, GHEMAWAT S, et al. Bigtable: a distributed storage system for structured data[J]. Proceedings of Usenix Symposium on Operating Systems Design & Implementation, 2006, 26(2): 205-218.

[7] LAKSHMAN A, MALIK P. Cassandra-a decentralized structured storage system[J]. ACM Sigops Operating Systems Review, 2010, 44(2): 35-40.

[8] SANJAY G, JEFF D. LevelDB: a fast and lightweight key/value database library[EB/OL]. [2012-12-28]. http://code.google.com/p/leveldb/.

[9] BlOOM B H. Space/time trade-offs in hash coding with allowable errors[J]. Communications of the ACM, 1970, 13(7): 422-426.

[10] ARGE L. The buffer tree: a technique for designing batched external data structures[J]. Algorithmica, 2003, 37(37): 1-24.

[11] PERCONA INC. TokuDB[EB/OL]. (2011-1-1). https://www. percona.com/software/mysql-database/percona-tokudb.

[12] ESMET J, BENDER M A, FARACH C M, et al. The TokuFS streaming file system[C]//Proceedings of the 4th USENIX Conference on Hot Topics in Storage and File Systems. Boston, USA: USENIX Association, 2012: 14.

[13] BENDER M A, FARACH C M, FINEMAN J T, et al. Cache-oblivious streaming B-trees[C]//Proceedings of the Nineteenth Annual ACM Symposium on Parallel Algorithms and Architectures - SPAA '07. Santorini, Greece: ACM, 2007: 81-92.

[14] SHREEDHAR M, VARGHESE G. Efficient fair queuing using deficit round-robin[J]. IEEE/ACM Transactions on Networking, 1996, 4(3): 375-385.

[15] DANIEL S. IOMeter: an I/O subsystem measurement and characterization tool for single and clustered systems [EB/OL]. (2003-2-1). http:// www.iometer.org/.

編 輯 葉 芳

MUSE: A High-Performance Metadata Storage Engine for Cloud Storage System

DUAN Han-cong, XIANG Xiao-ke, and Lü Peng-cheng

( School of Computer Science and Engineering, University of Electronic Science and Technology of China Chengdu 611731)

In the cloud storage systems, the accesses of massive small files metadata will generate a large number of random disk I/O requests, which will become the performance bottleneck of the entire storage system. In this paper, metadata unit storage engine (MUSE), a kind of metadata storage engine for cloud storage system, is proposed to support massive small files storage with high performance. Firstly, LevelDB, a high speed key-value storage engine based on LSM-tree, is used as underlying physical storage module. Secondly, LevelDB is enhanced by introducing multiple buffer tables and multiple compaction threads, which take full advantages of memory and multi-core processor. Thirdly, a new metadata accesses scheduling mechanism on multiple I/O channels is proposed. Channel is an independent data storage pipe formed by binding the independent thread to the independent physical disk. In this way, the access operations are isolated between channels, and then the aggregation of multiple channels can provide high concurrency random I/O. In addition, MUSE proposes two namespace management strategies: Split-path mapping strategy and absolute path mapping strategy, aimed to make trade-off according to different application scenarios by users. Benchmarks show that MUSE can support the massive small files storage scene and outperform other metadata storage systems.

I/O; LSM-tree; massive; metadata; performance; small file; storage engine

TP311

A

10.3969/j.issn.1001-0548.2016.03.011

2014 - 04 - 18；

2015 - 09 - 10

國家重大科技專項(xiàng)(2012ZX03002-004-004)

段翰聰(1973 - )，男，博士，副教授，主要從事P2P內(nèi)容分發(fā)網(wǎng)絡(luò)、分布式存儲、操作系統(tǒng)等方面的研究.