汪 帥 呂江花 汪溁鶴 吳繼芳 馬世龍

1(中國空間技術研究院 北京 100086) 2(北京航空航天大學計算機學院 北京 100191) (buaashuai@buaa.edu.cn)

互聯(lián)網(wǎng)的高速發(fā)展產生了海量數(shù)據(jù)，導致海量數(shù)據(jù)的傳輸和存儲場景日益增多，在這種背景下數(shù)據(jù)存儲技術得到了快速發(fā)展[1-3].過去10多年在多個應用領域產生的多媒體文件數(shù)量增長非常迅速，多媒體文件在互聯(lián)網(wǎng)信息中占有很大比重，所以海量多媒體文件存儲技術是一個重要研究課題[4-5]，分布式文件系統(tǒng)成為了當今的研究熱點.目前，在分布式文件系統(tǒng)中存儲海量多媒體文件時，還普遍存在著存儲性能不高、存儲空間利用率低、性能瓶頸及單點故障等問題，因此，如何解決海量多媒體文件在存儲和傳輸過程中存在的諸多實際問題，是當前計算機存儲技術研究領域非常重要的工作[6].

隨著云計算技術的廣泛應用，越來越多的應用程序為用戶提供圖片、視頻、音頻等多媒體文件的存儲和查詢服務，這類型文件通常具有存儲周期長、轉載復制頻繁、文件內容不宜分割等特點[7]，運用分布式存儲雖然可以提高多媒體文件的訪問效率，避免網(wǎng)絡傳輸瓶頸對多媒體文件造成的訪問延遲和磁盤存儲空間瓶頸對多媒體文件存儲造成的吞吐性能下降.但是，很多應用程序向用戶提供的多媒體文件上傳入口會使云存儲平臺積累大量重復的多媒體文件，這樣既給應用程序開發(fā)商增加了存儲成本，也降低了多媒體文件的訪問效率[8].因此，為了滿足這類應用程序對多媒體文件存儲和管理的需求，對多媒體文件進行分布式存儲、刪除重復的多媒體文件、保護用戶隱私、支持對存儲目錄動態(tài)邏輯擴容，對于提高系統(tǒng)性能、降低存儲成本、提升用戶體驗具有重要意義.

本文提出一種分布式存儲目錄動態(tài)建模方案，用來描述整個數(shù)據(jù)中心的存儲目錄邏輯結構，應用程序基于此模型可以方便地管理用戶上傳的多媒體文件，簡化存儲文件和獲取文件的過程.基于此建模方案實現(xiàn)的多媒體文件云存儲系統(tǒng)，支持對指定存儲目錄中的多媒體文件進行數(shù)據(jù)去冗，并且該系統(tǒng)可以在運行過程中對存儲目錄進行動態(tài)邏輯擴容.應用程序可以自定義存儲目錄樹的邏輯結構，應用程序通過該云存儲系統(tǒng)保存文件時，不必擔心某個存儲目錄的磁盤占用空間已達到存儲上限的問題，該云存儲系統(tǒng)解決了數(shù)據(jù)冗余度高的應用程序在低存儲成本條件下對多媒體文件進行分布式存儲的問題.

1 相關工作

云計算的發(fā)展使越來越多的信息被數(shù)據(jù)化，大量數(shù)據(jù)密集型的應用程序每天產生的體積較小的多媒體文件呈幾何級增長[9].Facebook這類大型社交軟件每周產生的圖片數(shù)據(jù)高達60TB[10]，淘寶網(wǎng)的圖片存儲量已經達到2PB[11]，如何對海量多媒體小文件進行有效的存儲與管理，減輕應用程序的負擔，已是存儲領域必須要面對的一個重要課題.

Ross等人[12]提出的PVFS(parallel virtual file system)是一個高性能、可擴展的分布式并行文件系統(tǒng)，PVFS將文件分散到多個存儲結點的多塊磁盤上，實現(xiàn)了對文件的條帶化存儲，消除了單個存儲結點引發(fā)的瓶頸問題，但是它缺乏必要的容錯機制并且配置不夠靈活，適用于對文本文件進行并行訪問和分析.Lustre文件系統(tǒng)[13]是基于對象存儲的大規(guī)模分布式文件系統(tǒng)，它把數(shù)據(jù)劃分成條帶存儲在多個對象存儲服務器(object storage server, OSS)上，當某個OSS發(fā)生故障時仍能保證存儲在該服務器上的數(shù)據(jù)不丟失.它是基于Linux內核級的分布式文件系統(tǒng)，多數(shù)用于高性能計算中.Lustre文件系統(tǒng)不支持數(shù)據(jù)去冗，同時數(shù)據(jù)的條帶化導致它在小文件存取時表現(xiàn)較差，每次讀取小文件都需要從多個存儲服務器結點上獲取文件的每個數(shù)據(jù)塊，然后把這些數(shù)據(jù)塊拼接成一個完整的小文件返回給應用程序.

Google文件系統(tǒng)(Google file system, GFS)[14]是一個支持數(shù)據(jù)密集型應用的、高度容錯且具有高吞吐量的分布式文件系統(tǒng)，GFS支持多個客戶端并行的對同一個文件進行內容追加操作，同時它能夠保證每個客戶端在在給同一個文件內容進行追加操作時的原子性，GFS會把文件切分成相同大小的數(shù)據(jù)塊存儲在不同的數(shù)據(jù)結點.對于多媒體文件來說，如果把它的內容切分成不同的數(shù)據(jù)塊分布式存儲，那么在訪問這些多媒體文件內容時，就需要從多個數(shù)據(jù)結點把數(shù)據(jù)塊全部取到然后返回給應用程序，這樣會額外消耗很多資源，而且GFS不支持通過HTTP協(xié)議訪問多媒體文件.基于GFS的設計思想，Konstantin等人[15]實現(xiàn)了開源的HDFS(Hadoop distributed file system)，HDFS也不支持通過HTTP協(xié)議訪問多媒體文件，HDFS的命名空間結點把系統(tǒng)中所有的元數(shù)據(jù)都放置在內存中，如果系統(tǒng)中存在海量的體積比較小的多媒體文件，會降低整個存儲系統(tǒng)的存儲效率和存儲能力.

淘寶文件系統(tǒng)(Taobao file system, TFS)[16]是一個構建在普通的Linux機器集群上的、對外提供高可靠和高并發(fā)訪問的分布式文件系統(tǒng).TFS為阿里巴巴提供海量小文件存儲，滿足了阿里巴巴對小文件存儲的需求，被廣泛地應用在阿里巴巴各項應用中.TFS采用扁平化的數(shù)據(jù)組織結構，一方面它把多個小文件壓縮在一個數(shù)據(jù)塊中進行存儲，另一方面它把文件名映射到文件的物理地址，簡化了文件的訪問流程，一定程度上為TFS提供了良好的讀寫性能.當TFS客戶端需要讀取文件內容時，它將文件名轉換為文件塊號和文件號，然后在命名空間結點上取得文件塊號所對應的數(shù)據(jù)結點信息，之后客戶端通過數(shù)據(jù)結點獲取數(shù)據(jù)塊內容，然后根據(jù)文件號找到文件的具體內容.TFS不支持數(shù)據(jù)去冗，它把圖片編號作為元數(shù)據(jù)存儲在外部數(shù)據(jù)庫中，TFS對數(shù)據(jù)庫比較依賴而且要求數(shù)據(jù)庫具有很高的性能，每次獲取圖片信息時都要進行讀取數(shù)據(jù)庫操作，然后去確定圖片的存儲位置.

