基于Hadoop的矢量空間數據庫技術

孟 輝，朱美正，張鋒葉

(華北計算技術研究所地理信息與圖形圖像技術研發(fā)中心，北京 100083)

0 引言

隨著GIS應用的發(fā)展和普及，地理數據的空間和時間分辨率不斷提高，其數據量將面對迅速增長的壓力。大型GIS系統(tǒng)對海量數據的管理能力和多用戶高效并發(fā)訪問的要求也越來越高。傳統(tǒng)GIS對數據的組織形式大多為文件系統(tǒng)與數據庫結合或者完全基于關系型數據庫的方式，這2種構架在解決日益增長的空間數據問題的思路一般為Scale-up模式的擴展，即增加垂直方向上硬件的處理能力。這種模式擴展成本很高，并且硬件更新的速度遠遠跟不上數據膨脹的速度，在應對海量數據管理上顯得力不從心。云計算的出現為解決海量空間數據的管理提供了新的思路。得益于云計算集群多機協同作業(yè)的優(yōu)勢，利用云計算系統(tǒng)可以輕松地將廉價的計算資源組織起來形成存儲量大、運算性能高的計算集群，并且云計算系統(tǒng)采用Scale-out的擴展模式，當現有集群性能、存儲出現不足時，可以簡單地通過添加新的機器來實現集群的擴展。這種縱向擴展省去了數據遷移的代價，擴展成本低，硬件資源廉價，較傳統(tǒng)Scale-up模式有明顯優(yōu)勢。本文研究存儲的矢量數據是空間數據中結構復雜、查詢顯示困難的數據類型。矢量數據具有半結構化特點，存儲設計比較困難，而且用戶經?；谑噶繑祿龃罅康牟樵冇嬎悴僮?，對矢量數據庫的設計直接影響到用戶請求服務的質量和服務體驗。矢量數據庫是地理信息系統(tǒng)的基礎與關鍵，其設計的好壞直接影響整個系統(tǒng)的性能與質量，因此有必要對其進行深入的研究與設計。大型的GIS系統(tǒng)，地理信息采集入庫后改動一般較少，大部分的用戶請求為讀操作，為提高存儲模型設計的針對性，本文將矢量數據庫面向的場景設定為多用戶高并發(fā)訪問。HDFS分布式文件系統(tǒng)是云計算的一種開源方案，在處理海量數據方面有著廣泛的應用。本文采用基于HDFS分布式文件系統(tǒng)，由HBase分布式數據庫來管理存儲海量的矢量數據，充分利用分布式集群海量的存儲空間和高效的并行運算，解決海量矢量數據的存儲和多用戶高效并發(fā)訪問的問題。

1 Hadoop及HBase簡介

Hadoop是一個分布式系統(tǒng)基礎架構，由Apache基金會開發(fā)。它可以對用戶屏蔽底層分布式細節(jié)，支持分布式程序，充分利用集群的高運算速度和海量數據存儲。Hadoop實現了一個分布式文件系統(tǒng)HDFS(Hadoop Distributed File System)和 MapReduce并行計算框架。2部分分屬Hadoop邏輯上的2層，如圖1所示。HDFS是Hadoop框架的底層實現部分，具有高容錯性(fault-tolerent)的特點，并且設計用來部署在低廉的(low-cost)硬件上。HDFS放寬了POSIX的要求，這樣可以以流的形式訪問文件系統(tǒng)中的數據，能提供高吞吐量的數據訪問。MapReduce是在HDFS的基礎上實現的并行計算框架，用戶可以使用它輕松進行并行編程。MapReduce計算由2個階段組成:Map映射階段和Reduce規(guī)約階段。首先Map函數把一組(Key，Value)輸入，經過Map階段的處理生成一組中間結果(Key，Value)，然后Reduce函數匯總所有Map的中間結果進行合并化簡。分布式計算中移動數據的代價總是高于移動計算的代價。因此MapReduce將計算作業(yè)細化成小的分片分配到不同機器上進行計算，既保證了數據的可靠性又方便MapReduce在數據宿主機器上進行計算。

圖1 Hadoop的結構圖

