面向城軌線網(wǎng)的海量小文件存儲方法

劉　靖　廖家趙　劉　瓊

1(廣州市地下鐵道總公司建設(shè)事業(yè)總部　廣東 廣州 510380)2(華南理工大學(xué)計算機(jī)科學(xué)與工程學(xué)院　廣東 廣州 510006)

?

面向城軌線網(wǎng)的海量小文件存儲方法

劉靖1廖家趙2劉瓊2

1(廣州市地下鐵道總公司建設(shè)事業(yè)總部廣東 廣州 510380)2(華南理工大學(xué)計算機(jī)科學(xué)與工程學(xué)院廣東 廣州 510006)

城軌線網(wǎng)小文件數(shù)據(jù)量巨大，傳統(tǒng)的分布式文件系統(tǒng)很難為海量小文件存儲提供符合需求的高吞吐、低延遲讀寫過程。根據(jù)城軌線網(wǎng)級業(yè)務(wù)的數(shù)據(jù)特點和以天為周期的數(shù)據(jù)訪問方式，提出基于FastDFS分布式文件系統(tǒng)和Redis鍵值數(shù)據(jù)庫的城軌線網(wǎng)海量小文件存儲方法，將具有相關(guān)性的城軌小文件合并成大文件進(jìn)行聚合寫操作；根據(jù)FastDFS返回的大文件索引、小文件存儲起始偏移量和小文件長度建立全局索引，利用Redis存儲小文件名和全局索引的鍵值對；采用數(shù)據(jù)預(yù)取機(jī)制，預(yù)取創(chuàng)建時間相鄰的數(shù)據(jù)。實驗結(jié)果表明，相較于FastDFS系統(tǒng)，F(xiàn)astDFS-Redis系統(tǒng)的小文件讀寫吞吐量分別提高了9.35%和4.45%，達(dá)到明顯改善城軌線網(wǎng)海量小文件的訪問效率的目的。

小文件存儲城軌線網(wǎng)FastDFSRedis訪問性能

0　引　言

隨著城市軌道交通(簡稱城軌)線路規(guī)模的增長，建立城軌線網(wǎng)數(shù)據(jù)中心對線路實施集中管理的需求日益凸顯。城軌線網(wǎng)數(shù)據(jù)中心面臨存儲管理海量數(shù)據(jù)的需求。城軌線網(wǎng)數(shù)據(jù)包括結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)，尤其非結(jié)構(gòu)化數(shù)據(jù)種類繁多，從便于存儲管理的角度，非結(jié)構(gòu)化數(shù)據(jù)可以歸為大文件(如視頻、文檔)和小文件(如圖片、報表)。大文件存儲技術(shù)(如HDFS文件系統(tǒng)[1])已有成熟的技術(shù)和系統(tǒng)，已經(jīng)得到較好的效果，而小文件的高效存儲問題尚未得到很好的解決。通常而言，容量在1MB以內(nèi)的文件被認(rèn)為是小文件，城軌線路存在大量的小文件，僅從廣州城軌的報表類文件進(jìn)行分析可知，現(xiàn)有9條線路投入運營，共164個車站，每個車站每天平均生成大約100個日報表。由此，城軌線網(wǎng)數(shù)據(jù)中心每天將產(chǎn)生約16 400個日報表，這些報表的平均大小為500 KB。

