基于MongoDB GridFS的地圖瓦片數(shù)據(jù)存儲研究

邱新忠

（1.浙江省第一測繪院，浙江 杭州 310012）

基于MongoDB GridFS的地圖瓦片數(shù)據(jù)存儲研究

邱新忠1

（1.浙江省第一測繪院，浙江 杭州 310012）

從地圖瓦片數(shù)據(jù)存儲方式入手，分析了ArcGIS地圖瓦片存儲散列式和緊湊式的優(yōu)缺點，從而引入基于MongoDB GridFS的地圖瓦片存儲方式。通過對常規(guī)地圖瓦片存儲與基于MongoDB GridFS的地圖瓦片存儲的讀取效率進(jìn)行性能測試和對比分析得出，基于MongoDB GridFS的地圖瓦片存儲在大數(shù)據(jù)量時有著明顯優(yōu)勢。

地圖瓦片；ArcGIS；MongoDB GridFS

隨著互聯(lián)網(wǎng)地圖服務(wù)應(yīng)用的不斷發(fā)展，地圖瓦片成為一種新的地理信息數(shù)據(jù)表達(dá)方式。常規(guī)地圖瓦片存儲大多采用文件目錄形式進(jìn)行組織，但隨著地圖瓦片數(shù)據(jù)量的不斷增長，文件目錄形式在數(shù)據(jù)遷移、備份、讀取效率等方面面臨著諸多問題，如一個百萬數(shù)量級的地圖瓦片文件目錄，如果進(jìn)行遷移或備份，至少需要2～3 h。為了解決這些問題，本文引入基于MongoDB GridFS的地圖瓦片數(shù)據(jù)存儲方式。

地圖瓦片是近年來發(fā)展起來的一種新型地理信息數(shù)據(jù)表達(dá)方式。它通過將地理信息數(shù)據(jù)預(yù)先可視化處理，并按照一定規(guī)則進(jìn)行切片，切片后的數(shù)據(jù)就稱之為地圖瓦片。常見的地圖瓦片切割技術(shù)為四叉樹金字塔模型，如圖1所示。由地圖瓦片切割模型的原理，決定了地圖瓦片數(shù)量呈現(xiàn)2倍率的指數(shù)增長。研究如何對地圖瓦片進(jìn)行高效存儲，以提高地圖瓦片的調(diào)用速度，具有重要意義。

圖1 四叉樹金字塔模型

1 常規(guī)地圖瓦片數(shù)據(jù)存儲

常規(guī)地圖瓦片數(shù)據(jù)存儲大多采用文件目錄形式，以下分別以ArcGIS地圖瓦片存儲之散列式和緊湊式對比分析其優(yōu)缺點。

1.1 常規(guī)地圖瓦片存儲之散列式

以ArcGIS Server 9．3地圖瓦片存儲為例，切片組織基于計算機文件系統(tǒng)的存儲組織方式，這種組織方式具有良好的索引性能，用戶可以通過級別、行號、列號快速定位到某一張瓦片。但是對于計算機文件系統(tǒng)來說，在一個文件目錄里，隨著文件數(shù)的不斷增加，系統(tǒng)對文件的讀取效率將急劇下降，如在Windows的NTFS文件系統(tǒng)中，當(dāng)某個文件夾存儲的文件總數(shù)超過2 000時，文件讀取的效率已明顯降低。

1.2 常規(guī)地圖瓦片存儲之緊湊式

以ArcGIS Server 10．0地圖瓦片存儲為例，切片組織與之前散列式存儲有了較大改進(jìn)，雖然也是基于計算機文件系統(tǒng)的存儲組織方式，但是這種存儲格式占用空間更少，復(fù)制遷移更方便。由于這種數(shù)據(jù)存儲特點（每個bundle數(shù)據(jù)包存儲16 384個瓦片文件），具體讀取單個瓦片時，需要根據(jù)bundle數(shù)據(jù)存儲格式進(jìn)行解析。目前ESRI官方?jīng)]有提供外部讀取接口，如采用這種存儲格式，需購置ArcGIS Server商業(yè)地圖軟件。

綜上所述，對于互聯(lián)網(wǎng)地圖服務(wù)應(yīng)用來說，以上2種方式各有利弊。散列式存儲無需購置商業(yè)軟件，但對大數(shù)據(jù)量存儲效率不高；緊湊式存儲雖然解決了大數(shù)據(jù)量備份、遷移等問題，但對于用戶來說，需購置ArcGIS Server大型商業(yè)地圖軟件才能應(yīng)用。

2 基于MongoDB GridFS的地圖瓦片存儲

2.1 MongoDB GridFS簡介

MongoDB是一個開源、NoSQL的文檔型數(shù)據(jù)庫。MongoDB使用一種類似JSON的BSON格式進(jìn)行數(shù)據(jù)存儲，由于這種數(shù)據(jù)存儲格式的松散性，可以存儲多種復(fù)雜的數(shù)據(jù)類型。