由于HDFS設計之初的目的是存儲大文件，一個典型HDFS文件大小一般都在G字節(jié)至T字節(jié)。其可以存儲的文件容量可以達到海量，但是HDFS存儲的文件數量并不能達到海量。當HDFS中存儲的文件數超過一定量時，系統(tǒng)的性能會嚴重降低，足見其對海量小文件支持并不好。因此要將單文件數據量較小的矢量數據存儲到HDFS中，還需要借助HBase分布式數據庫管理系統(tǒng)來實現。

HBase是Google公司Bigtable的開源實現，是一個功能強大的分布式數據庫系統(tǒng)。與傳統(tǒng)關系型數據庫不同的是，它的數據組織是按列來存儲的，因此可以不用遵守第一范式的約束存儲半結構、非結構的數據。HBase可以處理非常龐大的表，可以用普通計算機處理超過10億行數據及由數百列數據組成的表。HBase的這一特性正好可以用來存儲管理文件較小但是文件數量海量的矢量數據。HBase的底層物理存儲可以基于任何文件系統(tǒng)，但是為了支持高性能的數據存取和海量數據的存儲，提高數據的可靠性和系統(tǒng)的健壯性，可以使用HDFS作為文件系統(tǒng)來存儲物理數據文件。將HBase和Hadoop結合起來使用可以解決海量矢量數據塊的存儲問題。

2 矢量空間數據庫整體架構及存儲策略

2.1 整體架構

雖然目前業(yè)界各大地理信息系統(tǒng)都已經具備了比較成熟的空間數據庫技術，但是絕大多數空間數據庫都是針對有限數據和應用規(guī)模的應用場景，采用的大都是基于集中存儲和關系型數據庫管理系統(tǒng)的技術路線。集中式的存儲方案使數據量很難擴展，無法管理海量的空間數據。采用關系型數據庫來管理地理信息，空間數據以數據記錄的形式組織，受限于索引機制，當數據記錄數量增大到一定程度，關系數據庫的訪問性能會嚴重降低，并且其支持的并發(fā)用戶數有限，無法滿足大型地理系統(tǒng)面向大量用戶高效并發(fā)訪問的需求。

沿用傳統(tǒng)的技術路線，無法從根本解決海量空間數據存儲以及高效訪問問題，很難取得質的突破。因此本文摒棄傳統(tǒng)關系數據庫+集中存儲的技術體制，徹底擺脫傳統(tǒng)空間數據庫本質上的缺陷，研究基于分布式存儲的空間數據庫技術。

本文設計的整體結構如圖2所示，數據存儲層采用分布式文件系統(tǒng)和關系數據庫組成，以分布式文件系統(tǒng)存儲用于顯示和空間查詢的矢量數據，這些數據壓縮成數據塊存儲到分布式文件系統(tǒng)中;將用于屬性查詢的空間屬性信息以及圖層描述信息、元數據信息等數據量小、查詢更新頻繁、結構性強的數據存儲在關系數據庫中。分布式半結構數據管理系統(tǒng)HBase在HDFS高性能存儲能力的基礎上提供半結構化空間數據的存儲和管理功能?？臻g數據訪問中間件用于維護存儲在分布式文件系統(tǒng)和關系型數據庫中數據的一致性?？臻g數據訪問引擎用于對上層應用提供數據接入、查詢、存儲等功能。這種存儲方案可以充分利用分布式存儲集群提供的海量存儲空間、平滑的存儲擴展能力，輕松應對海量空間數據的存儲。計算集群的高I/O帶寬和高運算性能可以滿足大用戶量高并發(fā)的訪問需求。同時關系數據庫強大的SQL查詢功能可以用來完成屬性查詢功能。

圖2 整體結構圖

2.2 存儲策略

通過分析，傳統(tǒng)的空間數據庫方案以地理目標為單位進行組織，與大型地理信息系統(tǒng)管理的海量數據量相比存儲粒度過細，查詢讀取數據時需要逐條加載目標信息，導致數據庫的讀取性能很低。本文采用HBase分布式海量半結構化數據管理技術，將矢量數據進行瓦片化分塊處理，每個數據塊交由HBase進行管理，分布存儲到HDFS中。數據瓦片內則基于矢量目標記錄進行存儲組織，并以塊為單位進行壓縮。這樣提高了數據存儲的粒度，極大地提高了加載的速度，明顯地改進了地圖顯示和空間查詢的性能。