主流的文件存儲系統(tǒng)通常面向大文件的特點設(shè)計，海量小文件的存儲管理存在三個方面的問題：1)元數(shù)據(jù)管理低效[2]，由于當(dāng)前主流的文件系統(tǒng)是面向大文件的順序訪問特點設(shè)計的，索引節(jié)點、數(shù)據(jù)和目錄分別保存在磁盤的不同位置。因此訪問一個文件至少需要訪問磁盤的三個不同位置，使得并發(fā)的小文件訪問轉(zhuǎn)變成大量的隨機(jī)訪問，隨之帶來的磁頭的頻繁移動顯著地降低傳統(tǒng)機(jī)械磁盤的讀寫性能。2)I/O訪問流程復(fù)雜：主流的操作系統(tǒng)采用虛擬文件系統(tǒng)VFS(Virtual File System)作為文件系統(tǒng)的抽象接口。其中包括四種數(shù)據(jù)對象：超級塊對象、索引結(jié)點對象、文件對象和目錄項對象。由于在用戶態(tài)中使用路徑名表示文件，因此在打開文件時需要將文件的路徑名進(jìn)行分量解析，轉(zhuǎn)換成對應(yīng)文件在內(nèi)核中的四種數(shù)據(jù)對象，此過程占用的系統(tǒng)開銷非常大。3)數(shù)據(jù)布局單一：為了便于用戶對文件進(jìn)行并發(fā)的訪問，分布式文件系統(tǒng)通常采用條帶化技術(shù)切分文件，將某個文件的各部分存儲到多個數(shù)據(jù)服務(wù)器。然而，小文件容量較小，不宜進(jìn)行條帶化，只能將單個小文件存儲在單個數(shù)據(jù)服務(wù)器中，原來的多服務(wù)器并發(fā)訪問變成單服務(wù)器訪問。因此當(dāng)大量訪問某個服務(wù)器的小文件時，將使數(shù)據(jù)服務(wù)器的性能大幅下降。

目前，海量小文件存儲優(yōu)化已經(jīng)成為熱點技術(shù)，如Yahoo使用PNUTS[3]為其應(yīng)用平臺提供數(shù)據(jù)存儲服務(wù)；Amazon使用Dynamo系統(tǒng)[4]解決其電子商務(wù)應(yīng)用的數(shù)據(jù)存儲問題；Facebook使用Haystack系統(tǒng)[5]存儲百億級別的社交圖片；Google 使用BigTable[6]系統(tǒng)來存儲其海量的Google地球圖片和網(wǎng)頁索引。上述系統(tǒng)都經(jīng)歷了實踐的檢驗，能夠高效地存儲數(shù)以億計的小對象或小文件。然而，這些存儲系統(tǒng)專門針對社交網(wǎng)絡(luò)或電子商務(wù)等互聯(lián)網(wǎng)應(yīng)用而設(shè)計，存儲數(shù)據(jù)多為Web類應(yīng)用數(shù)據(jù)。城軌線網(wǎng)海量小文件訪問針對地鐵專業(yè)系統(tǒng)的非結(jié)構(gòu)化數(shù)據(jù)，具有層次性和周期性的特點?，F(xiàn)有的海量小文件存儲系統(tǒng)與城軌線網(wǎng)海量小文件存儲系統(tǒng)具有不同的設(shè)計需求，難以直接應(yīng)用于城軌線網(wǎng)海量小文件數(shù)據(jù)存儲。因此，為城軌線網(wǎng)數(shù)據(jù)中心提供高效的海量小文件存儲訪問技術(shù)迫在眉睫。

本文針對城軌線網(wǎng)海量小文件存儲的需求，指出部分已有海量小文件存儲訪問技術(shù)的局限性，從城軌線網(wǎng)業(yè)務(wù)分層的特點和數(shù)據(jù)周期性訪問方式出發(fā)，提出基于FastDFS分布式文件系統(tǒng)和Redis鍵值數(shù)據(jù)庫的城軌線網(wǎng)海量小文件存儲方法。首先，將同一線路同一地鐵專業(yè)系統(tǒng)同一天產(chǎn)生的小文件合并成大文件進(jìn)行聚合寫操作。其次，根據(jù)FastDFS分布式文件系統(tǒng)返回的大文件索引、小文件存儲的起始偏移量和小文件長度建立全局索引，使用Redis鍵值數(shù)據(jù)庫存儲小文件名與全局索引的鍵值對。最后，采用數(shù)據(jù)預(yù)取機(jī)制，預(yù)取創(chuàng)建時間相鄰的數(shù)據(jù)。