表1直觀地顯示了上述4個文件系統(tǒng)之間的差異和不足:

Table 1 Different Feature of File Systems表1 文件系統(tǒng)對比

① Large: File size greater than 10 MB.

② Small: File size less than 10 MB.

在具備擴展性的高性能文件系統(tǒng)研究方面，OceanStore[17]和Farsite[18]可以提供TB級別的高可靠文件存儲，同時支持幾千個客戶端并發(fā)訪問文件內容，但是它們由于命名空間結點的瓶頸，不能支持客戶端高并發(fā)訪問小文件.Ceph[19]是一個擴展性較強的高性能分布式文件系統(tǒng)，Ceph文件系統(tǒng)為異構的并且擁有不可靠對象存儲設備的動態(tài)集群設計了偽隨機數(shù)據(jù)分發(fā)函數(shù)，通過替換分配表來最大化分離數(shù)據(jù)和元數(shù)據(jù)管理之間的耦合關系，但是它在安全性和POSIX調用[20]方面還有待進一步完善.Chung等人[21]提出的分布式文件系統(tǒng)雖然可以降低存儲成本并且擁有不錯的性能，但它在擴展性方面表現(xiàn)較差.Hao等人[22]提出的鏈接分布式文件系統(tǒng)支持對文件進行多版本管理，但擴展性和實用性較差.Xiong等人[23]、Cao等人[24]和Chao等人[25]在實用性方面各自研究了分布式存儲策略，但他們的研究方向偏向于文件副本策略.在小文件管理方面，Dong等人[26-27]、Chandrasekar等人[28]和Chatuporn等人[29]在HDFS的基礎上優(yōu)化了小文件的存儲策略，一定程度上提高了HDFS在小文件存儲和訪問方面的性能，但他們對多媒體文件去冗方面研究較少.

在多媒體文件數(shù)據(jù)去冗領域，根據(jù)去冗粒度的不同，去冗方式可以分為字節(jié)級的去冗、數(shù)據(jù)塊級的去冗和文件級的去冗，不同的去冗方式各有利弊.1)對于字節(jié)級去冗，一般在字節(jié)層面查找和刪除重復的數(shù)據(jù)，通常使用差異壓縮策略生成差異部分內容，它的優(yōu)點是去冗率很高，缺點是去冗的速度比較慢，不適合對數(shù)據(jù)實時去冗.2)數(shù)據(jù)塊級的去冗方式將文件按一定的策略劃分成多個數(shù)據(jù)塊，把數(shù)據(jù)塊視為去冗的基本單位，它的優(yōu)勢是計算速度較快，去重效率也較高，但對數(shù)據(jù)變化比較敏感.3)文件級的去冗方式把整個文件當作檢測和去冗的基本單位，首先計算整個文件的指紋，然后根據(jù)文件指紋在存儲系統(tǒng)中查找是否存在具有相同指紋信息的文件，這種去冗方式的去冗速度非?？?，缺點是即使2個文件中存在很多相同數(shù)據(jù)，也無法刪除文件內的重復數(shù)據(jù)[30].

主流的開源分布式文件系統(tǒng)大多針對大文件讀寫而專門設計，企業(yè)級的多媒體文件管理系統(tǒng)因商業(yè)利益無法公開.本文重點研究數(shù)據(jù)冗余度高的應用程序如何對多媒體文件進行分布式存儲的問題，與主流的分布式文件系統(tǒng)相比，本文實現(xiàn)的MFCSS(multimedia file cloud storage system)系統(tǒng)能夠運行在Windows或Linux下，不依賴數(shù)據(jù)庫，支持對多媒體文件進行數(shù)據(jù)去冗，支持對存儲目錄進行運行時動態(tài)邏輯擴容.

2 分布式存儲目錄建模方法及MFCSS系統(tǒng)

數(shù)據(jù)中心是一整套復雜的設施，它不僅包括計算機系統(tǒng)和其它與之配套的設備，還包含冗余的數(shù)據(jù)通信連接、環(huán)境控制設備、監(jiān)控設備以及各種安全裝置[31].一個數(shù)據(jù)中心通常會包含多臺存儲服務器，存儲服務器自身會存在一些受保護的應用程序數(shù)據(jù)文件和存儲目錄，為了隔離不同應用程序的存儲區(qū)域，防止應用程序上傳的文件對存儲服務器自身的重要文件造成破壞，存儲服務器需要指定一些存儲目錄供應用程序存儲文件.

圖1描述了一個數(shù)據(jù)中心的分布式存儲目錄結構圖，它由多棵存儲目錄樹構成，不同的應用程序在保存用戶文件時通常具有不同的存儲目錄樹邏輯結構，存儲目錄樹中結點的層次關系取決于應用程序，本節(jié)將給出分布式存儲目錄建模方案中各結點的詳細定義.

Fig. 1 Distributed directory tree structure圖1 分布式存儲目錄結構圖

定義1. 存儲目錄結點(directory node,DN).用來描述存儲服務器上的存儲目錄信息，它定義為(id,naming,storePath,(parent,ChildNodes))，其中：

1)id表示DN的編號，編號具有唯一性.

2)naming表示DN的命名規(guī)則.它定義為三元組(nameType,staticName,dynamicName)，其中：

①nameType∈{static,dynamic}表示DN的命名方式，static表示DN采用靜態(tài)命名方式，dynamic表示DN采用動態(tài)命名方式.

②staticName表示DN采用靜態(tài)命名方式時候的文件名是staticName，例如：staticName=“Z1”，則該目錄的文件名為“Z1”.

③dynamicName表示DN采用動態(tài)命名方式時，將應用程序運行時傳遞的dynamicName所對應的參數(shù)的值作為DN的文件名，例如：dynamic-Name=“userId”，且應用程序運行時傳遞的參數(shù)userId=“U10”，則該目錄的文件名為“U10”.

3)storePath表示DN的初始設置結點的磁盤存儲路徑，初始設置結點AN(ancestor node)的定義參見下文.

4) (parent,ChildNodes)表示DN的直連結點的屬性信息，其中：

①parent表示DN的直接父結點.

②ChildNodes={node1,node2…,nodem}(m≥0)表示DN直接子結點的集合，其中nodei(0≤i≤m)可以是DN，也可以是文件結點(file node,FN)，F(xiàn)N的定義參見下文.

根據(jù)定義1，下面行文中定義靜態(tài)目錄結點SDN(static directory node)，它是DN的特殊實例，其名稱staticName在系統(tǒng)未運行時指定，為了防止同一個存儲目錄中出現(xiàn)2個具有相同文件名的存儲目錄，不同編號的SDN具有不同的目錄名稱；定義動態(tài)目錄結點DDN(dynamic directory node)，它也是DN的特殊實例，其編號在系統(tǒng)未運行時指定，但其名稱取決于系統(tǒng)運行過程中應用程序傳遞的dynamicName所對應的參數(shù)的值，一個DDN在系統(tǒng)運行過程中會產生多個具有不同文件名的DN，這些DN具有相同的父目錄；定義初始設置結點AN，它也是DN的特殊實例，它代表存儲服務器結點在應用程序運行之初提供的用來存放文件的存儲目錄，AN必須是實際存在的存儲目錄，其中AN.parent是存儲服務器結點，AN.storePath是該初始設置結點在磁盤上的絕對路徑.