矢量數據存儲策略如圖3所示，考慮某一層次的矢量數據，由于可視范圍有限，往往只需要對較小區(qū)域內的矢量數據進行可視化、編輯、更新，如何快速地查找指定區(qū)域的矢量數據是影響系統(tǒng)性能的關鍵因素。為此，本文采用數據分塊的方法來實現矢量數據的快速定位和靈活調度。根據分塊規(guī)則在全球范圍內按一定規(guī)則進行瓦片分塊，對每個瓦片進行唯一標識，建立快速索引。根據全球劃分瓦片后計算當前矢量所覆蓋的范圍，將矢量圖層劃分為一系列子塊，子塊中包含圖層的地理目標，將矢量圖層劃分塊后，在邏輯上空間數據是無縫組織的。對數據塊所包含的地理目標建立地理目標級索引，實現矢量數據的多級索引。將劃分所得的數據塊壓縮后存儲到HBase分布式數據庫中進行管理。同時考慮矢量數據中的空間屬性數據多為結構化數據，通常需要頻繁更新，而且需要按不同字段進行檢索查詢，NoSQL目前的單鍵值存儲限制了屬性查詢的靈活性，并且屬性數據的數據量通常較小，因此本文選擇將屬性數據冗余存儲到關系型數據庫中，充分利用關系型數據庫靈活的檢索特性彌補HBase在檢索方面的不足。這樣存儲在HBase中的矢量數據專門用來進行高速的加載顯示以及空間查詢，存儲在關系型數據庫中的屬性數據用來支持屬性查詢。

圖3 存儲策略

3 矢量空間數據庫設計

空間數據庫作為整個GIS系統(tǒng)最底層的存儲媒介，承載組織矢量數據模型并統(tǒng)一存儲和集中管理的功能，為整個GIS系統(tǒng)提供數據存儲支持。數據庫的讀取性能和面對高并發(fā)訪問的抗壓能力，直接決定了系統(tǒng)對用戶訪問請求的響應速度。良好的數據庫的設計是決定一個空間數據庫性能的基礎和關鍵。

3.1 相關數據結構設計

矢量圖層在全球范圍內按照一定規(guī)則劃分瓦片，瓦片是一次矢量數據存儲的基本單位。本文將一塊瓦片數據組織成一種叫做桶的基本單位。一個桶對應一個地圖瓦片，每個桶屬于且只屬于一個矢量圖層，一個矢量圖層可以包含多個桶。桶是矢量入庫的基本單位也是構建空間索引的基本單位。

桶是根據待存儲的地圖瓦片構建而成。首先桶以目標集合的形式獲得瓦片中的地理目標，通過遍歷目標集合內的所有目標，計算每個目標的最小外界矩形(MBR)，以MBR的幾何中心表示目標的位置;同時統(tǒng)計出所有地理目標的ID范圍，以及桶所包含的目標集合所覆蓋的地理范圍;然后根據桶的地理范圍按照一定規(guī)則劃分成塊，對每一塊內的地理目標建立空間索引。將空間索引以及各個塊所包含的地理目標ID作為桶的組成部分進行保存。將每一個地理目標塊進行壓縮序列化后存儲到數據庫中。桶的形成過程如圖4所示。

圖4 桶形成過程

3.2 數據庫的物理模型

本文設計將矢量數據冗余存儲到分布式NoSQL數據庫HBase和關系數據庫Oracle中。為提高矢量數據的存取效率，簡化數據庫的存儲模型，本文設計直接將矢量數據分塊序列化后以二進制流的形式存儲到HBase中。同時將矢量數據中數據量較小的元數據信息以及需要大量SQL語句查詢的屬性信息冗余存儲到關系數據庫中，彌補HBase查詢操作的不足。

3.2.1 關系數據庫表的設計

系統(tǒng)為了支持系統(tǒng)的大用戶量和高并發(fā)訪問，將矢量數據打包成塊存儲到分布式空間數據庫中。同時考慮屬性數據要大量用到SQL查詢操作，適合存儲到關系數據庫中。矢量數據的描述和管理類信息，數據量小，數據條目少，查詢和修改操作頻繁，亦適合存儲在關系型數據庫(Oracle)中。同時也可利用關系數據庫的事務機制維護關鍵數據的一致性，因此將矢量數據的屬性信息部分冗余存儲到關系型數據庫中。