1　相關(guān)研究

本文方法從小文件合并優(yōu)化和元數(shù)據(jù)管理優(yōu)化技術(shù)出發(fā)，研究已有工作的優(yōu)勢和不足。

1.1小文件合并優(yōu)化

當(dāng)Linux文件系統(tǒng)維護(hù)大量的小文件時，inode的管理容易成為性能瓶頸，將小文件合并成數(shù)據(jù)塊文件可以減少文件個數(shù)，有效地降低 inode管理負(fù)載。Liu等[7]根據(jù)地理信息數(shù)據(jù)的特征，將具有地理相關(guān)性的小文件合并成同一個大文件，并為這些小文件建立全局哈希索引，以便對小文件進(jìn)行存取。Bo等[8]針對中國電子教學(xué)共享系統(tǒng)Bluesky的特點，將屬于同一個教學(xué)課件的文件合并成同一個大文件，并且提出一種索引文件預(yù)取與數(shù)據(jù)文件預(yù)取結(jié)合的數(shù)據(jù)預(yù)取機(jī)制，以解決電子課件小文件存儲的問題。張春明等[9]根據(jù)“中華字庫”工程小文件之間的相關(guān)性和文獻(xiàn)的目錄結(jié)構(gòu)，將同一文獻(xiàn)的圖片文件合并成大文件，并建立分層索引，同時使用索引文件和數(shù)據(jù)文件的預(yù)取機(jī)制以提高順序讀的效率。以上文獻(xiàn)針對具體應(yīng)用的數(shù)據(jù)特點，將具有強(qiáng)數(shù)據(jù)相關(guān)性的小文件合并成大文件進(jìn)行訪問，但是HDFS最初是面向存儲海量大文件設(shè)計的。因此受限于其存儲結(jié)構(gòu)，海量小文件的訪問性能很難得到本質(zhì)的提升。相比以上研究工作，本文提出方法基于的FastDFS分布式文件系統(tǒng)是面向存儲海量中小文件的需求設(shè)計的。其重要特點是將文件元數(shù)據(jù)存儲在FastDFS文件索引中，返回給客戶端，大大減少元數(shù)據(jù)管理服務(wù)器的負(fù)擔(dān)。

1.2元數(shù)據(jù)管理優(yōu)化

元數(shù)據(jù)管理低效是海量小文件存儲訪問性能低下的主要原因之一。Luo等[10]使用基于Fat-Btree的索引結(jié)構(gòu)，解決海量的小文件訪問時元數(shù)據(jù)服務(wù)器的內(nèi)存占用問題，但是該方法沒有從整體系統(tǒng)架構(gòu)考慮，優(yōu)化性能受到限制。Philip等[11]在PVFS[12]文件系統(tǒng)中使用分批提交的方式提交元數(shù)據(jù)以降低數(shù)據(jù)訪問延遲。但是，此方法局限于在PVFS文件系統(tǒng)中使用，過分依賴PVFS的存儲結(jié)構(gòu)。相比以上研究工作，本文提出的方法使用Redis鍵值數(shù)據(jù)庫，存儲小文件名與文件全局索引的鍵值對，進(jìn)行元數(shù)據(jù)管理，不局限于特定的分布式文件系統(tǒng)。

2　FastDFS-Redis存儲方案

本文提出的FastDFS-Redis小文件存儲方法包括：(1)將具有相關(guān)性的城軌小文件合并成大文件進(jìn)行聚合寫操作；(2)根據(jù)FastDFS分布式文件系統(tǒng)返回的大文件索引、小文件的起始偏移量和文件長度建立全局索引，使用Redis鍵值數(shù)據(jù)庫存儲原始文件名與全局索引的鍵值對；(3)采用數(shù)據(jù)預(yù)取機(jī)制，預(yù)取創(chuàng)建時間相鄰的數(shù)據(jù)。

