基于MongoDB的電子地圖瓦片數(shù)據(jù)存儲和服務(wù)研究

邱儒瓊，鄭麗娜，李 兵

（1.中國地質(zhì)大學(xué)（武漢），湖北 武漢430074；2.湖北省基礎(chǔ)地理信息中心，湖北 武漢 430074）

隨著瓦片[1]（Tile）的概念被提出，利用金字塔模型緩存地圖瓦片的模式代替?zhèn)鹘y(tǒng)WebGIS 地圖模式構(gòu)建WebGIS 地圖框架，大大提高了網(wǎng)絡(luò)地圖的響應(yīng)速度，具有良好的用戶體驗(yàn)。在國家地理信息公共服務(wù)平臺設(shè)計(jì)中，明確將電子地圖緩存服務(wù)[2]作為主要的地圖服務(wù)標(biāo)準(zhǔn)之一。它是將傳統(tǒng)的電子地圖在服務(wù)器端以瓦片的形式預(yù)生成，并利用一定的算法組織并存儲在服務(wù)器磁盤空間下。但這些緩存瓦片不同于正常的文件，瓦片的大小從1 KB到20 KB，瓦片具有“總個數(shù)多、單個文件小”的特點(diǎn)。如果采用基于文件系統(tǒng)的傳統(tǒng)方式保存，將會面臨以下挑戰(zhàn)：

1）文件的量級飛速增長，在達(dá)到了單機(jī)操作系統(tǒng)的查詢性能瓶頸，或超過單機(jī)硬盤的擴(kuò)容范圍時，需要在文件系統(tǒng)級別上擴(kuò)展和優(yōu)化。

2）由于文件的備份不方便，導(dǎo)致文件系統(tǒng)訪問的故障轉(zhuǎn)移和修復(fù)出現(xiàn)問題。

3）由于瓦片服務(wù)是靠將文件轉(zhuǎn)換為二進(jìn)制比特流，再通過客戶端軟件接收二進(jìn)制流，再將多個瓦片拼接為整張圖像的機(jī)制[3]，限制了瓦片服務(wù)的發(fā)布無法實(shí)現(xiàn)分布式。

針對上面的問題，本文探討了采用主流NoSQL數(shù)據(jù)庫MongoDB，利用Nginx、memcahced緩存優(yōu)化機(jī)制，以數(shù)字湖北地理空間框架建設(shè)和湖北省內(nèi)的部分?jǐn)?shù)字城市地理框架建設(shè)等瓦片數(shù)據(jù)存儲為例，探索新的服務(wù)發(fā)布模式，滿足緩存服務(wù)的高并發(fā)性、大數(shù)據(jù)量的訪問。

1 MongoDB概述

MongoDB[4]是一個基于分布式文件存儲的數(shù)據(jù)庫，由C++語言編寫，旨在為WEB應(yīng)用提供可擴(kuò)展的高性能數(shù)據(jù)存儲解決方案。MongoDB是一個介于關(guān)系數(shù)據(jù)庫和非關(guān)系數(shù)據(jù)庫之間的產(chǎn)品，是非關(guān)系數(shù)據(jù)庫當(dāng)中功能最豐富、最像關(guān)系數(shù)據(jù)庫的。2007年10月，MongoDB由10gen團(tuán)隊(duì)所發(fā)展，2009年2月首度推出[5]。它支持的數(shù)據(jù)結(jié)構(gòu)非常松散，類似json的bson格式，因此可以存儲比較復(fù)雜的數(shù)據(jù)類型。Mongo最大的特點(diǎn)是它支持的查詢語言非常強(qiáng)大，其語法有點(diǎn)類似于面向?qū)ο蟮牟樵冋Z言，幾乎可以實(shí)現(xiàn)類似關(guān)系數(shù)據(jù)庫單表查詢的絕大部分功能，而且還支持對數(shù)據(jù)建立索引。

選擇MongoDB這個軟件，首先MongoDB是滿足一些研究所需的必要條件。它是一種區(qū)別于傳統(tǒng)關(guān)系型數(shù)據(jù)庫的文件式新型數(shù)據(jù)庫，是適合現(xiàn)代網(wǎng)絡(luò)應(yīng)用并基于分布式的平臺、高度事務(wù)性的系統(tǒng)，可以幫助解決一些棘手的問題，同時還支持云計(jì)算架構(gòu)的伸縮性。其次，MongoDB軟件本身是開源的，源代碼完全公開，而且有專門的研發(fā)團(tuán)隊(duì)保證這個軟件可以持續(xù)更新。最后MongoDB軟件的研發(fā)初衷是解決在線視頻網(wǎng)站、在線社交網(wǎng)站以及在線購物網(wǎng)站中海量視頻、圖片、文檔的存儲、管理和訪問問題，這種視頻、圖片和文檔單純從文件的類型來看，其本質(zhì)與海量瓦片本身是同類的。

2 基于MongoDB的瓦片存儲和服務(wù)研究

2.1 研究路線