例1. 在圖1所示的分布式存儲目錄結構圖中，“圖書”和“場景”分別是“電子書存儲服務器”和“場景存儲服務器”的初始設置結點，每個存儲服務器可以具有多個初始設置結點，但是每個存儲目錄結點只能隸屬于唯一的初始設置結點.

定義2. 存儲服務器結點(server node,SN).用來描述數(shù)據(jù)中心內存儲服務器的屬性信息、訪問信息和它所提供的初始設置結點信息，它定義為(id,property,access,AncestorNodes,url)，其中:

1)id表示SN的編號，編號具有唯一性.

2)property定義為(ip,ftpPort,serverPort)，表示SN的屬性.

①ip表示SN的IP地址.

②ftpPort表示通過FTP協(xié)議訪問SN的端口號.

③serverPort表示SN提供的外部TCP協(xié)議訪問端口號.

3)access定義為(userName,password)，表示SN的訪問信息.

①userName表示訪問SN的用戶名.

②password表示訪問SN的密碼.

4)AncestorNodes={AN1,AN2…,ANn}(n≥1)表示SN提供的可以存儲文件的初始設置結點集合.

5)url表示通過HTTP協(xié)議訪問SN的地址.

定義3. 文件結點.FN用來描述文件的相關信息，它定義為(id,fileName,fileType,property)，其中：

1)id表示FN的編號.

2)fileName表示文件名.

3)fileType表示文件類型.

4)property定義為(fingerprint,directory-NodeId)，它表示文件的屬性.其中：

①fingerprint表示文件的指紋信息，它在系統(tǒng)中可以是MD5，也可以是SHA-1等摘要算法.

②directoryNodeId表示FN的父存儲目錄結點的編號.

根據(jù)上文中對一些結點的定義，下面將給出存儲目錄子樹、存儲目錄樹和分布式存儲目錄的相關定義.

定義4. 存儲目錄子樹(SubTree).用于描述某一個存儲目錄結點及其嵌套子結點之間的關系，以存儲目錄結點node為根結點的存儲目錄子樹SubTree(node)定義為：

1) 如果node是文件結點，則SubTree(node)=node.

2) 如果node是存儲目錄結點，并且該存儲目錄結點沒有直接子結點，即node.ChildNodes=?,則SubTree(node)=node.

3) 如果node是存儲目錄結點，并且該存儲目錄結點具有直接子結點，假設：node.ChildNodes={node1,node2,…,nodem}(m≥1)，則SubTree(node)是由以node為根結點的m棵子樹{SubTree(node1),SubTree(node2),…,SubTree(nodem)}按從左到右順序構成的樹.

4) 用SubTree(node).id表示存儲目錄子樹的編號，且SubTree(node).id=node.id.

定義5. 存儲目錄樹(DirectoryTree).用于描述某一個存儲服務器結點(SN)及其嵌套子結點之間的關系，設SN.AncestorNodes={AN1,AN2,…,ANn}(n≥1)，則存儲目錄樹DirectoryTree(SN)是由以SN為根結點和n棵存儲目錄子樹SubTree(AN1),SubTree(AN2),…,SubTree(ANn)按從左到右順序構成的樹，用DirectoryTree.id表示存儲目錄樹DirectoryTree的編號，且DirectoryTree.id=SN.id.

定義6. 數(shù)據(jù)中心.可以看作一個分布式存儲目錄(DistributeTrees)，它由若干棵存儲目錄樹構成，即DistributeTrees={DirectoryTree(SN1),DirectoryTree(SN2),…,DirectoryTree(SNk)}(k≥1).

通過以上定義，整個數(shù)據(jù)中心可以被建模形成一棵分布式存儲目錄，分布式存儲目錄中的存儲目錄結點都是邏輯結點，應用程序可以通過該建模方案定義每個邏輯結點之間的關系以及邏輯結點的相關屬性，系統(tǒng)會在運行過程中根據(jù)應用程序傳遞的參數(shù)，把每個邏輯結點實例化為相應的物理存儲結點，應用程序在保存文件時只需要指定邏輯結點的編號，系統(tǒng)會把文件保存到邏輯結點對應的物理存儲結點中.

在分布式存儲目錄模型的基礎上實現(xiàn)的多媒體文件云存儲系統(tǒng)(MFCSS)解決了數(shù)據(jù)中心內多媒體文件的數(shù)據(jù)去冗問題，它可以給應用程序提供便捷的管理分布式存儲目錄的接口，簡化應用程序管理分布式存儲環(huán)境中多媒體文件的過程.整個系統(tǒng)的架構如圖2所示，MFCSS系統(tǒng)向應用程序提供多媒體文件云存儲服務，它由存儲接口管理子系統(tǒng)(storage interface management subsystem, SIMSS)、集群管理子系統(tǒng)(cluster management sub-system, CMSS)和存儲管理子系統(tǒng)(storage manage-ment subsystem, SMSS)構成，每個應用程序各集成一個存儲接口管理子系統(tǒng)，存儲接口管理子系統(tǒng)以JAR文件格式包的形式集成在應用程序中.

Fig. 2 System architecture of MFCSS圖2 多媒體文件云存儲系統(tǒng)架構

存儲接口管理子系統(tǒng)給應用程序提供操作數(shù)據(jù)文件的接口，包括文件操作相關接口和目錄操作相關接口等，同時負責生成操作指令與集群管理子系統(tǒng)和存儲管理子系統(tǒng)進行通信.它還負責管理應用程序自定義的存儲目錄樹，生成多媒體文件的存儲路徑和訪問路徑，當存儲服務器的存儲負荷達到一定閾值之后，存儲接口管理子系統(tǒng)會向集群管理子系統(tǒng)發(fā)送指令，對相應的存儲目錄進行邏輯擴容.

數(shù)據(jù)中心的每臺存儲服務器上都會部署一個存儲管理子系統(tǒng)，它負責管理其所在存儲服務器上所有文件元數(shù)據(jù)、文件引用信息和擴容狀態(tài)信息，并提供查詢文件元數(shù)據(jù)、查詢存儲目錄引用信息和查詢存儲目錄擴容狀態(tài)信息等服務.多個存儲管理子系統(tǒng)在查找文件指紋信息所對應文件元數(shù)據(jù)時是并行執(zhí)行的，它們將各自的查找結果通過通信指令傳輸給集群管理子系統(tǒng)，集群管理子系統(tǒng)匯總各個存儲管理子系統(tǒng)發(fā)來的查找結果,并將結果返回給存儲接口管理子系統(tǒng)做后續(xù)的業(yè)務處理.

當存儲接口管理子系統(tǒng)在驗證多媒體文件是否屬于冗余文件時，通過集群管理子系統(tǒng)與不同的存儲管理子系統(tǒng)通信，當存儲接口管理子系統(tǒng)在保存多媒體文件時，它直接與存儲管理子系統(tǒng)通信.