2.1相關(guān)系統(tǒng)

2.1.1FastDFS分布式文件系統(tǒng)

FastDFS[13]是一個開源的輕量級分布式文件系統(tǒng)，面向海量中小文件的存儲需求進(jìn)行設(shè)計，由跟蹤服務(wù)器、存儲服務(wù)器和客戶端三個部分組成，其基本架構(gòu)如圖1所示。

圖1　FastDFS分布式文件系統(tǒng)的架構(gòu)圖

FastDFS服務(wù)端有三個角色：跟蹤服務(wù)器、存儲服務(wù)器和客戶端。跟蹤服務(wù)器在內(nèi)存中記錄集群中所有存儲組和存儲服務(wù)器的狀態(tài)信息，是客戶端和數(shù)據(jù)服務(wù)器交互的樞紐，主要負(fù)責(zé)存儲服務(wù)器的調(diào)度工作。相比GFS[14]中的元數(shù)據(jù)管理服務(wù)器更為精簡，跟蹤服務(wù)器不記錄文件索引信息，占用的內(nèi)存量很少。存儲服務(wù)器存儲文件和文件屬性，以組為單位組織，一個組內(nèi)可以包含多臺存儲服務(wù)器，同組內(nèi)的存儲服務(wù)器的數(shù)據(jù)互為備份。客戶端作為業(yè)務(wù)請求的發(fā)起方，當(dāng)需進(jìn)行文件讀寫的時候，向跟蹤服務(wù)器詢問可用的存儲服務(wù)器地址，然后直接與存儲服務(wù)器連接，進(jìn)行文件讀寫操作。

2.1.2Redis鍵值數(shù)據(jù)庫

Redis[15]是一個開源的基于內(nèi)存的高性能鍵值數(shù)據(jù)庫。與Memcached[16]相同的是，為了提高讀寫的效率，數(shù)據(jù)都是存儲在內(nèi)存中的，提供快照和AOF兩種數(shù)據(jù)持久化方式。與Memcached不同的是，它支持存儲的值類型相對更多，包括字符串、鏈表、集合、有序集合和哈希表。

2.2線網(wǎng)小文件合并

城軌線網(wǎng)業(yè)務(wù)系統(tǒng)具有層級特點，包括線路車站級系統(tǒng)、線路控制中心級系統(tǒng)和線網(wǎng)中心級系統(tǒng)，如圖2所示。城軌線網(wǎng)小文件數(shù)據(jù)由車站數(shù)據(jù)、線路控制中心數(shù)據(jù)和線網(wǎng)數(shù)據(jù)中心數(shù)據(jù)組成，其特點是同一線路專業(yè)系統(tǒng)的文件具有很強(qiáng)的相關(guān)性，每個文件名按照車站、專業(yè)系統(tǒng)和創(chuàng)建時間共同組成。

圖2　廣州城軌線網(wǎng)系統(tǒng)層次結(jié)構(gòu)圖

各城軌線路將以地鐵專業(yè)系統(tǒng)為級別按周期(如以一天或半天為周期)向線網(wǎng)數(shù)據(jù)中心寫入小文件。同時線網(wǎng)數(shù)據(jù)訪問具有局部性，往往讀取相同地鐵專業(yè)系統(tǒng)的創(chuàng)建時間連續(xù)的文件。因此，本方法首先在客戶端將同一線路同一地鐵專業(yè)系統(tǒng)同一天產(chǎn)生的小文件合并成大文件，再將大文件寫入到FastDFS文件系統(tǒng)中。

2.3全局索引存儲

在FastDFS分布式文件系統(tǒng)中，客戶端向存儲服務(wù)器寫入文件后，存儲服務(wù)器會向客戶端返回該文件的文件索引，以便客戶端以該文件索引為參數(shù)讀取文件。文件索引信息包含了文件的主要元數(shù)據(jù)，其組成如圖3所示，包括組名、虛擬磁盤路徑、數(shù)據(jù)兩級目錄和文件名。