地圖數(shù)據(jù)以海量著稱，如何有效地組織地圖數(shù)據(jù)，使其被高效地訪問，是必須考慮的問題。在WebGIS 中，客戶端經(jīng)常向服務(wù)器發(fā)送地圖圖形數(shù)據(jù)的請求，為了便于傳輸和減輕服務(wù)器端的壓力[6]，可以建立金字塔式的地圖圖形瓦片，將瓦片存儲在MongoDB中，并建立服務(wù)器端緩存，客戶端只需到緩存中下載需要的圖片。

在整個研究過程中，設(shè)計(jì)了一套從“瓦片存儲—瓦片服務(wù)實(shí)現(xiàn)—瓦片讀取”的技術(shù)方案。首先驗(yàn)證使用MongoDB可以滿足瓦片的存儲、服務(wù)的發(fā)布和調(diào)用；其次通過對比驗(yàn)證MongoDB和文件式管理在數(shù)據(jù)拷貝、數(shù)據(jù)存儲和數(shù)據(jù)訪問效率上的性能指數(shù)；最后通過分析MongoDB與文件式管理的劣勢，在數(shù)據(jù)訪問時增加“高速內(nèi)存緩存機(jī)制”中間件，優(yōu)化MongoDB技術(shù)方案，并在同環(huán)境下，完成前面性能指標(biāo)的對比測試。

2.2 基于MongoDB的瓦片數(shù)據(jù)存儲和服務(wù)實(shí)現(xiàn)

研究測試的MongoDB數(shù)據(jù)庫以瓦片類型為單位，以湖北省影像電子地圖瓦片和影像注記瓦片作為研究對象，在MongoDB數(shù)據(jù)庫中創(chuàng)建了hubeiImage和hubeiImageLabel兩個數(shù)據(jù)庫實(shí)例。同時，MongoDB中存放的基本單元為BsonDocument對象，設(shè)計(jì)BsonDocument對象為65 536個瓦片單元，每個單元格存放的就是一張瓦片，每張瓦片不再用行號、列號和級別號3個關(guān)鍵字來唯一標(biāo)示，替換為MongoDB內(nèi)部的文件索引。生成的BsonDocument對象以集合式松散結(jié)構(gòu)進(jìn)行統(tǒng)一管理，統(tǒng)一由MongoDB自動生成不超過2 GB的大文件。

圖1 湖北省影像電子地圖瓦片入庫

根據(jù)這種設(shè)計(jì)方案，湖北省影像瓦片在MongoDB中生成了hubeiimage.0—hubeiimage.60，合計(jì)61個大文件，總大小為113 GB。湖北省影像注記瓦片在MongoDB中生成了hubeiimagelabel.0—hubeiimagelabel.6，合計(jì)7個大文件，合計(jì)大小為5.93 GB。瓦片入庫過程采用command命令進(jìn)行操作，入庫過程見圖1，涉及的操作命令包括[5]：

1）Dbcommand.cpp：一般數(shù)據(jù)庫指令，如數(shù)據(jù)庫、索引的創(chuàng)建、重建、打開/關(guān)閉等。

2）dbcommands_admin.cpp：管理指令，如CleanCmd，JournalLatencyTestCmd，ValidateCmd，F(xiàn)SyncCommand。

3）dbcommands_generic.cpp：常用指令,ListComman dsCmd,LogRotateCmd,PingCommand,CmdSet,CmdGet等。

4）replset_commands.cpp：復(fù)制集指令，CmdReplSetTest，CmdReplSetGetStatus,CmdReplSetReconfig等。

同時，通過設(shè)計(jì)開發(fā)基于MongoDB數(shù)據(jù)庫瓦片讀取的WMTS服務(wù)中間件，請求用戶通過標(biāo)準(zhǔn)的WMTS服務(wù)接口訪問MongoDB數(shù)據(jù)庫瓦片，將請求結(jié)果返回給用戶。在使用過程中，請求用戶完全不會感覺到這種請求與以往請求的差異性。

實(shí)現(xiàn)的核心代碼如下：

public void ReadMongoTile(int x,int y,int z)

{

string tableName = "Z" + z.ToString("00") + "X"+ Convert.ToString((int)(x / 256)) + "Y" + Convert.ToString((int)(y / 256));

int index = x % 256 + 256 * (y % 256);

MongoCollection collection = mongoDb.GetCollection(tableName);

MapEnity e = collection.FindOneByIdAs(index);

int length = 0;

if (e.data != null) length = e.data.Length;

}

2.3 性能指標(biāo)對比測試

