基于MongoDB的電子地圖瓦片數據存儲和服務研究

邱儒瓊，鄭麗娜，李 兵

（1.中國地質大學（武漢），湖北 武漢430074；2.湖北省基礎地理信息中心，湖北 武漢 430074）

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

1）文件的量級飛速增長，在達到了單機操作系統的查詢性能瓶頸，或超過單機硬盤的擴容范圍時，需要在文件系統級別上擴展和優化。

2）由于文件的備份不方便，導致文件系統訪問的故障轉移和修復出現問題。

3）由于瓦片服務是靠將文件轉換為二進制比特流，再通過客戶端軟件接收二進制流，再將多個瓦片拼接為整張圖像的機制[3]，限制了瓦片服務的發布無法實現分布式。

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

1 MongoDB概述

MongoDB[4]是一個基于分布式文件存儲的數據庫，由C++語言編寫，旨在為WEB應用提供可擴展的高性能數據存儲解決方案。MongoDB是一個介于關系數據庫和非關系數據庫之間的產品，是非關系數據庫當中功能最豐富、最像關系數據庫的。2007年10月，MongoDB由10gen團隊所發展，2009年2月首度推出[5]。它支持的數據結構非常松散，類似json的bson格式，因此可以存儲比較復雜的數據類型。Mongo最大的特點是它支持的查詢語言非常強大，其語法有點類似于面向對象的查詢語言，幾乎可以實現類似關系數據庫單表查詢的絕大部分功能，而且還支持對數據建立索引。

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

2 基于MongoDB的瓦片存儲和服務研究

2.1 研究路線

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

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

2.2 基于MongoDB的瓦片數據存儲和服務實現

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

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

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

1）Dbcommand.cpp：一般數據庫指令，如數據庫、索引的創建、重建、打開/關閉等。

2）dbcommands_admin.cpp：管理指令，如CleanCmd，JournalLatencyTestCmd，ValidateCmd，FSyncCommand。

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

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

同時，通過設計開發基于MongoDB數據庫瓦片讀取的WMTS服務中間件，請求用戶通過標準的WMTS服務接口訪問MongoDB數據庫瓦片，將請求結果返回給用戶。在使用過程中，請求用戶完全不會感覺到這種請求與以往請求的差異性。

實現的核心代碼如下：

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 性能指標對比測試

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

2.3.1 存儲效率對比

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

圖2 存儲效率比對結果表

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

2.3.2 服務訪問效率對比

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

圖3 電子地圖瓦片服務訪問效率對比結果圖

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

2.4 測試結論

在反復的驗證測試中，最終得出結論，“MongoDB+內存緩存中間件”的技術方案可以完全實現現有文件式管理的所有功能，同時通過性能測試指標數據，表明這種技術方案明顯優于現有文件式管理模式。

3 結 語

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

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

[2]許虎 ,聶云峰, 舒堅.基于中間件的瓦片地圖服務設計與實現[J].地球信息科學學報，2010(4) :563-565

[3]CH/Z 9011―2011.地理信息公共服務平臺電子地圖數據規范[S].

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

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

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