圖3FastDFS索引組成圖

其中，組名為文件上傳后所在的存儲組名稱；虛擬磁盤路徑為存儲服務(wù)器配置的虛擬路徑；數(shù)據(jù)兩級目錄為存儲服務(wù)器在每個虛擬磁盤路徑下創(chuàng)建的兩級目錄；文件名是由存儲服務(wù)器根據(jù)特定信息生成，文件名包含存儲服務(wù)器IP地址、文件創(chuàng)建時間戳、文件大小、隨機(jī)數(shù)和文件拓展名等信息。

FastDFS返回索引給客戶端，而不是將文件索引存儲在跟蹤服務(wù)器，降低了跟蹤服務(wù)器的負(fù)擔(dān)，但是沒有從根本上解決海量小文件的文件索引的元數(shù)據(jù)存儲和管理問題。

因此，本方法將FastDFS返回的大文件索引、小文件在大文件存儲的起始偏移量和小文件長度合并構(gòu)造全局索引，如圖4所示。并使用Redis鍵值數(shù)據(jù)庫存儲小文件名與文件索引的鍵值對，從而提高元數(shù)據(jù)查找的效率。

圖4　全局索引組成圖

2.4數(shù)據(jù)預(yù)取

數(shù)據(jù)預(yù)取是行之有效的存儲優(yōu)化技術(shù)[8]，其原理是利用應(yīng)用的局部性特征預(yù)先讀取數(shù)據(jù)，從而減少磁盤I/O的訪問次數(shù)，有效提高數(shù)據(jù)訪問的性能。考慮到同一地鐵專業(yè)系統(tǒng)小文件的相關(guān)性和用戶訪問的局部性特征，本方法采用數(shù)據(jù)預(yù)取機(jī)制讀取文件。

城軌線網(wǎng)數(shù)據(jù)讀取的特點是往往讀取相同地鐵專業(yè)系統(tǒng)同一時間段寫入的文件，具有局部性。本方法是當(dāng)客戶端讀取某個地鐵專業(yè)系統(tǒng)的小文件時，預(yù)取與該文件相同地鐵專業(yè)系統(tǒng)的創(chuàng)建時間相鄰的10個文件。

3　FastDFS-Redis存儲系統(tǒng)

本文基于FastDFS 分布式文件系統(tǒng)和Redis數(shù)據(jù)庫，建立了面向城軌線網(wǎng)海量小文件的FastDFS-Redis存儲系統(tǒng)，其架構(gòu)如圖5所示。FastDFS-Redis存儲系統(tǒng)有四個角色：跟蹤服務(wù)器、存儲服務(wù)器、Redis鍵值數(shù)據(jù)庫和客戶端。跟蹤服務(wù)器主要用于管理存儲服務(wù)器，起到負(fù)載均衡的作用，在內(nèi)存中記錄集群中所有存儲組和存儲服務(wù)器的狀態(tài)信息；存儲服務(wù)器用于存儲來自客戶端上傳的文件；Redis鍵值數(shù)據(jù)庫用于存儲小文件名與全局索引的鍵值對；客戶端通過跟蹤服務(wù)器獲得可用的存儲服務(wù)器的地址，然后直接與存儲服務(wù)器連接進(jìn)行讀寫。

圖5　FastDFS-Redis架構(gòu)圖

3.1小文件寫入流程

如圖5所示，客戶端向FastDFS-Redis系統(tǒng)寫入小文件的流程包括如下步驟：

步驟1客戶端將同一線路同一地鐵系統(tǒng)同一天產(chǎn)生的小文件合并成大文件，并記錄小文件在大文件的起始偏移量和文件長度；

步驟2客戶端向跟蹤服務(wù)器詢問可用存儲服務(wù)器的地址；

