段翰聰，向小可，呂鵬程

?

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

段翰聰，向小可，呂鵬程

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

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

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

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

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

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

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

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

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

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

1 相關(guān)工作

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

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

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

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

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

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

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

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

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

2.1 系統(tǒng)綜述

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

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

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

2.2 Key-Value存儲(chǔ)引擎層

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

2.3 命名空間管理層

2.3.1 路徑分割映射

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

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

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

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

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

2.3.2 全路徑映射

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

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

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

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

2.4 通道處理層

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

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

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

3 評(píng)估測(cè)試

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

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

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

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

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

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

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

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

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

a. 多通道MUSE上傳性能

b. 多通道MUSE查詢(xún)性能

圖6 多通道MUSE的性能

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

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

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

4 結(jié) 論

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

[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

國(guó)家重大科技專(zhuān)項(xiàng)(2012ZX03002-004-004)

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