集群管理子系統(tǒng)部署在單獨的服務器上，負責管理新接入的存儲服務器，監(jiān)控各臺存儲服務器的運行狀態(tài)，提供對存儲目錄進行邏輯擴容的服務，同時還提供文件指紋信息匹配驗證服務.集群管理子系統(tǒng)中實現(xiàn)了一個布隆過濾器[32]負責管理MFCSS系統(tǒng)保存的所有文件指紋信息，在接收到存儲接口管理子系統(tǒng)發(fā)來的驗證文件指紋信息指令之后，它通過布隆過濾器判斷文件指紋信息的存在性，如果文件指紋信息不存在于布隆過濾器中，集群管理子系統(tǒng)判定用戶上傳文件不屬于冗余文件，否則，就將查找該指紋信息所對應文件元數(shù)據(jù)的指令發(fā)送給各個存儲管理子系統(tǒng)，進一步確定冗余文件的具體位置.每個存儲管理子系統(tǒng)根據(jù)指紋信息迅速在內存中找出該指紋信息所對應的文件元數(shù)據(jù)，集群管理子系統(tǒng)匯總所有存儲管理子系統(tǒng)發(fā)送給它的匹配結果，并把結果反饋給應用程序，由應用程序根據(jù)該反饋結果做后續(xù)的業(yè)務處理.

Fig. 3 The process of logical expansion圖3 邏輯擴容流程圖

數(shù)據(jù)中心的每臺存儲服務器都開啟了FTP訪問服務，供存儲接口管理子系統(tǒng)操作文件和目錄.應用程序在集成了存儲接口管理子系統(tǒng)之后，可以自定義分布式存儲目錄模型，然后調用存儲接口管理子系統(tǒng)提供的文件操作接口和目錄操作接口就可以完成對多媒體文件的存儲和查詢過程，存儲的過程中MFCSS系統(tǒng)會根據(jù)應用程序的需求對指定的存儲目錄或者整個存儲服務器中的數(shù)據(jù)進行去冗，當某個存儲服務器的磁盤空間利用率在超過一定的閾值之后，MFCSS系統(tǒng)會自動給該存儲服務器中的存儲目錄進行邏輯擴容，應用程序在存儲文件時不必擔心存儲目錄會出現(xiàn)磁盤存儲空間不足的情況.

MFCSS系統(tǒng)中的每個存儲服務器都由部署在其上的Apache提供多媒體文件的Web訪問服務，為了提高用戶文件的存儲安全性和訪問安全性，避免用戶文件被網(wǎng)絡爬蟲按照一定規(guī)則竊取，同時還要保證MFCSS系統(tǒng)保存的文件不被第三方應用程序訪問.存儲接口管理子系統(tǒng)會對用戶上傳的每個文件都生成一個時間戳并分配一個隨機數(shù)存儲于文件名中，它相當于每個多媒體文件的“私人秘鑰”，該秘鑰可以保證所有獲取文件的請求都是經過MFCSS系統(tǒng)“批準”的，可以有效防止網(wǎng)絡爬蟲根據(jù)某些已知文件的訪問路徑通過暴力破解的方式非法獲取到其他文件的訪問路徑.同時，應用程序在系統(tǒng)初始化時MFCSS系統(tǒng)會給它授權一個訪問編號，在保存文件和訪問文件時應用程序需要給MFCSS系統(tǒng)提供該編號，該編號相當于應用程序的“身份證”，可以有效防止第三方應用程序在知道了存儲目錄樹結構的情況下非法竊取MFCSS系統(tǒng)中的用戶文件.

3 存儲目錄邏輯擴容策略

為了提高系統(tǒng)的擴展性，保證文件系統(tǒng)服務的連續(xù)性，需要在系統(tǒng)運行過程中實時地給存儲目錄邏輯擴容.對于應用程序而言，它通過分布式存儲目錄模型可以定義存儲目錄的邏輯結構，在保存文件時應用程序只需要提供存儲目錄的邏輯結點編號以及相應的保存參數(shù)，MFCSS系統(tǒng)會維護邏輯結點到物理存儲結點之間的映射關系.應用程序可以源源不斷地把文件保存在某個存儲目錄邏輯結點中，不需要擔心該結點對應的磁盤空間出現(xiàn)不足的問題，MFCSS系統(tǒng)在保存文件時如果發(fā)現(xiàn)某個磁盤的存儲空間出現(xiàn)不足，會自動的給相應的存儲目錄邏輯擴容.

圖3所示是MFCSS系統(tǒng)邏輯擴容的具體流程，主要步驟如下：

1) 存儲接口管理子系統(tǒng)發(fā)送獲取擴容存儲目錄指令給集群管理子系統(tǒng)；

2) 集群管理子系統(tǒng)收到獲取擴容存儲目錄指令，發(fā)送獲取服務器運行狀態(tài)指令給所有的存儲管理子系統(tǒng)；

3) 每個存儲管理子系統(tǒng)收到獲取服務器運行狀態(tài)指令，將服務器運行狀態(tài)返回給集群管理子系統(tǒng)；

4) 集群管理子系統(tǒng)匯總所有的存儲服務器運行狀態(tài)，確定空閑的存儲服務器并生成擴容存儲目錄，然后保存擴容信息，并將擴容存儲目錄信息返回給存儲接口管理子系統(tǒng).

圖4所示為一個具有擴容狀態(tài)的分布式存儲目錄示意圖，假設應用程序通過MFCSS系統(tǒng)向存儲目錄樹DirectoryTree(SN2)中的靜態(tài)目錄結點F14添加一個文件結點fileNode1，則MFCSS系統(tǒng)進行2項判斷：

1) 如果存儲服務器結點SN2的磁盤存儲空間利用率未超過其存儲上限，那么fileNode1會被保存到結點F14中；

2) 如果存儲服務器結點SN2的磁盤存儲空間利用率超過了其存儲上限，此時系統(tǒng)會為結點F14分配一個擴容結點并把fileNode1保存到該擴容結點中.

Fig. 4 Distributed directory tree structure with expand status圖4 具有擴容狀態(tài)的分布式存儲目錄示意圖

任何一個存儲服務器結點的磁盤存儲空間利用率超過了其存儲上限之后，MFCSS系統(tǒng)會給映射在其上的存儲目錄結點進行邏輯擴容，如果應用程序需要獲取某個被擴容過的存儲目錄結點中的所有文件，MFCSS系統(tǒng)會自動把該存儲目錄結點對應的實際磁盤目錄中的文件，還有存放在其擴容結點對應的實際磁盤目錄中的文件一起返回給應用程序.該存儲目錄邏輯擴容機制使每個邏輯存儲目錄結點都能映射到多個實際磁盤存儲目錄，保證了文件系統(tǒng)服務的連續(xù)性，同時有效利用了存儲服務器的磁盤空間.

4 數(shù)據(jù)去冗策略

Fig. 5 The process of deleting redundant files圖5 數(shù)據(jù)去冗流程圖