步驟3跟蹤服務(wù)器向客戶端返回一臺可用存儲服務(wù)器的IP地址和端口號；

步驟4客戶端直接與存儲服務(wù)器建立連接，并向其寫入大文件，寫入完成后，存儲服務(wù)器向客戶端返回新生成的大文件索引；

步驟5客戶端結(jié)合FastDFS返回的大文件索引、小文件的起始偏移量和文件長度建立全局索引，使用Redis存儲小文件名和全局索引的鍵值對。

3.2小文件讀取流程

如圖5所示，客戶端從FastDFS-Redis系統(tǒng)讀取小文件的流程包括如下步驟：

步驟1客戶端根據(jù)小文件名在Redis數(shù)據(jù)庫中獲取小文件名對應(yīng)的全局索引；

步驟2客戶端從全局索引獲取對應(yīng)大文件的索引，向跟蹤服務(wù)器詢問可以下載大文件的存儲服務(wù)器，參數(shù)為大文件索引；

步驟3跟蹤服務(wù)器向客戶端返回一臺可用的存儲服務(wù)器的IP地址和端口號；

步驟4客戶端直接與該存儲服務(wù)器建立連接，讀取大文件；

步驟5客戶端根據(jù)全局索引中的文件起始偏移量和文件長度從大文件中預(yù)取與該文件創(chuàng)建時間相鄰的10個文件。

4　性能評測

4.1實驗環(huán)境

本文的實驗環(huán)境由四臺服務(wù)器組成。三臺服務(wù)器是Dell T110II，Intel Xeon E3-1220 3.1 GHz，8 GB內(nèi)存，500 GB硬盤，一臺服務(wù)器是Intel E750 2.93 GHz，4 GB內(nèi)存，320 GB硬盤。網(wǎng)絡(luò)環(huán)境是百兆以太網(wǎng)。其中兩臺Dell T110II機(jī)器各組成一個存儲組，每個組內(nèi)有一臺存儲服務(wù)器。有一臺Dell T110II機(jī)器作為Redis數(shù)據(jù)庫，最后一臺機(jī)器作為跟蹤服務(wù)器。每臺服務(wù)器的操作系統(tǒng)是Ubuntu Server 14.04。

4.2實驗數(shù)據(jù)

實驗數(shù)據(jù)由廣州地鐵報表數(shù)據(jù)組成，分別是文件大小為50 KB、100 KB、200 KB、500 KB和1 MB的報表各10 000個。各類數(shù)據(jù)由廣佛線路ACS系統(tǒng)近100天的報表文件挑選而成。

4.3實驗對比

本文實驗對比的主要指標(biāo)是FastDFS系統(tǒng)和FastDFS-Redis系統(tǒng)讀取和寫入小文件吞吐量，即每秒讀寫小文件的數(shù)據(jù)量。每項測試重復(fù)四次，取實驗數(shù)據(jù)的平均值作為最終的實驗結(jié)果。

4.3.1小文件寫入性能對比

分別向FastDFS系統(tǒng)和FastDFS-Redis系統(tǒng)寫入文件大小為50 KB、100 KB、200 KB、500 KB和1 MB的報表各10 000個，各吞吐量統(tǒng)計數(shù)據(jù)如表1所示。由于FastDFS-Redis方法采用了合并小文件進(jìn)行聚合寫操作的方法，客戶端與存儲服務(wù)器的網(wǎng)絡(luò)交互次數(shù)明顯減少，因此 FastDFS-Redis的吞吐量普遍大于FastDFS的吞吐量。FastDFS-Redis系統(tǒng)和FastDFS系統(tǒng)的平均吞吐量分別為8.34和7.98 MB/s，因此FastDFS-Redis系統(tǒng)提高了4.45%的寫吞吐量。實驗結(jié)果表明，F(xiàn)astDFS-Redis存儲方案能夠提高海量小文件在城軌線網(wǎng)場景下的寫入性能。

