基于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