隨著集群規(guī)模的擴大和存儲多媒體文件的數(shù)量增加，為了降低整個云存儲系統(tǒng)的運行成本，需要對系統(tǒng)中保存的多媒體文件進行數(shù)據(jù)去冗，節(jié)省磁盤占用空間.圖5所示是多媒體文件云存儲系統(tǒng)數(shù)據(jù)去冗的具體流程，整個去冗流程主要分為3個階段：判定階段、確認階段和存儲階段.在判定階段，應用程序將文件指紋信息發(fā)送給多媒體文件云存儲系統(tǒng)，系統(tǒng)中的布隆過濾器快速判定該指紋信息是否存在，如果布隆過濾器中不存在該文件的指紋信息，系統(tǒng)就認為該文件不屬于冗余文件，否則就進入確認階段進一步確定文件的存在性.在確認階段，系統(tǒng)通過通信指令告訴所有存儲服務器上的客戶端，使它們各自查找該指紋信息所對應的文件元數(shù)據(jù)，并將查找結果匯總反饋給應用程序，只要某個客戶端找到了該指紋信息所對應的文件元數(shù)據(jù)，系統(tǒng)就認為該文件屬于冗余文件.系統(tǒng)在以上2個階段運行結束之后進入存儲階段，在該階段系統(tǒng)保存相關的文件引用信息和文件指紋信息等核心數(shù)據(jù).

具體的數(shù)據(jù)去冗步驟如下：

步驟1. 針對用戶上傳的多媒體文件，通過瀏覽器計算該多媒體文件的指紋信息并傳輸給應用程序.

用戶在通過瀏覽器訪問應用程序并上傳文件時，應用程序提供的瀏覽器頁面上的JavaScript腳本首先計算文件的指紋信息并將它發(fā)送給應用程序.

步驟2. 應用程序獲取到該多媒體文件的指紋信息，調用存儲接口管理子系統(tǒng)的接口生成驗證文件指紋信息指令.

應用程序通過存儲接口管理子系統(tǒng)向集群管理子系統(tǒng)發(fā)送驗證文件指紋信息指令；應用程序在存儲文件和訪問文件時需要提供MFCSS系統(tǒng)授權給它的編號，只有經過MFCSS系統(tǒng)認證才能進行后續(xù)的文件操作和目錄操作，存儲接口管理子系統(tǒng)對用戶上傳的每個文件都生成一個時間戳并分配一個隨機數(shù)存儲在文件名中，這種設計可以在不影響MFCSS系統(tǒng)服務效率的同時保證用戶數(shù)據(jù)的訪問安全.

步驟3. 存儲接口管理子系統(tǒng)把驗證文件指紋信息指令發(fā)送給集群管理子系統(tǒng).

步驟4. 集群管理子系統(tǒng)在收到驗證文件指紋信息指令后，判斷該多媒體文件的指紋信息是否存在，如果存在，進入步驟5；否則，生成文件指紋信息驗證結果，進入步驟7.

如果集群管理子系統(tǒng)通過布隆過濾器判斷得出該指紋信息已存在，則系統(tǒng)需要進一步找到該指紋信息所對應的文件元數(shù)據(jù)，在查找指紋信息所對應的文件元數(shù)據(jù)過程中，集群管理子系統(tǒng)給每個存儲管理子系統(tǒng)發(fā)送查找文件元數(shù)據(jù)的指令，把存儲管理子系統(tǒng)返回的查找結果匯總并發(fā)送給存儲接口管理子系統(tǒng)，否則，生成文件指紋信息驗證結果并發(fā)送給存儲接口管理子系統(tǒng).

集群管理子系統(tǒng)在找到與用戶上傳的多媒體文件具有相同指紋信息的文件后，會把文件元數(shù)據(jù)返回給應用程序，由應用程序根據(jù)文件元數(shù)據(jù)進行后續(xù)的業(yè)務處理，防止用戶無法訪問到該文件的情況發(fā)生；

步驟5. 集群管理子系統(tǒng)發(fā)送查找該指紋信息對應的文件元數(shù)據(jù)指令給所有的存儲管理子系統(tǒng).

在查找文件指紋信息所對應文件元數(shù)據(jù)的過程中，每個存儲管理子系統(tǒng)的查找過程是并行的，有效提高了定位冗余文件的速度，提升了用戶體驗.

步驟6. 每個存儲管理子系統(tǒng)收到查找文件元數(shù)據(jù)指令，在各自的內存中查找該多媒體文件指紋對應的文件元數(shù)據(jù)，并生成文件指紋信息驗證結果返回給集群管理子系統(tǒng).

步驟7. 集群管理子系統(tǒng)匯總文件指紋信息驗證結果，并發(fā)送給存儲接口管理子系統(tǒng).

步驟8. 存儲接口管理子系統(tǒng)獲取文件指紋信息驗證結果，根據(jù)結果判斷MFCSS系統(tǒng)中是否存在相同文件，如果存在，進入步驟9；否則，進入步驟10.

步驟9. 向存儲管理子系統(tǒng)發(fā)送添加文件引用信息指令和增加文件引用頻率指令，并生成文件上傳結果；然后進入步驟14.

存儲接口管理子系統(tǒng)根據(jù)集群管理子系統(tǒng)發(fā)來的消息判斷用戶上傳的文件是否屬于冗余文件，如果MFCSS系統(tǒng)中的存儲服務器SNi上已經存在一個文件filex和用戶上傳的文件具有相同的指紋信息，則應用程序把它分配的用來保存該多媒體文件的存儲目錄結點編號idx傳遞給存儲接口管理子系統(tǒng)，然后存儲接口管理子系統(tǒng)向idx所在的存儲管理子系統(tǒng)發(fā)送添加文件引用信息的指令，收到該指令之后，存儲管理子系統(tǒng)會保存idx和filex之間的映射關系；之后存儲接口管理子系統(tǒng)向filex所在的存儲管理子系統(tǒng)發(fā)送增加文件引用頻率的指令，收到該指令之后，存儲管理子系統(tǒng)會找到filex的元數(shù)據(jù)并對其引用頻率加1.如果MFCSS系統(tǒng)中已經存在某個文件與用戶上傳的文件具有相同的指紋信息，則中斷用戶文件的上傳過程并提示文件秒傳成功，減少了用戶上傳文件需要消耗的平均時間，同時降低了存儲服務器的存儲負載和數(shù)據(jù)中心的存儲成本；如果MFCSS系統(tǒng)內不存在某個文件與用戶上傳的文件具有相同的指紋信息，則存儲接口管理子系統(tǒng)向應用程序請求文件的二進制流.

步驟10. 應用程序獲取用戶待上傳的多媒體文件流，并傳輸文件流和應用程序指定的存儲目錄結點編號給存儲接口管理子系統(tǒng).

步驟11. 存儲接口管理子系統(tǒng)生成存儲目錄結點編號對應的存儲目錄對象，并獲取該存儲目錄的磁盤存儲空間利用率，之后根據(jù)磁盤存儲空間利用率判斷該存儲目錄是否需要擴容，如果存儲目錄需要擴容，則存儲接口管理子系統(tǒng)獲取擴容存儲目錄，然后生成文件保存路徑；否則，直接生成文件保存路徑.

存儲接口管理子系統(tǒng)根據(jù)應用程序指定的存儲目錄編號生成保存文件流的存儲目錄對象，之后存儲接口管理子系統(tǒng)通過該存儲目錄編號所在存儲管理子系統(tǒng)獲取該存儲目錄的磁盤存儲空間利用率，如果此時存儲接口管理子系統(tǒng)發(fā)現(xiàn)該存儲目錄所在的存儲服務器的磁盤空間利用率已經達到指定的閾值，則存儲接口管理子系統(tǒng)根據(jù)圖4描述的邏輯擴容流程，向集群管理子系統(tǒng)發(fā)送給該存儲目錄邏輯擴容的指令，然后獲取到擴容的存儲目錄對象，之后存儲接口管理子系統(tǒng)就會把文件流保存到擴容存儲目錄中.

