基于MongoDB GridFS的地图瓦片数据存储研究

邱新忠

（1.浙江省第一测绘院，浙江 杭州 310012）

基于MongoDB GridFS的地图瓦片数据存储研究

邱新忠1

（1.浙江省第一测绘院，浙江 杭州 310012）

从地图瓦片数据存储方式入手，分析了ArcGIS地图瓦片存储散列式和紧凑式的优缺点，从而引入基于MongoDB GridFS的地图瓦片存储方式。通过对常规地图瓦片存储与基于MongoDB GridFS的地图瓦片存储的读取效率进行性能测试和对比分析得出，基于MongoDB GridFS的地图瓦片存储在大数据量时有着明显优势。

地图瓦片；ArcGIS；MongoDB GridFS

随着互联网地图服务应用的不断发展，地图瓦片成为一种新的地理信息数据表达方式。常规地图瓦片存储大多采用文件目录形式进行组织，但随着地图瓦片数据量的不断增长，文件目录形式在数据迁移、备份、读取效率等方面面临着诸多问题，如一个百万数量级的地图瓦片文件目录，如果进行迁移或备份，至少需要2～3 h。为了解决这些问题，本文引入基于MongoDB GridFS的地图瓦片数据存储方式。

地图瓦片是近年来发展起来的一种新型地理信息数据表达方式。它通过将地理信息数据预先可视化处理，并按照一定规则进行切片，切片后的数据就称之为地图瓦片。常见的地图瓦片切割技术为四叉树金字塔模型，如图1所示。由地图瓦片切割模型的原理，决定了地图瓦片数量呈现2倍率的指数增长。研究如何对地图瓦片进行高效存储，以提高地图瓦片的调用速度，具有重要意义。

图1 四叉树金字塔模型

1 常规地图瓦片数据存储

常规地图瓦片数据存储大多采用文件目录形式，以下分别以ArcGIS地图瓦片存储之散列式和紧凑式对比分析其优缺点。

1.1 常规地图瓦片存储之散列式

以ArcGIS Server 9．3地图瓦片存储为例，切片组织基于计算机文件系统的存储组织方式，这种组织方式具有良好的索引性能，用户可以通过级别、行号、列号快速定位到某一张瓦片。但是对于计算机文件系统来说，在一个文件目录里，随着文件数的不断增加，系统对文件的读取效率将急剧下降，如在Windows的NTFS文件系统中，当某个文件夹存储的文件总数超过2 000时，文件读取的效率已明显降低。

1.2 常规地图瓦片存储之紧凑式

以ArcGIS Server 10．0地图瓦片存储为例，切片组织与之前散列式存储有了较大改进，虽然也是基于计算机文件系统的存储组织方式，但是这种存储格式占用空间更少，复制迁移更方便。由于这种数据存储特点（每个bundle数据包存储16 384个瓦片文件），具体读取单个瓦片时，需要根据bundle数据存储格式进行解析。目前ESRI官方没有提供外部读取接口，如采用这种存储格式，需购置ArcGIS Server商业地图软件。

综上所述，对于互联网地图服务应用来说，以上2种方式各有利弊。散列式存储无需购置商业软件，但对大数据量存储效率不高；紧凑式存储虽然解决了大数据量备份、迁移等问题，但对于用户来说，需购置ArcGIS Server大型商业地图软件才能应用。

2 基于MongoDB GridFS的地图瓦片存储

2.1 MongoDB GridFS简介

MongoDB是一个开源、NoSQL的文档型数据库。MongoDB使用一种类似JSON的BSON格式进行数据存储，由于这种数据存储格式的松散性，可以存储多种复杂的数据类型。

GridFS是MongoDB中用户存储大对象的工具。GridFS将每个文件对象分成2部分存储：文件的实际内容（二进制数据）被存在一个集合（fs．chunks）中；文件有关的meta数据（如文件名、大小、用户自定义的属性等）将会被存在另一个集合（fs．files）中。GridFS会将大文件对象分割成多个小的文件片段（chunk），每个片段一般容量为256 K，每个片段将作为MongoDB的一个文档被存储在Chunks集合中。如此，就实现了分布式数据库文件存储。

2.2 MongoDB GridFS地图瓦片存储

MongoDB作为一种存储JSON格式的数据库，对地图瓦片存储无疑是恰当不过的。通过为每张瓦片建立索引“_id”（如瓦片的行列号及级别），如图2所示，瓦片读取时即可利用key-value键值对唯一获取该张瓦片。

图2 MongoDB地图瓦片组织

为了将常规地图瓦片存储导入MongoDB，首先需要开发导入工具。如图3所示，通过该工具可以非常便捷地将常规文件目录组织的瓦片存储导入MongoDB GridFS。

图3 瓦片入库工具

3 性能测试

以浙江省地图瓦片数据为例，浙江省陆域面积约10．18万km2，仅占全国面积的1．06%，是中国面积最小的省份之一。浙江省处于北纬27°～31．5°、东经118°～123．5°之间。按照国际通用的地图瓦片切割规则，以西经180°、北纬90°为切图原点，向东向南按行列递增，瓦片规格256像素×256像素，瓦片分辨率及分级如表1所示。

表1 地图瓦片分级表

根据浙江省范围，全省7～17级瓦片数量近400万，其中17级达到280多万，单目录文件数达2 000以上。通过对常规地图瓦片存储与基于MongoDB的地图瓦片存储在地图瓦片读取效率方面的比较，探索瓦片读取的性能。由于地图瓦片读取都是通过Web形式进行的，因此，在性能测试之前，先编写2个Web服务，分别读取常规地图瓦片存储以及基于MongoDB的地图瓦片存储（限于篇幅，读取常规地图瓦片存储的代码略）。Web服务均以IIS作为Web服务器进行发布。

测试工具采用LoadRunner 11．0，测试环境由一台客户机及一台服务器组成,如表2所示，网络带宽为100 Mb/s。

表2 测试环境详细情况

采用LoadRunner对2个Web服务进行并发性测试，分别以10个用户、20个用户、50个用户、100个用户作为并发测试对象，测试结果如表3、图4、图5所示。

表3 试结果表

图5 单目录文件大于2 000时的结果比较

从图4、图5可知，当常规地图瓦片存储单目录文件数小于1 000时，平均响应时间与MongoDB地图瓦片存储基本一致；当常规地图瓦片存储单目录文件数大于2 000时，平均响应时间明显大于MongoDB地图瓦片存储的响应时间。

可见，MongoDB地图瓦片存储在大数据量方面有着明显优势，但对系统内存的占用要求很高。如何改进MongoDB的内存占用量还有待进一步研究。

[1] 陈超,王亮,闫浩文,等．一种基于NoSQL的地图瓦片数据存储技术[J]．测绘科学,2013(1):142-143

[2] 郭武士．基于MongoDB GridFS的图片存储方案的实现[J]．四川工程职业技术学院学报,2011(4):39-41

[3] 张恩,张广弟,兰磊．基于MongoDB的海量空间数据存储和并行[J]．地理空间信息,2014,12(1):46-48

[4] 陈慧英． 基于NoSQL数据库的海量天文图像分布存储研究[D]．昆明：昆明理工大学,2012

[5] CH/Z 9011-2011 地理信息公共服务平台:电子地图数据规范[S]．

P208

B

1672-4623（2016）02-0050-03

10.3969/j.issn.1672-4623.2016.02.018

邱新忠，高级工程师，注册测绘师，主要从事地理信息技术管理及应用。

2014-09-02。

项目来源：浙江省地理空间数据交换和共享平台资助项目（[2008]353）。