關系數據庫中存儲的數據均為數據量較小的數據。圖層描述表存儲的是矢量圖層的架子，該表維護一個圖層最基本的描述信息，包括圖層ID、圖層類型、圖層名稱、空間參考、圖層范圍、拓撲信息等信息。圖層中的目標組織需要有唯一的ID，在為圖層創(chuàng)建目標之前需要為目標分配ID，圖層目標ID表用來管理每個圖層地理目標ID的統(tǒng)一分配。當需要批量分配目標ID時，從表中讀取圖層對應的最大ID值，再將分配后的最大ID值存回表中。元數據表包括基本元數據和擴展元數據2部分，圖層和圖幅的元數據統(tǒng)一交由元數據表來維護。以上各表均只有一張，由各個圖層共同使用。

此外在創(chuàng)建圖層時，還會分別為每個圖層相應地創(chuàng)建圖幅信息表、圖幅版本信息表、屬性信息表，表名由圖層ID進行區(qū)分，與具體圖層進行關聯。屬性信息表用來存儲圖層地理目標的屬性信息。當新建圖層時相應地創(chuàng)建屬性信息表。該部分數據與分布式空間數據庫中存儲的屬性信息冗余存儲，方便對矢量數據進行屬性查詢。為支持圖層的分幅管理以及多版本管理，還會為每個圖層建立一張圖幅信息表和圖幅版本表。圖幅信息表用來存儲圖層對應的圖幅的ID、編號、范圍和保存時間。圖幅版本表用來存儲每個圖幅不同版本的信息。

3.2.2 Hbase 表的設計

HDFS分布式文件系統(tǒng)對海量小文件的支持效果不好，因此海量的矢量數據分塊不適合直接由分布式文件系統(tǒng)來存儲，而是交由分布式數據庫HBase來管理，每個矢量數據塊作為HBase表中的一個Cell存儲。如前文所述，HBase為按列存儲的數據庫，表中相鄰記錄的同列族數據在物理存儲上是相鄰組織的。同時HBase物理模型簡單，沒有復雜的關系和事務機制，因此可以滿足對海量數據高性能讀寫的需求。

HBase中存儲的數據主要包括圖層信息——屬性字段和桶信息、矢量數據塊2部分，分別由圖層信息表和矢量數據表來存儲。

圖層信息表VEC_LAYER_INFO用來存儲矢量圖層的屬性字段信息和桶信息。如表1所示，該表由一個列族組成:Info。Info列族又分為2列，分別存儲。該表的存儲為簡單的鍵值對的形式，每一行存儲一個序列化的桶信息。為方便將同一圖層的所有桶信息區(qū)分出來，每行數據的RowKey前綴為圖層ID，RowKey由圖層ID和桶ID拼接組成。當打開圖層時，一次性按前綴將圖層對應的桶信息加載到內存中，用來進行圖層內的空間查詢。

表1 圖層信息表

矢量數據表VEC_DATA用來存儲所有圖層的分塊數據。如表2所示，該表由一個列族組成。Data列族用來存儲分塊數據。

表2 圖層數據表

Data列族存儲的是桶切分成塊后對應范圍內各個圖層的矢量數據。每一個圖層對應該范圍內的矢量目標均被組織成塊，序列化后以二進制流的形式存儲到矢量數據表中。每個圖層的塊都作為Data列族中的一列進行存儲，每一行的列數可以不同。這樣的設計可以保證每塊區(qū)域內各個圖層的數據可以連續(xù)地存儲在一起，方便地圖顯示時連續(xù)地一次性讀取出來，可以提高數據讀取的效率。

3.2.3 物理存儲優(yōu)化

由于HBase表中的數據在組織時是按RowKey的字典序來組織的，字典序上相鄰的RowKey對應的行會被連續(xù)地存儲到HDFS中，HBase的這一存儲特點為底層數據存儲提供了優(yōu)化的空間。利用HBase存儲的這個特點，可以通過設計RowKey的結構來保證將顯示中經常會被一同讀取的數據連續(xù)地存儲到一起，以提高數據讀取的速度。