步驟12. 存儲接口管理子系統(tǒng)對用戶待上傳的多媒體文件類型進行識別，并判斷文件類型是否合法，如果合法，則生成文件名，進入步驟13，否則，生成文件上傳結果，進入步驟14.

存儲接口管理子系統(tǒng)根據(jù)文件流識別用戶上傳多媒體文件的文件類型，如果文件類型合法，則存儲接口管理子系統(tǒng)生成一個時間戳并分配一個隨機數(shù)作為文件名；如果文件類型不合法，則生成相應的文件上傳結果.

步驟13. 存儲接口管理子系統(tǒng)保存文件，并向集群管理子系統(tǒng)發(fā)送添加文件指紋信息指令，同時向存儲管理子系統(tǒng)發(fā)送添加文件元數(shù)據(jù)指令，并生成文件上傳結果.

如果應用程序分配的保存該多媒體文件的存儲目錄idx不需要擴容，則存儲接口管理子系統(tǒng)把用戶上傳的多媒體文件流保存到應用程序指定的存儲目錄idx中，否則，集群管理子系統(tǒng)會給存儲目錄idx分配一個擴容存儲目錄idy并記錄相關擴容信息，然后存儲接口管理子系統(tǒng)把用戶上傳的多媒體文件流保存到擴容后的存儲目錄idy中.文件流被保存之后，存儲接口管理子系統(tǒng)向集群管理子系統(tǒng)發(fā)送添加文件指紋信息指令，集群管理子系統(tǒng)收到指令之后會把該文件的指紋信息添加到布隆過濾器中.如果idx沒有被擴容，則存儲接口管理子系統(tǒng)向idx所在的存儲管理子系統(tǒng)發(fā)送添加文件元數(shù)據(jù)指令，否則，存儲接口管理子系統(tǒng)向擴容存儲目錄idy所在的存儲管理子系統(tǒng)發(fā)送添加文件元數(shù)據(jù)指令.存儲管理子系統(tǒng)收到指令之后會保存該文件的元數(shù)據(jù)信息.

步驟14. 應用程序獲取文件上傳結果，并發(fā)送文件上傳結果給用戶.

步驟15. 用戶查看文件上傳結果，多媒體文件被保存到了MFCSS系統(tǒng)中.

為了快速地確定數(shù)據(jù)中心內是否存在某個文件與用戶上傳的文件具有相同的指紋信息，效率最高的方案是將所有的文件元數(shù)據(jù)都加載到服務器的內存中，每次查詢時在內存中進行匹配，但是考慮到服務器內存大小的限制，以及MFCSS系統(tǒng)在運行的過程中文件數(shù)量會快速增長，所有的文件元數(shù)據(jù)很難全部加載到一臺服務器的內存中.在MFCSS系統(tǒng)中，每個存儲管理子系統(tǒng)都將它所管理的存儲服務器上的全部文件元數(shù)據(jù)從磁盤預加載到內存中，并維護文件指紋信息和文件元數(shù)據(jù)之間的映射關系，這樣整個數(shù)據(jù)中心內全部的文件元數(shù)據(jù)都分散存儲于各臺存儲服務器的內存中，充分利用了每臺服務器的內存空間，并且在匹配文件指紋信息的過程中多個存儲管理子系統(tǒng)的匹配過程是并行執(zhí)行的，有效的提高了冗余文件的定位速度，提升了用戶存儲文件的交互體驗.

5 實驗結果與分析

為了評估MFCSS系統(tǒng)的各項性能指標，對系統(tǒng)做了如下測試：寫性能測試、系統(tǒng)響應時間測試、系統(tǒng)吞吐量測試、集群管理子系統(tǒng)和存儲管理子系統(tǒng)內存使用情況測試以及磁盤占用空間測試.為了比較MFCSS與HDFS在保存具有不同冗余度的多媒體文件時性能的差異，在相同的測試環(huán)境下搭建了HDFS原型系統(tǒng).集成了存儲接口管理子系統(tǒng)的應用程序服務器具有4 GB內存，處理器是Intel?CoreTM2 Duo CPU P9400@2.40 GHz；部署集群管理子系統(tǒng)的服務器具有16 GB內存，處理器是Intel?CoreTMi7-4610M CPU@3.00 GHz，同時它還作為HDFS命名空間結點；2臺部署存儲管理子系統(tǒng)的服務器具有2 GB內存，處理器是Intel?CoreTM2 Duo CPU E7500@2.93 GHz，同時這2臺服務器還作為HDFS數(shù)據(jù)結點.整個實驗環(huán)境都在以太網(wǎng)交換機構建的局域網(wǎng)中，使用的交換機是傳輸速率為100 Mbps的TP-LINK TL-SF1008.

5.1 寫性能測試

為了評估MFCSS系統(tǒng)在用戶上傳不同大小多媒體文件情況下系統(tǒng)的寫性能，實驗過程中使用了具有不同大小的17類多媒體文件，每類文件都由數(shù)據(jù)冗余度為0%，25%，40%，50%的樣本構成，實驗過程中對各類型的文件分別做了10次實驗，分析寫性能時使用的是這10次實驗結果的平均值.北京理工大學的焦晨宇[33]在2015年研究了一種可伸縮的分布式文件系統(tǒng)SDFS，并針對海量小文件存儲進行了性能優(yōu)化.為了對比不同文件系統(tǒng)寫性能的差異，本文對HDFS，SDFS，MFCSS系統(tǒng)的寫性能做了對比，圖6顯示了這3個文件系統(tǒng)之間寫性能的差異，其中SDFS的實驗數(shù)據(jù)來源于焦晨宇的論文.

Fig. 6 The writing performance of MFCSS圖6 MFCSS系統(tǒng)寫性能

MFCSS系統(tǒng)在保存非冗余文件時需要由存儲接口管理子系統(tǒng)動態(tài)生成文件的保存路徑，集群管理子系統(tǒng)需要保存文件指紋信息，存儲管理子系統(tǒng)需要保存文件元數(shù)據(jù)，同時存儲接口管理子系統(tǒng)需要把文件流傳輸?shù)酱鎯Ψ掌魃?，這些操作結束之后文件就保存成功了.如果MFCSS系統(tǒng)保存的是冗余文件，那么系統(tǒng)只需保存相關的引用信息就會提示用戶文件保存成功.HDFS和SDFS由于沒有數(shù)據(jù)去冗措施，因此在保存數(shù)據(jù)冗余度較高的多媒體文件時，本文實現(xiàn)的MFCSS系統(tǒng)的性能要優(yōu)于其他2個文件系統(tǒng)，而且MFCSS系統(tǒng)的性能優(yōu)勢隨著數(shù)據(jù)冗余度的提高會變得更加顯著.

5.2 系統(tǒng)響應時間測試

為了評估MFCSS系統(tǒng)在保存多媒體文件時系統(tǒng)的響應時間，實驗過程中使用了大量內容不同的小文件，這些文件的平均大小為100 KB，實驗過程中分別對HDFS和MFCSS系統(tǒng)執(zhí)行讀寫操作各200次，統(tǒng)計系統(tǒng)讀寫的平均響應時間，其中SDFS的實驗數(shù)據(jù)來源于焦晨宇同學的論文[33].