表1　FastDFS和FastDFS-Redis的小文件寫入吞吐量統(tǒng)計表

根據(jù)表1可以得到FastDFS和FastDFS-Redis的小文件寫入吞吐量對比圖，如圖6所示。

圖6　FastDFS和FastDFS-Redis的小文件寫入吞吐量對比

4.3.2小文件讀取性能對比

城軌線網(wǎng)讀取數(shù)據(jù)的請求具有以組為單位的特點，每組讀請求是隨機(jī)的，組內(nèi)的讀請求是順序的。因此，為模仿在城軌線網(wǎng)場景下的小文件讀取行為，分別對各類型的報表文件發(fā)出1000組隨機(jī)讀請求，其中每組包含9個順序讀請求。FastDFS系統(tǒng)和FastDFS-Redis系統(tǒng)各情況的讀取吞吐量統(tǒng)計數(shù)據(jù)如表2所示。FastDFS-Redis的吞吐量普遍大于FastDFS的吞吐量。FastDFS-Redis系統(tǒng)和FastDFS系統(tǒng)的平均吞吐量分別為7.86和7.19 MB/s，因此FastDFS-Redis系統(tǒng)提高了9.35%的讀吞吐量。實驗結(jié)果表明，F(xiàn)astDFS- Redis存儲方案能夠顯著提高海量小文件在城軌線網(wǎng)場景下的讀取性能。

表2　FastDFS和FastDFS-Redis的小文件讀取吞吐量統(tǒng)計表

根據(jù)表2可以得到FastDFS和FastDFS-Redis的小文件讀取吞吐量對比圖，如圖7所示。

圖7　FastDFS和FastDFS-Redis的小文件讀取吞吐量對比

5　結(jié)　語

本文提出并實現(xiàn)一種優(yōu)化城軌線網(wǎng)海量小文件存儲效率的方法。主要工作有：

1) 將具有相關(guān)性的城軌小文件合并成大文件進(jìn)行聚合寫操作；

2) 結(jié)合FastDFS返回的大文件索引、小文件的起始偏移量和文件長度建立全局索引，利用Redis存儲小文件名和全局索引的鍵值對；

3) 采用數(shù)據(jù)預(yù)取機(jī)制，預(yù)取創(chuàng)建時間相鄰的數(shù)據(jù)。

相較于FastDFS系統(tǒng)，該方法實現(xiàn)的FastDFS-Redis系統(tǒng)提高了4.45%的寫吞吐量和9.35%的讀吞吐量。證明FastDFS- Redis存儲方案能夠顯著提高城軌線網(wǎng)小文件的讀寫性能。下一步的工作是利用用戶態(tài)文件系統(tǒng)接口實現(xiàn)FastDFS-Redis系統(tǒng)的POSIX文件訪問接口，提高系統(tǒng)的可用性和擴(kuò)展性。

[1] Konstantin Shvachko,Hairong Kuang,Sanjay Radia,et al.The Hadoop Distributed File System[C]//Proceedings of the 26th IEEE Symposium on Mass Storage Systems and Technologies,2010.

[2] 王玲惠,李小勇,張軼彬.海量小文件存儲系統(tǒng)研究綜述[J].計算機(jī)應(yīng)用與軟件,2012,29(8):106-109.

[3] Cooper B F,Ramakrishnan R,Srivastava U,et al.PNUTS:Yahoo!’s hosted data serving platform[C]//Proc.of the VLDB Endowment,2008.

[4] DeCandia G,Hastorun D,Jampani M,et al.Dynamo:Amazon’s highly available key-value store[C]//Proceedings of the 25st ACM SIGOPS Symposium on Operating Systems Principles,New York,USA,2007.

[5] Beaver D,Kumar S,Li H C,et al.Finding a needle in haystack:facebook's photo storage[C]//Proceedings of the 9th USENIX Symposium on Operating System Design and Implementation(OSDI’10),Vancouver,Canada,2010.