在實際應用中，同一區(qū)域的各個圖層的數據會被一同讀取出來，因此這些數據應該優(yōu)先存儲到一起。在地圖漫游操作中，當前區(qū)域內的數據塊周圍的數據塊會在后續(xù)的拖動中被讀取，因此這些空間上相鄰的數據塊也應該盡量存儲到一起。所以在讀取HBase中的一塊數據時，會連續(xù)地將該塊周圍的數據一同調入到緩存中，這樣在請求周圍的塊數據時可以直接從內存緩存中獲取，減少HBase訪問文件系統(tǒng)的次數，提高系統(tǒng)的讀取速度。在表設計中，將同一區(qū)域的不同圖層的塊數據作為多個列存儲在Data列族中，這樣可以利用HBase的存儲機制，絕對保證同一區(qū)域內的多個圖層數據連續(xù)存儲在一起。在RowKey的設計中，綜合考慮到圖幅內塊的連續(xù)性和各個圖幅之間的連續(xù)性。圖幅內的塊號按照希爾伯特曲線進行編碼，按照該編碼可以自然地將圖幅內臨近的區(qū)域塊連續(xù)地存儲。在考慮相鄰圖幅連續(xù)存儲的設計時，本文研究標準分幅規(guī)則的圖幅號命名規(guī)則，通過圖幅號獲得圖幅之間的相鄰關系，類似地將每相鄰的16個圖幅按希爾伯特曲線進行編碼，按照編碼來順序存儲相鄰的圖幅數據。最終RowKey的結構如圖5所示。

圖5 RowKey的結構

同時為避免HBase讀寫的單點問題的出現，將每16塊相鄰的圖幅鄰接存儲到一個Region中。不同的16塊圖幅隨機存儲到不同的Region，這樣既可以避免入庫時，多臺客戶端機器同時將數據入到一臺機器中，造成單臺機器的數據寫入成為瓶頸，也可以避免在數據讀取時，無法利用集群多機運算的優(yōu)勢，并行地讀取數據?？紤]到上述需求，本文在RowKey的開頭添加了一個根據圖幅區(qū)域隨機生成的前綴，通過此前綴將不同范圍內的數據分散存儲到不同的Region-Server中去。實驗表明，RowKey的設計好壞大大影響數據庫訪問的性能。

4 實驗結果及分析

4.1 實驗環(huán)境及數據

用作實驗的Hadoop集群由5臺機器組成，系統(tǒng)為Ubuntu Linux。5臺機器上部署HDFS，在其中3臺上部署HBase。關系數據庫采用Oracle，部署在5臺Windows計算機，機器配置與Hadoop集群機器相同。測試客戶端機器由3臺組成，配置均為2 GB內存，2.83 GHz四核CPU，系統(tǒng)同樣為Ubuntu Linux。集群各臺機器的配置及具體程序的部署如圖6所示。

圖6 集群環(huán)境

實驗數據采用矢量數據中數據量最大的1:50000比例尺的數據，選取其中的1000幅作為入庫實驗數據，數據總量為28 GB，圖層包含陸地地貌及土質、居民地及附屬設施等11個圖層。

4.2 矢量入庫

矢量入庫采用3臺客戶端同時進行，每臺客戶端運行3個線程并行入庫。矢量數據的數據主要集中在“陸地地貌及土質”和“居民地及附屬設施”2個圖層。本實驗將“陸地地貌及土質”圖層(26 GB，7003541個目標)和“居民地及附屬設施”(300 MB，673195個目標)存入 HDFS中所用時間分別為:1094.52 min、123.36 min。存入 Oracle 中所用的時間分別為:5316.17 min、613.92 min。

4.3 并發(fā)空間查詢

以數據量最大的“陸地地貌及土質”圖層為待查圖層，圖層內目標數量為7003541。通過在文件中預先定義好1000個覆蓋不同空間范圍的矩形，矩形覆蓋的范圍大小均勻，以矩形為空間查詢條件查詢加載被包含和相交地理目標。使用3臺客戶端以多線程的方式模擬多用戶分別對基于2種存儲方案實現的空間數據庫進行空間查詢。以每臺計算機模擬10個并發(fā)用戶，循環(huán)執(zhí)行查詢條件，持續(xù)10 min。每過10 min每臺計算機增加10個并發(fā)用戶。記錄2種情況下各并發(fā)用戶數空間查詢的平均耗時，并以如折線圖7的形式將實驗結果呈現出來。

圖7 空間查詢實驗結果