圖7所示為HDFS，SDFS，MFCSS系統(tǒng)響應時間的差異.從圖7中可以看出本文實現(xiàn)的多媒體文件云存儲系統(tǒng)MFCSS在小文件的讀寫上相較于HDFS和SDFS有更好的性能優(yōu)勢，平均響應時間遠低于HDFS，同時也優(yōu)于SDFS.

Fig. 7 The system response time圖7 系統(tǒng)響應時間

5.3 系統(tǒng)吞吐量測試

為了測試存儲目錄邏輯擴容策略的有效性，證明此方法可以有效提高系統(tǒng)的運行效率，實驗過程中采用的數(shù)據(jù)集是100個具有不同內容的1MB大小的文件，模擬了多用戶并發(fā)上傳文件的場景，測試了系統(tǒng)從1臺存儲服務器逐漸擴容到3臺存儲服務器時各個階段的吞吐量，每次實驗都做了10次并取平均值作為實驗結果.

圖8所示是系統(tǒng)吞吐量的測試結果，隨著MFCSS系統(tǒng)存儲服務器的增加，系統(tǒng)的吞吐量逐漸提高，但增加了存儲服務器后系統(tǒng)的吞吐量優(yōu)勢并非立刻展現(xiàn)出來，因為增加存儲服務器的同時系統(tǒng)會增加內存資源、CPU資源和網(wǎng)絡等資源的消耗，隨著并發(fā)用戶數(shù)的增加吞吐量的優(yōu)勢才能得以展現(xiàn).在實驗環(huán)境下，當云存儲系統(tǒng)的存儲服務器數(shù)量從1臺擴展到2臺時，并發(fā)用戶數(shù)在9以內并不能顯示出擴容優(yōu)勢，只有并發(fā)用戶數(shù)超過了9個，具有2臺存儲服務器的系統(tǒng)才會比具有1臺存儲服務器的系統(tǒng)具有更高的吞吐量.當云存儲系統(tǒng)的存儲服務器數(shù)量從2臺擴展到3臺時，系統(tǒng)的吞吐量優(yōu)勢在并發(fā)用戶數(shù)為5時就開始展現(xiàn)出來，并隨著并發(fā)用戶數(shù)的增加，具有3臺存儲服務器的系統(tǒng)具有更加明顯的性能優(yōu)勢.

Fig. 8 The throughput of MFCSS圖8 系統(tǒng)吞吐量

5.4 內存使用測試

在評估MFCSS系統(tǒng)的內存使用情況時，分別測試了用戶上傳2 000，4 000，6 000，8 000，10 000個文件的情況下，集群管理子系統(tǒng)和存儲管理子系統(tǒng)各自的內存占用情況，在相同測試環(huán)境下測試了HDFS原型系統(tǒng)在保存這些文件時命名空間結點和數(shù)據(jù)結點的內存使用情況.其中圖9(a)表示集群管理子系統(tǒng)與HDFS命名空間結點的內存使用實驗結果，圖9(b)表示存儲管理子系統(tǒng)與HDFS數(shù)據(jù)結點的內存使用實驗結果.

Fig. 9 The memory usage of MFCSS comparing with HDFS圖9 MFCSS與HDFS的內存使用對比

從圖9(a)可知，在保存相同個數(shù)文件的情況下，集群管理子系統(tǒng)使用的內存少于HDFS命名空間結點，主要是因為HDFS命名空間結點保存了HDFS集群中所有的文件元數(shù)據(jù)，而MFCSS系統(tǒng)的集群管理子系統(tǒng)僅保存了文件元數(shù)據(jù)中的文件指紋信息，因此HDFS命名空間結點消耗更多的內存.從圖9(b)可知，即使存儲管理子系統(tǒng)把它所在的存儲服務器上所有文件元數(shù)據(jù)都加載到內存中，它需要使用的內存空間依然少于HDFS數(shù)據(jù)結點，主要是因為HDFS原型系統(tǒng)的數(shù)據(jù)結點需要維護每個數(shù)據(jù)塊的塊報告(block report)以及其他數(shù)據(jù)塊相關信息，因此它需要消耗更多的內存空間.

5.5 磁盤占用空間測試

為了評估MFCSS系統(tǒng)在節(jié)省磁盤占用空間方面的性能，實驗過程中把系統(tǒng)部署在課題組局域網(wǎng)后，供課題組的其他成員通過本系統(tǒng)上傳多媒體文件，圖10所示為10周之內課題組成員通過MFCSS系統(tǒng)累計上傳的多媒體文件總量和這些文件實際占用磁盤空間的對比圖.

Fig. 10 The disk usage of MFCSS圖10 磁盤占用空間

在剛開始的幾周里，MFCSS系統(tǒng)積累的用戶數(shù)據(jù)較少，因此用戶上傳的多媒體文件都需要保存到磁盤中，過一段時間之后MFCSS系統(tǒng)積累了大量用戶數(shù)據(jù)，因此用戶上傳的多媒體文件會越來越多的被系統(tǒng)判定為冗余文件，此時系統(tǒng)只會記錄相關的文件引用信息，并不會重復的保存用戶數(shù)據(jù)，因此用戶累計上傳的文件大小和這些文件的實際磁盤占用空間之間的差距逐漸增大，而且差距越來越明顯.

6 總 結

本文分析了目前主流的分布式文件系統(tǒng)的優(yōu)點和不足，為了解決數(shù)據(jù)冗余度高的應用程序在低存儲成本條件下對多媒體文件進行分布式存儲的難題，提出了一種分布式存儲目錄建模方案，該建模方案具有很高的靈活性，允許應用程序自定義存儲目錄樹的結構.為了去除數(shù)據(jù)中心內重復的多媒體文件數(shù)據(jù)，提出了一種數(shù)據(jù)去冗方案，并在降低了存儲成本且不影響用戶體驗的情況下，解決了多媒體文件在MFCSS系統(tǒng)內的數(shù)據(jù)去冗難題.在識別重復數(shù)據(jù)的過程中，使用布隆過濾器加快了識別冗余文件的速度.基于分布式存儲目錄建模方案實現(xiàn)的MFCSS系統(tǒng)，簡化了應用程序管理分布式環(huán)境中多媒體文件的過程，在保存數(shù)據(jù)冗余度較高的多媒體文件時具有良好的寫性能，可以有效提高磁盤的存儲效率，同時具備良好的擴展性，還可以加快用戶與MFCSS系統(tǒng)之間傳輸文件的平均速度.

在未來的工作中，為提高系統(tǒng)的可靠性，將會使用副本策略保護MFCSS系統(tǒng)中存儲的文件，提高系統(tǒng)的可靠性，同時將會對多媒體文件進行分類，不同類型的多媒體文件由不同的布隆過濾器進行管理，進一步提高冗余文件的定位速度.

[1]Fu Yinxun, Luo Shengmei, Shu Jiwu. Survey of secure cloud storage system and key technologies[J]. Journal of Computer Research and Development, 2013, 50(1): 136-145 (in Chinese)

(傅穎勛, 羅圣美, 舒繼武. 安全云存儲系統(tǒng)與關鍵技術綜述[J]. 計算機研究與發(fā)展, 2015, 50(1): 136-145)

