基于MongoDB GridFS的地图瓦片数据存储研究
2016-12-26邱新忠
邱新忠
(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)。