[6] Fay Chang,Jeffrey Dean,Sanjay Ghemawat,et al.Bigtable:a distributed storage system for structured data[C]//Proceedings of the 7th USENIX Symposium on Operating System Design and Implementation (OSDI’06),2006.

[7] Xuhui Liu,Jizhong Han,Yunqin Zhong,et al.Implementing WebGIS on Hadoop:A Case Study of Improving Small File I/O Performance on HDFS[C]//Proc.of the 2009 IEEE Conf.on Cluster Computing,2009.

[8] Bo Dong,Jie Qiu,Qinghua Zheng,et al.A Novel Approach to Improving the Efficiency of Storing and Accessing Small Files on Hadoop:A Case Study by PowerPoint Files[C]//Proceedings of IEEE SCC,2010.

[9] 張春明,芮建武,何婷婷.一種Hadoop小文件存儲和讀取的方法[J].計算機(jī)應(yīng)用與軟件,2012,29(11):95-100.

[10] Luo Min,Yokota H.Comparing Hadoop and fat-tree based access method for small file I/O applications[C]//Proc.of the 11th Int Conf on Web-Age Information Management,Berlin:Springer,2010.

[11] Philip Carns,Sam Lang,Robert Ross,et al.Small-File Access in Parallel File systems[C]//Proceedings of the 23rd IEEE International Parallel and Distributed Processing Symposium,2009.

[12] Carns P H,Ligon W B,Ross B R,et al.PVFS:A parallel file system for Linux cluster[C]//Proceedings of the 4th Annual Linux Showcase&Conf.Berkeley,CA:USENIX Association,2000.

[13] 余慶.FastDFS[CP/OL].https://code.google.com/p/fastdfs/.

[14] Ghemawat S,Gobioff H,Leung S T.The Google file system[C]//Proc. of the 19th ACM Symp.on Operating Systems Principles (SOSP 2003),New York:ACM Press,2003.

[15] Salvatore Sanfilippo.Redis[CP/OL].http://redis.io/.

[16] LiveJournal Corporation.Memcached[CP/OL].http://memcached .org/.

AN APPROACH TO STORING MASSIVE SMALL FILES FOR URBAN RAIL TRANSIT NETWORK

Liu Jing1Liao Jiazhao2Liu Qiong2

1(ConstructionDivision,GuangzhouMetroCorporation,Guangzhou510380,Guangdong,China)2(SchoolofComputerScienceandEngineering,SouthChinaUniversityofTechnology,Guangzhou510006,Guangdong,China)

Because of the great amount of small files for urban rail transit network system, traditional distributed file system is difficult to provide read and write process with high throughput and low latency meeting the demand for massive small files storage. According to the data characteristics of urban rail transit network system and the data access method cycled in day, we propose an approach of storing massive small files for urban rail transit network, which is based on FastDFS distributed file system and Redis key-value database. The method merges the small files with correlation for urban rail transit into a big file to accomplish the aggregated writing operation; It forms the global index according to the big file indexes returned by FastDFS, the initial offset of small file storage and the lengths of small files, and uses Redis to store key-value pair of the filename of small file and global index; It adopts data prefetching mechanism to prefech the files with adjacent creation time. Experimental results show that compared with FastDFS distributed file system, the read throughput and write throughput of small files in FastDFS-Redis storage system increase by 9.35% and 4.45% respectively, which reaches the goal of noticeably improving the small file access efficiency for urban rail transit network.

Small file storageUrban rail transit networkFastDFSRedisAccess performance

2014-12-29。劉靖，教授級高工，主研領(lǐng)域：城市軌道交通機(jī)電一體化，自動化控制和通信工程。廖家趙，碩士生。劉瓊，教授。

TP311

A

10.3969/j.issn.1000-386x.2016.08.017