為了對基于MongoDB 的瓦片存儲策略以及并發(fā)訪問特性進(jìn)行性能分析，我們搭建了如下的實(shí)驗(yàn)環(huán)境。在局域網(wǎng)內(nèi)，把數(shù)據(jù)庫服務(wù)器部署在一臺4U機(jī)架上，X86/4 Intel XeonE7-8837處理器/24 MB高速緩存/64 GB Registered DDR3內(nèi)存/8塊300 GB 15 000轉(zhuǎn) SAS硬盤/11個PCI-E，操作系統(tǒng)為WindowsServer 2008 的浪潮NF8520服務(wù)器；客戶端的配置為Intel ( R)Core( TM) 2 CPU 3.00 GHz，內(nèi)存3.25 G，操作系統(tǒng)為Windows XP 的臺式機(jī)，進(jìn)行存儲和服務(wù)訪問實(shí)驗(yàn)。由客戶端向服務(wù)器端發(fā)出連接請求，分別利用Mongo DB 2.2.2帶緩存機(jī)制、Mongo DB 2.2.2不帶緩存機(jī)制、文件管理模式進(jìn)行了存儲效率和服務(wù)訪問效率對比。

2.3.1 存儲效率對比

存儲效率對比主要是針對MongoDB數(shù)據(jù)庫入庫和文件式瓦片單次拷貝的時間效率進(jìn)行比對，對比結(jié)果見圖2。

圖2 存儲效率比對結(jié)果表

從圖2的測試指標(biāo)可以看出，MongoDB的瓦片讀取效率是與線程并發(fā)量成正比的，也就是說單進(jìn)程的情況下，上表測試的MongoDB入庫是讀取200張瓦片后一次性存寫入庫，如果優(yōu)化程序到一次性寫入1 000張瓦片后，該程序的入庫效率將提高2～3倍。

2.3.2 服務(wù)訪問效率對比

設(shè)計(jì)開發(fā)了針對服務(wù)發(fā)布效率的測試對比程序，在單進(jìn)程條件下，并發(fā)N個模擬服務(wù)請求，獲取每種技術(shù)方案的返回結(jié)果時間。在設(shè)計(jì)時，加入了帶內(nèi)存緩存機(jī)制的MongoDB方案，即在IIS上設(shè)計(jì)開發(fā)了MemCache中間件，請求首先通過IIS到MemCache，如果緩存中沒有，則再通過訪問MongoDB獲取瓦片。服務(wù)訪問效率測試對比結(jié)果見圖3（橫軸代表并發(fā)數(shù);縱軸代表反饋時間/ms）：

圖3 電子地圖瓦片服務(wù)訪問效率對比結(jié)果圖

從圖3可以明顯看到，隨著并發(fā)量的增加，帶緩存的MongoDB技術(shù)方案明顯優(yōu)于其他2種方案，訪問時間大大低于其余2種方案。

2.4 測試結(jié)論

在反復(fù)的驗(yàn)證測試中，最終得出結(jié)論，“MongoDB+內(nèi)存緩存中間件”的技術(shù)方案可以完全實(shí)現(xiàn)現(xiàn)有文件式管理的所有功能，同時通過性能測試指標(biāo)數(shù)據(jù)，表明這種技術(shù)方案明顯優(yōu)于現(xiàn)有文件式管理模式。

3 結(jié) 語

本文針對MongoDB獨(dú)特高效的體系結(jié)構(gòu)、存儲機(jī)制、索引特點(diǎn)等關(guān)鍵技術(shù)，深入研究了利用MongoDB進(jìn)行瓦片數(shù)據(jù)的存儲，并通過實(shí)驗(yàn)對其高效性進(jìn)行驗(yàn)證。實(shí)驗(yàn)表明，利用MongDB進(jìn)行瓦片數(shù)據(jù)的存儲，數(shù)據(jù)入庫效率將比傳統(tǒng)方式提高2～3倍。隨著并發(fā)量的增加，帶緩存的MongoDB的訪問時間也將縮短2～3倍。目前來說，MongoDB對內(nèi)存要求較高，還不如傳統(tǒng)數(shù)據(jù)庫成熟，只能是對傳統(tǒng)數(shù)據(jù)庫的補(bǔ)充。但對于這種海量小文件的圖片管理應(yīng)用開發(fā)，MongoDB則是一種優(yōu)秀的Web存儲解決之道。同時，利用MongoDB自帶的分布式文件系統(tǒng)（GridFS）進(jìn)行海量影像數(shù)據(jù)的高效管理等問題，還有待于進(jìn)一步深入研究。

[1]王浩，喻占武，曾武，等.基于瓦片壽命和訪問熱度的海量空間數(shù)據(jù)緩存置換策略[J].武漢大學(xué)學(xué)報(bào):信息科學(xué)版，2009,34(6) : 667-668

[2]許虎 ,聶云峰, 舒堅(jiān).基于中間件的瓦片地圖服務(wù)設(shè)計(jì)與實(shí)現(xiàn)[J].地球信息科學(xué)學(xué)報(bào)，2010(4) :563-565

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

[4]分布式文檔存儲數(shù)據(jù)庫MongoDB [EB/OL].http://www.oschina.net/p/mongodb,2014-06-01

[5]霍多羅夫，迪洛爾夫.MongoDB權(quán)威指南[M].北京: 人民郵電出版社，2011

[6]李浩松，朱欣焰，李京偉，等.WebGIS 空間數(shù)據(jù)分布式緩存技術(shù)研究[J].武漢大學(xué)學(xué)報(bào):信息科學(xué)版， 2005,30(12) :1 092-1 095