[2]Liu Jian, Huang Kun, Rong Hong, et al. Privacy-preserving public auditing for regenerating-code-based cloud storage[J]. IEEE Trans on Information Forensics and Security, 2015, 10(7): 1513-1528

[3]Lü Yisheng, Duan Yanjie, Kang Wenwen, et al. Traffic flow prediction with big data: A deep learning approach[J]. IEEE Trans on Intelligent Transportation Systems, 2015, 16(2): 865-873

[4]Vandenbroucke K, Ferreira D, Goncalves J, et al. Mobile cloud storage: A contextual experience[C] //Proc of the 16th Int Conf on Human-computer Interaction with Mobile Devices & Services. New York: ACM, 2014: 101-110

[5]Eyben F, Weninger F, Gross F, et al. Recent developments in opensmile, the munich open-source multimedia feature extractor[C] //Proc of the 21st ACM Int Conf on Multimedia. New York: ACM, 2013: 835-838

[6]Armbrust M, Fox A, Griffith R, et al. A view of cloud computing[J]. Communications of the ACM, 2010, 53(4): 50-58

[7]Zhao Zhenpeng, Badam S K, Chandrasegaran S, et al. A multimedia sketching system for collaborative creativity[C] //Proc of the 32nd Annual ACM Conf on Human Factors in Computing Systems. New York: ACM, 2014: 1235-1244

[8]Dinh H T, Lee C, Niyato D, et al. A survey of mobile cloud computing: architecture, applications, and approaches[J]. Wireless Communications and Mobile Computing, 2013, 13(18): 1587-1611

[9]Kwon S J. A cache-based flash translation layer for TLC-based multimedia storage devices[J]. ACM Trans on Embedded Computing Systems, 2016, 15(1): 11-12

[10]Levi A, Mokryn O, Diot C, et al. Finding a needle in a haystack of reviews: Cold start context-based hotel recommender system[C] //Proc of the 6th ACM Conf on Recommender Systems. New York: ACM, 2012: 115-122

[11]Duan Huiying, Liu Feifei. Building and managing reputation in the environment of Chinese e-commerce: A case study on Taobao[C] //Proc of the 2nd Int Conf on Web Intelligence, Mining and Semantics. New York: ACM, 2012: 43-49

[12]Ross R B, Thakur R. PVFS: A parallel file system for Linux clusters[C] //Proc of the 4th Annual Linux Showcase and Conf. Berkeley, CA: USENIX Association, 2000: 391-430

[13]Piernas J, Nieplocha J, Felix E J. Evaluation of active storage strategies for the lustre parallel file system[C] //Proc of ACM/IEEE Conf on Supercomputing. New York: ACM, 2007: 28-30

[14]Ghemawat S, Gobioff H, Leung S T. The Google file system[J]. ACM SIGOPS Operating Systems Review, 2003, 37(5): 29-43

[15]Shvachko K, Kuang H, Radia S, et al. The hadoop distributed file system[C] //Proc of the 26th IEEE Conf on Mass Storage Systems and Technologies. Piscataway, NJ: IEEE, 2010: 7-13

[16]Chu Yu. Taobao file system[OL]. [2016-05-06] http://code.taobao.org/p/tfs/wiki/intro/

[17]Kubiatowicz J, Bindel D, Chen Y, et al. Oceanstore: An architecture for global-scale persistent storage[J]. ACM SIGPLAN Notices, 2000, 35(11): 190-201

[18]Adya A, Bolosky W J, Castro M, et al. FARSITE: Federated, available, and reliable storage for an incompletely trusted environment[J]. ACM SIGOPS Operating Systems Review, 2002, 36(1): 9-14

[19]Weil S A, Brandt S A, Miller E L, et al. Ceph: A scalable, high-performance distributed file system[C] //Proc of the 7th Symp on Operating Systems Design and Implementation. Berkeley: USENIX Association, 2006: 307-320

[20]Burns A, Wellings A. Real-Time Systems and Programming Languages: Ada, Real-Time Java and C/Real-Time POSIX[M]. Boston: Addison-Wesley Educational Publishers Inc, 2009

[21]Chung C-Y, Lee C-L, Liu T-J. A high performance and low cost distributed file system[C] //Proc of the 2nd Int Conf on Software Engineering and Service Science (ICSESS). Piscataway, NJ: IEEE, 2011: 47-50

[22]Hao Peng, Wang Lirong, Wang Jiacai, et al. Design and implement of file linked distributed file system[C] //Proc of Conf on the Computer Science and Information Engineering. Piscataway, NJ: IEEE, 2009: 305-309

[23]Xiong Jin, Li Jianyu, Tang Rongfeng, et al. Improving data availability for a cluster file system through replication[C] //Proc of the 6th Conf on the Parallel and Distributed Processing. Piscataway, NJ: IEEE, 2008: 7-15

[24]Cao Liang, Wang Yu, Xiong Jin. Building highly available cluster file system based on replication[C] //Proc of the 7th Conf on the Parallel and Distributed Computing. Piscataway, NJ: IEEE, 2009: 94-101

[25]Chao H-C, Liu T-J, Kong-H, et al. A seamless and reliable distributed network file system utilizing webspace[C] //Proc of the 10th Int Symp on Web Site Evolution. Piscataway, NJ: IEEE, 2008: 65-68

[26]Dong Bo, Qiu Jie, Zheng Qinghua, et al. A novel approach to improving the efficiency of storing and accessing small files on Hadoop: A case study by PowerPoint files[C] //Proc of Conf on the Services Computing (SCC). Piscataway, NJ: IEEE, 2010: 65-72

[27]Dong Bo, Zheng Qinghua, Tian Feng, et al. An optimized approach for storing and accessing small files on cloud storage[J]. Journal of Network and Computer Applications, 2012, 35(6): 1847-1862

[28]Chandrasekar S, Dakshinamurthy R, Seshakumar P G, et al. A novel indexing scheme for efficient handling of small files in hadoop distributed file system[C] //Proc of Conf on the Computer Communication and Informatics (ICCCI). Piscataway, NJ: IEEE, 2008: 5-9

[29]Vorapongkitipun C, Nupairoj N. Improving performance of small-file accessing in Hadoop[C] //Proc the 11th of Conf on Computer Science and Software Engineering (JCSSE). Piscataway, NJ: IEEE, 2014: 200-205

[30]Fu Yinjin, Xiao Nong, Liu Fang. Research and development on key techniques of data deduplication[J]. Journal of Computer Research and Development, 2012, 49(1): 12-20 (in Chinese)

(付印金, 肖儂, 劉芳. 重復數(shù)據(jù)刪除關鍵技術研究進展[J]. 計算機研究與發(fā)展, 2012, 49(1): 12-20)

[31]Boucher T D, Auslander D M, Bash C E, et al. Viability of dynamic cooling control in a data center environment[J]. Journal of Electronic Packaging, 2006, 128(2): 137-144

[32]Song Haoyu, Dharmapurikar S, Turner J, et al. Fast Hash table lookup using extended bloom filter: An aid to network processing[J]. ACM SIGCOMM Computer Communication Review, 2005, 35(4): 181-192

[33]Jiao Chenyu. The design and application of a scalable distributed file system [D]. Beijing: Beijing Institute of Technology, 2015 (in Chinese)

(焦晨宇. 可伸縮分布式文件系統(tǒng)及其應用[D]. 北京: 北京理工大學, 2015)