| MongoDB存储地图瓦片技术在国情普查建库中的应用 |
2. 安徽省智慧城市与地理国情监测重点实验室, 安徽 合肥, 230031
2. Anhui Key Laboratory of Smart City and Geographical Condition Monitoring, Hefei 230031, China
安徽省第一次地理国情普查工作于2015年8月全面进入数据成果整理、建库及管理系统的建设阶段。本次普查共形成了影像、地形地貌、地表覆盖、国情要素、解译样本、元数据、专题信息等7大类数据成果, 累计数据量达4.74 TB。
安徽省地理国情普查数据库管理系统, 采用C/S架构进行设计与搭建, 基于ArcSDE + Oracle的建库模式实现了对上述国情普查数据成果的管理与展示。在建设的过程中, 我们发现在管理系统中加载各类地图数据图层时, 当遇到数据量大或者图斑个数多的图层(例如影像、地表覆盖层等)的情况, 如果采用传统的直接从数据库中读取数据显示的方式, 图层的显示速度会非常慢, 用户体验很差。为了解决这个问题, 引入了地图瓦片技术, 改变传统的直接读取数据库中的原始数据为读取配对的地图瓦片, 从而达到提升系统加载地图时的显示速度, 优化用户体验的目的。但如何对地图瓦片数据进行合理的组织和存储, 以及怎样快速地查询和检索, 又成为了系统建设过程中一个技术难点。
1 传统地图瓦片数据存储与MongoDB方式的比较传统的地图瓦片数据有文件和关系型数据库两种存储形式。由于国情普查数据库中管理的是省、市、县(区)三级数据成果, 因此, 在制作地图瓦片时, 往往涉及大、中、小三类比例尺, 产生的地图瓦片数据的量大。后期随着地理国情监测项目的常规性开展, 瓦片数据的文件量急速增大, 终将达到单机操作系统的查询性能瓶颈, 或超过单机硬盘的扩容范围。此外, 还存在备份和恢复不方便以及难以实现分布式数据存储的问题。
关系型数据库适宜存储格式化数据, 每个关系元组由相同的属性组成, 容易理解且使用方便。然而, 对于结构简单, 基本由键值对组成的瓦片数据来说, 无法发挥优势。瓦片数据往往面临高并发的读取需求, 而传统的关系数据库, 硬盘的I/O是一大瓶颈。为了维护数据的一致性, SQL解析等, 会牺牲读写效率。
MongoDB[1]是一个基于分布式文件存储的数据库, 旨在提供可扩展的高性能数据存储解决方案[2]。该数据库的文件存储采用面向集合的松散的bson格式, 具备存储比较复杂的数据类型的能力, 同时它自带一个分布式文件系统用来支持海量数据的存储。
近几年, 随着数据库技术的不断发展, 瓦片数据研究的不断深入, 出现了基于NoSQL的MongoDB存储瓦片的技术。相比较早期的技术MongoDB存储地图瓦片有如下优势。
1) MongoDB数据库以一对键值或数组作为存储对象, 允许创建不同类型的非结构化的或任意格式的字段, 数据耦合度低, 易于扩展, 减少了时间和空间的开销;
2) 高扩展性和可用性。MongoDB数据库可以使用廉价服务器集群, 在不影响服务提供的前提下, 通过动态增加站点的方式, 应对数据与事务规模急剧增加的问题;
3) MongoDB作为一种存储JSON格式的数据库, 通过为每张瓦片建立索引“_id”(如瓦片的行列号及级别), 瓦片读取时可利用key-value键值对唯一获取该张瓦片, 非常适用于地图瓦片的存储;
4) 支持多种数据类型、多种图片格式的地图瓦片数据建库, 同时提供了数据版本信息设置功能, 支持同一数据同一级别多次入库更新, 实现了同一套瓦片数据不同时期版本的多重存储;
5) MongoDB数据库使用成本较低。
综上所述, 本文采用了主流的NoSQL数据库MongoDB, 以安徽省第一次地理国情普查数据库管理系统为例, 设计了一套适用于C/S模式的地理信息数据库管理系统应用场景的瓦片地图存储方案。
2 基于MongoDB存储地图瓦片的方案设计1) 数据源分析。安徽省地理国情普查瓦片数据库中主要存储影像、地形和地表覆盖三类地图瓦片数据。用于入库的文件型地图瓦片数据源均基于安徽省地理信息公共服务平台的切图级别和比例尺[3], 采用ArcGIS格式制作而成。数据按照类型、切图级别和比例尺进行分组存放, 每一组地图瓦片数据文件由瓦片配置文件(conf.xml)、瓦片目录文件夹和png文件进行组成。
2) 地图瓦片数据库存储架构设计。安徽省第一次地理国情普查数据库管理系统采用Oracle数据库存储业务和地图数据。采用传统的文件方式存储瓦片的时候, 系统调用瓦片, 通过读取地图服务的瓦片配置文件, 访问以文件夹方式组织的瓦片数据; 基于MongoDB后, 综合Oracle数据库和MongoDB数据库的优势, 在瓦片数据存储上, 瓦片配置文件中的瓦片数据类型及参数设置等基本信息, 存在地理国情普查数据库管理系统Oracle数据库中相关的业务表中, 瓦片数据本身和相关的元数据信息以键值对的方式, 存储在MongoDB数据库中, 地图瓦片数据存储架构图如图 1所示。
![]() |
| 图 1 地图瓦片数据存储架构 Fig.1 Data Store Structure of Map Cache |
全省大批量的影像和矢量瓦片均可存储在MongoDB数据库中, 以提升对地图瓦片的访问和管理效率[4]。瓦片数据入库时, 依据瓦片的服务类型、瓦片级别建立瓦片数据集。例如, 地表覆盖地图服务的切片级别比较多、数据量比较大; 为了快速地将所有的瓦片入库, 可以将瓦片依据切片的比例尺级别进行分组, 多客户端地并行进行入库, 建立多个数据集, 在数据库管理系统中通过服务的动态整合, 逻辑上作为一个图层进行展示。地图服务更新时, 当遇到部分级别数据服务更新时, 可以针对相关级别的瓦片数据集进行更新, 提高了数据更新工作的效率。
3) 数据库设计。MongoDB瓦片数据库由瓦片元数据表和瓦片数据集表组成[5-14], 瓦片数据库概念模型图如图 2所示。元数据表存储瓦片格式、瓦片类型、瓦片坐标系等基本信息, 一条记录对应一组地图瓦片的配置文件; 瓦片数据集表存储地图瓦片本身, 一组地图瓦片对应一个瓦片数据集, 每个瓦片数据集单独存储。
![]() |
| 图 2 瓦片数据库概念模型 Fig.2 Concept Model of Cache Database |
综上所述, 瓦片元数据, 相当于地图配置文件(.xml)的集合; 瓦片数据集对应一组地图瓦片一次入库后建立的瓦片数据集, 多次入库产生多个数据集。
Oracle数据库中建立一张瓦片操作业务表, 记录每组地图瓦片的配置与入库、更新等操作信息, 与MongoDB瓦片数据库中的元数据表中的记录一一对应。当数据库管理系统需要调用某组地图瓦片数据时, 通过读取该表中的对应记录, 访问MongoDB瓦片数据库中对应的元数据记录, 得到瓦片数据集中的瓦片数据。
4) 地图瓦片数据的入库流程及实例。地图瓦片数据入库流程图如图 3所示, 地图瓦片数据录入人员以国情普查数据库管理系统使用者的身份登陆后, 首先新建MongoDB链接, 在Oracle业务库中建立MongoDB数据库链接记录, 在MongoDB建立地图瓦片元数据表; 然后输入本地瓦片数据的名称、坐标系、瓦片范围等参数, 在MongoDB数据库的瓦片元数据表中建立一条记录, 并同步创建一个以地图瓦片数据组名称命名的空的瓦片数据集、在Oracle瓦片操作业务表中建立一条包含该组地图瓦片的配置信息的空操作信息; 接着输入瓦片类型和起算级别信息, 利用瓦片入库工具, 对本地瓦片数据进行入库。当瓦片数据入库完成后, 每张地图瓦片以独立记录的方式存储于Mongo DB数据库的数据集表中, Oracle瓦片操作业务表中对应记录的瓦片类型、起算级别、操作类型等信息会进行同步更新。
![]() |
| 图 3 地图瓦片数据入库流程 Fig.3 Loading Process of Map Cache |
地理国情普查管理系统, 可以直接对入库后的MongoDB数据库中的地图瓦片进行浏览、查询等操作。地理国情普查管理系统访问MongoDB数据库中地图瓦片示例如图 4所示。
![]() |
| 图 4 管理系统访问MongoDB数据库中地图瓦片示例 Fig.4 Example of Manage System Access Map Cache from MongoDB Database |
3 性能指标对比测试
基于MongoDB数据库存储地图瓦片与传统的散列式存储有了较大改进, 虽然也是基于计算机文件系统的存储组织方式, 但是这种存储格式占用空间更少, 复制迁移更方便, 当常规地图瓦片存储单目录文件数大于2 000时, MongoDB地图瓦片存储的响应时间明显小于普通的散列式存储平均响应时间。为了对基于MongoDB的瓦片存储策略以及并发访问特性进行性能分析, 在项目实施前期我们在普通的局域网环境内(传输峰值不超过15 MB), 搭建了多个不同的场景, 开展了针对性的测试。
本文在单客户端单MongoDB数据库、单客户端MongoDB集群和多客户端MongoDB集群3种场景下, 基于2 000 820张地图瓦片累计数据量为238 GB, 基于单客户端单MongoDB数据库场景下数据查询总耗时仅为0.01 s, 表现了极佳的性能。入库测试的结果如表 1所示。
| 表 1 三种测试场景下数据入库结果对比表 Tab.1 Compare Result of LoadingData Within Three Test Scene |
![]() |
从表 1可以看出, 在多客户端并行及MongoDB集群的场景下, 瓦片数据的入库效率最高。
采用基于MongoDB的瓦片数据存储技术, 不仅扩展性良好, 而且在入库与查询上都有很好的性能表现。考虑到安徽省第一次地理国情普查数据库建成初期, 数据更新的频率不高, 入库操作不频繁, 数据库管理系统与MongoDB数据库交互的主要操作为查询, 故选择了单机单Mongodb数据库的模式进行建设, 后期根据实际需要, 再进行集群模式的扩展。
4 结束语本文针对安徽省地理国情普查数据库管理系统建设过程中, 遇到的加载数据量大或者图斑个数多的图层时, 显示速度慢的问题, 设计并实现了一套基于MongoDB数据库存储地图瓦片, 地理国情普查数据库管理系统同步管理库体成果的技术方案。
实践证明, 该方案解决了安徽省地理国情普查数据库管理系统加载某些“困难”图层慢的问题, 在遇到瓦片数据文件量急速增大的情况, 可以有效地避免数据存储和访问性能间瓶颈问题的产生。
为了进一步提升MongoDB地图瓦片数据库的性能, 今后将在以下方面作进一步的研究:
1) 优化MongoDB索引, 进一步提高系统性能;
2) 研究MongoDB自带的分布式文件系统(GridFS), 实现数据库对海量影像数据的高效管理;
3) 对MongoDB的聚合技术进行深入研究, 探索如何在集成的数据中进行数据分析。
| [1] |
张恩, 张广弟, 兰磊. 基于MongoDB的海量空间数据存储和并行[J]. 地理空间信息, 2014, 12(1): 46-48. |
| [2] |
霍多罗夫迪洛尔夫. MongoDB权威指南[M]. 北京: 人民邮电出版社, 2011.
|
| [3] |
国家测绘地理信息局. 地理信息公共服务平台电子地图数据规范: CH/Z 9011-2011[S]. 北京: 测绘出版社, 2011
|
| [4] |
王浩, 喻占武, 曾武, 等. 基于瓦片寿命和访问热度的海量空间数据缓存置换策略[J]. 武汉大学学报·信息科学版, 2009, 34(6): 667-668. |
| [5] |
陈超, 王亮, 闫浩文, 等. 一种基于NoSQL的地图瓦片数据存储技术[J]. 测绘学报, 2013, 42(1): 142-143. |
| [6] |
雷德龙, 郭殿升, 陈崇成, 等. 基于MongoDB的矢量空间数据云存储与处理系统[J]. 地球信息科学学报, 2014, 16(4): 507-516. |
| [7] |
仝义明, 黄蔚, 李戴维. 基于MongoDB的信息集成系统的设计与实现[J]. 信息技术, 2015(2): 125-129. |
| [8] |
李朝奎, 杨武, 殷智慧, 等. MongoDB的遥感影像分布式存储策略研究[J]. 测绘通报, 2014(5): 16-19. |
| [9] |
吴飞. 基于MongoDB的LBS数据管理系统关键技术研究[J]. 测绘通报, 2014(7): 121-124. |
| [10] |
马骏, 张飞龙. 基于MongoDB的遥感规格化数据云平台的设计与实现[J]. 计算机时代, 2016(2): 49-52. |
| [11] |
谢华成, 马学文. MongoDB数据库下文件型数据存储研究[J]. 软件, 2015, 36(11): 12-14. |
| [12] |
秦强, 王晏民, 黄明. 基于MongoDB的海量遥感影像大数据存储[J]. 北京建筑大学学报, 2015(1): 62-66. |
| [13] |
周怀许, 周俊晖, 侯祥意. 利用MongoDB的地籍时空数据库研究[J]. 测绘地理信息, 2013, 38(6): 73-75. |
| [14] |
邱新忠. 基于MongoDB GridFS的地图瓦片数据存储研究[J]. 地理空间信息, 2016, 14(2): 50-52. |
2018, Vol. 43