從圖7可以看出，隨著并發(fā)用戶數的遞增，基于2種方案的空間數據庫應對空間查詢的響應時間都有所增加，傳統(tǒng)方案實現空間數據庫空間查詢耗時始終較高?；贠racle的空間數據庫，在并發(fā)訪問數較少的情況下請求響應時間比較穩(wěn)定，當并發(fā)訪問數超過一定數量時響應時間會急劇增長;基于Hadoop實現的空間數據庫在并發(fā)訪問數增長時可以保持比較穩(wěn)定的緩慢增長。由此可見基于Hadoop的空間數據庫可以輕松應對高并發(fā)的空間查詢請求，而基于Oracle的空間數據庫則無法滿足高并發(fā)訪問的需求。

4.4 并發(fā)漫游操作

以相同的方式測試空間數據庫在高并發(fā)漫游操作場景下的表現。待測試的空間數據庫實現方案分別為基于傳統(tǒng)關系型數據庫集中存儲、分布式存儲未經存儲優(yōu)化以及基于分布式存儲經過存儲優(yōu)化3種。測試過程為:以“陸地地貌及土質”圖層上某一顯示區(qū)域范圍為起點，之后以1/2圖幅范圍為單位逐次加載區(qū)域四周臨近2個圖幅范圍內的地圖數據，以模擬用戶漫游操作。為避免起點區(qū)域選取的偶然性對實驗結果的影響，實驗開始前隨機在圖層內選取10個起始范圍，當完成以一個區(qū)域起始的漫游之后，再漫游下一個區(qū)域，直到將10個區(qū)域都漫游完記錄下10次操作完成的總耗時，并計算出10次漫游操作的平均耗時。測試依然在并發(fā)用戶數逐級遞增的情況下進行。最終的實驗結果如圖8所示。

圖8 漫游實驗結果

由圖8可以看出，在地圖漫游操作的實驗中，當并發(fā)用戶數較少時基于Oracle集中存儲的方案與基于Hadoop分布式存儲的方案性能相當，略高于后者。但是，當并發(fā)用戶數超過一定數值時，關系數據庫的性能急劇下降，訪問響應時間大幅提高。分布式集群的性能受并發(fā)用戶數的影響不大，只是緩慢地上升。經過存儲優(yōu)化之后，地圖漫游時對臨近數據的加載速度會比未經存儲優(yōu)化情況下快約30%。

5 結束語

本文針對大型GIS系統(tǒng)中海量矢量數據組織困難，面對大量用戶高并發(fā)訪問時效率底下的問題，提出一種全新的基于Hadoop分布式存儲的方案。通過實驗驗證了該方案的有效性，在解決海量矢量數據高效并發(fā)訪問方面效果明顯。

［1］陸嘉恒.Hadoop實戰(zhàn)［M］.北京:機械工業(yè)出版社，2011:260-261.

［2］鄔倫，劉瑜，張晶，等.地理信息系統(tǒng)——原理、方法和應用［M］.北京:科學出版社，2005.

［3］薩師煊，王珊.數據庫系統(tǒng)概述［M］.北京:高等教育出版社，1990.

［4］胡鵬，吳艷蘭，楊傳勇，等.大型GIS與數字地球的空間數學基礎研究［J］.武漢大學學報:信息科學版，2001，26(4):296-302.

［5］劉鵬.云計算［M］.北京:電子工業(yè)出版社，2010:189-230.

［6］龔健雅.地理信息系統(tǒng)基礎［M］.北京:科學出版社，2001:29-35.

［7］常燕卿.大型GIS空間數據組織方法初探［J］.遙感信息，2000(2):28-31.

［8］毋河海.地圖數據庫系統(tǒng)［M］.北京:測繪出版社，1991:236-251.

［9］胡志勇，何建邦.分布式地理信息服務類型及解決方案［C］//中國GIS協會年會論文集.1999.

［10］屈紅剛，潘懋，王勇，等.設計模式在GIS軟件開發(fā)中的應用研究［J］.計算機工程與應用，2003，39(25):1-4.

［11］張洪巖，王欽敏，周成虎，等.“數字地球”與地理信息科學［J］.地球信息科學，2001(4):1-4.

［12］The Apache Software Foundation.Hadoop［DB/OL］.http://hadoop.apache.org/，2011-10-31.

［13］Chang F，Dean J，Ghemawat S，et al.Bigtable:A distributed storage system for structured data［C］//Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation.2006:205-218.

［14］Ghemawat S，Gobioff H，Leung S T.The Google file system［C］//Proceedings of the 19th ACM Symposium on Operation Systems Principles.2003:29-43.