GridFS是MongoDB中用戶存儲大對象的工具。GridFS將每個文件對象分成2部分存儲：文件的實際內(nèi)容（二進(jìn)制數(shù)據(jù)）被存在一個集合（fs．chunks）中；文件有關(guān)的meta數(shù)據(jù)（如文件名、大小、用戶自定義的屬性等）將會被存在另一個集合（fs．files）中。GridFS會將大文件對象分割成多個小的文件片段（chunk），每個片段一般容量為256 K，每個片段將作為MongoDB的一個文檔被存儲在Chunks集合中。如此，就實現(xiàn)了分布式數(shù)據(jù)庫文件存儲。

2.2 MongoDB GridFS地圖瓦片存儲

MongoDB作為一種存儲JSON格式的數(shù)據(jù)庫，對地圖瓦片存儲無疑是恰當(dāng)不過的。通過為每張瓦片建立索引“_id”（如瓦片的行列號及級別），如圖2所示，瓦片讀取時即可利用key-value鍵值對唯一獲取該張瓦片。

圖2 MongoDB地圖瓦片組織

為了將常規(guī)地圖瓦片存儲導(dǎo)入MongoDB，首先需要開發(fā)導(dǎo)入工具。如圖3所示，通過該工具可以非常便捷地將常規(guī)文件目錄組織的瓦片存儲導(dǎo)入MongoDB GridFS。

圖3 瓦片入庫工具

3 性能測試

以浙江省地圖瓦片數(shù)據(jù)為例，浙江省陸域面積約10．18萬km2，僅占全國面積的1．06%，是中國面積最小的省份之一。浙江省處于北緯27°～31．5°、東經(jīng)118°～123．5°之間。按照國際通用的地圖瓦片切割規(guī)則，以西經(jīng)180°、北緯90°為切圖原點，向東向南按行列遞增，瓦片規(guī)格256像素×256像素，瓦片分辨率及分級如表1所示。

表1 地圖瓦片分級表

根據(jù)浙江省范圍，全省7～17級瓦片數(shù)量近400萬，其中17級達(dá)到280多萬，單目錄文件數(shù)達(dá)2 000以上。通過對常規(guī)地圖瓦片存儲與基于MongoDB的地圖瓦片存儲在地圖瓦片讀取效率方面的比較，探索瓦片讀取的性能。由于地圖瓦片讀取都是通過Web形式進(jìn)行的，因此，在性能測試之前，先編寫2個Web服務(wù)，分別讀取常規(guī)地圖瓦片存儲以及基于MongoDB的地圖瓦片存儲（限于篇幅，讀取常規(guī)地圖瓦片存儲的代碼略）。Web服務(wù)均以IIS作為Web服務(wù)器進(jìn)行發(fā)布。

測試工具采用LoadRunner 11．0，測試環(huán)境由一臺客戶機及一臺服務(wù)器組成,如表2所示，網(wǎng)絡(luò)帶寬為100 Mb/s。

表2 測試環(huán)境詳細(xì)情況

采用LoadRunner對2個Web服務(wù)進(jìn)行并發(fā)性測試，分別以10個用戶、20個用戶、50個用戶、100個用戶作為并發(fā)測試對象，測試結(jié)果如表3、圖4、圖5所示。

表3 試結(jié)果表

圖5 單目錄文件大于2 000時的結(jié)果比較

從圖4、圖5可知，當(dāng)常規(guī)地圖瓦片存儲單目錄文件數(shù)小于1 000時，平均響應(yīng)時間與MongoDB地圖瓦片存儲基本一致；當(dāng)常規(guī)地圖瓦片存儲單目錄文件數(shù)大于2 000時，平均響應(yīng)時間明顯大于MongoDB地圖瓦片存儲的響應(yīng)時間。

可見，MongoDB地圖瓦片存儲在大數(shù)據(jù)量方面有著明顯優(yōu)勢，但對系統(tǒng)內(nèi)存的占用要求很高。如何改進(jìn)MongoDB的內(nèi)存占用量還有待進(jìn)一步研究。

[1] 陳超,王亮,閆浩文,等．一種基于NoSQL的地圖瓦片數(shù)據(jù)存儲技術(shù)[J]．測繪科學(xué),2013(1):142-143

[2] 郭武士．基于MongoDB GridFS的圖片存儲方案的實現(xiàn)[J]．四川工程職業(yè)技術(shù)學(xué)院學(xué)報,2011(4):39-41

[3] 張恩,張廣弟,蘭磊．基于MongoDB的海量空間數(shù)據(jù)存儲和并行[J]．地理空間信息,2014,12(1):46-48

[4] 陳慧英． 基于NoSQL數(shù)據(jù)庫的海量天文圖像分布存儲研究[D]．昆明：昆明理工大學(xué),2012

[5] CH/Z 9011-2011 地理信息公共服務(wù)平臺:電子地圖數(shù)據(jù)規(guī)范[S]．

P208

B

1672-4623（2016）02-0050-03

10.3969/j.issn.1672-4623.2016.02.018

邱新忠，高級工程師，注冊測繪師，主要從事地理信息技術(shù)管理及應(yīng)用。

2014-09-02。

項目來源：浙江省地理空間數(shù)據(jù)交換和共享平臺資助項目（[2008]353）。