基于MongoDB集群的遥感数据存储方法的研究

2018-05-22李宏志李苋兰

四川轻化工大学学报(自然科学版) 2018年2期

李宏志，李苋兰

（1.滁州学院信息学院，安徽滁州 239000；2.福建师范大学光电与信息工程学院，福州 350000）

引言

高精度的遥感数据作为一种大容量的信息载体，在国土勘测和军事安全方面有着重要的作用。随着我国的航天遥感技术的发展，遥感数据的数量和质量都在逐步的提高，单个的遥感文件可达到数百MB，甚至达到数GB的大小，如何高效且安全地存储和管理这些遥感数据已成为当前空间信息科学领域的重要研究方向。

由于MongoDB集群在存储和管理遥感数据方面具有一定的优势［1-3］，使得基于MongoDB集群在遥感数据存储方面的研究成为热点。文献［4－6］详细介绍了使用MongoDBGridFS分布式文件系统存储和管理影像图片文件的方法；田帅［7］提出了一种基于 MongoDB和HDFS的大规模遥感数据存储方案，该方案将遥感元数据和遥感影像文件分开存储和管理，由MongoDB存储非结构化的元数据，HDFS分布式文件系统负责存储大规模的影像文件。这种存储方案需要维护元数据和影像文件的对应关系，同时涉及到的技术较复杂，不便于维护；赖积保等［8］提出了基于云计算的遥感影像存储模型RSC－DOM，该模型采用改进的遥感数据直接存储方式，实现了对遥感数据的分布式管理，但应用场景要求数据是均匀分布的，因此具有一定的局限性；秦强等［9］提出了基于MongoDB的遥感数据存储方案，通过NoSQL技术实现了非结构化的遥感元数据的存储；梁海等［10］提出了通过MongoDB的分片技术提高数据库的读写性能和效率。本文在上述研究成果基础上提出了基于高速缓存和MongoDB数据库的存储模型，底层存储模块采用MongoDB及其分布式文件系统GridFS。在底层存储之上新建一层基于内存型存储器的缓存层用于快速存储遥感元数据，结合一致性哈希算法，提高遥感数据在分布式集群中分布的均匀性，减少各存储节点之间的数据迁移次数，提高系统的访问效率。

1 MongoDB的存储架构简介

1.1 MongoDB的数据存储机制

MongoDB存储的内容是结构松散的类似于JSON结构的BSON格式数据，支持MapReduce功能，以保证其可以对数据进行复杂的关系和分析；除此之外，MongoDB支持对于地理信息的索引及检索操作。

GridFS是构建于MongoDB之上的分布式文件系统，利用MongoDB的分布式存储机制实现遥感影像文件的存储；GridFS默认使用 fs.files和 fs.chunks集合来存储文件的元数据和文件块。MongoDBGridFS支持对存储的大文件自动分片，分布式文件存储架构如图1所示。

图1 GridFS的文件存储分片架构

MongoDB的存储架构主要由三个部分组成：分片存储服务器、集群路由服务器以及配置服务器。其中存储服务器负责集群数据和文件的存储，路由服务器负责请求的寻址和定位，而配置服务器保存集群服务器所有的配置信息。

MongoDB采用数据块的概念作为基本的存储单元，当单个数据块的大小达到某个阈值之后，系统会进行数据块分裂，各分片服务器通过数据块存储应用数据，当系统中各分片中的存储块的数量出现失衡时，会启动再平衡算法，在各分片之间进行数据迁移，具体过程如图2所示。

图2 MongoDB数据存储机制

1.2 MongoDB数据分片的片键选择

MongoDB分片机制能够根据文件的大小将数据划分到不同的分片服务器上，数据分片一般应在数据库建立早期进行，避免由于分片操作造成过多的系统开销。要进行数据分片必须要选择集合中一个或多个索引作为数据分片的基准，称之为片键。片键的选择关乎到集群的性能。MongoDB根据片键进行数据分块主要包括以下几个步骤：

（1）开启集合的数据分片。

（2）创建集合字段索引。

（3）选定索引字段作为片键。

（4）系统会依据集合选定的片键对文档数据进行分块，使文档数据按照片键分布在不同的数据块中。

（5）各分片按照数据块（chunk）的数量调整分片之间的数据分布。

2 基于高速缓存和MongoDB的遥感影像文件的存储系统

MongoDB数据库能够兼容多种数据格式的遥感元数据，对于遥感影像文件的管理也较为方便，遥感数据满足如下模型：

其中，Object Data指的是遥感元数据及其对象，Object Image表示遥感影像数据，Object Vector代表矢量数据对象。

通常对于遥感数据的访问和操作主要集中于遥感元数据，因此可以使用内存型缓存来加速这部分数据的访问过程。本文研究的遥感元数据见表1。

表1 遥感元数据示例

根据对MongoDB分片机制的研究可知，当数据量过大时，各数据分片之间存在数据迁移操作，这会使系统开销较大，影响系统的稳定性。因此可以通过一致性哈希算法建立应用数据与分片节点之间的映射关系，减少系统级的数据平衡操作的执行次数。

2.1 存储系统的架构设计

在设计存储系统时，除了考虑遥感数据的存储和管理之外，还需要保证与其他系统平台兼容，要求系统具备接受和处理来自其他平台的数据并且能够为其他的应用平台提供数据服务的能力。为了保证整个平台的可靠性和扩展性，系统采用层次化设计，可分为交互层、服务层、数据缓存层和数据存储层，系统分层结构如图3所示。

图3 基于MongoDB的存储系统的多层架构模

（1）交互层位于整个系统的最前端，负责与其他系统或用户进行交互。交互层提供了PULL和PUSH的两种集成方式，支持多种传输协议和数据格式，一方面用户可以通过PUSH方式定义的通用接口向系统提交遥感数据，另一方面用户可以通过PULL方式获取系统中的遥感数据，便于与其他系统集成。同时，交互层负责为客户端提供遥感元数据的格式规范，影像文件以及高程文件的上传接口。

（2）服务层为整个系统架构的核心层，主要包括消息队列模块、任务调度模块、数据库操作服务以及元数据解析模块。系统消息队列负责接收用户的上传的数据，由服务程序实现队列数据的存储，这样能够减少数据库系统的瞬时压力，以提高系统的并发能力。任务调度模块负责调度和管理系统中的各种任务进程的执行，任务调度模块包含了任务执行队列、调度器以及触发器等核心模块［11］。任务调度模块与消息队列配合共同完成请求的分发和系统的负载均衡。

（3）缓存层用于缓存遥感元数据，使用内存型缓存，如Memcache、Redis缓存服务器；通过高速缓存使常用数据常驻内存，提高数据的访问效率。通过缓存层访问遥感数据的基本步骤：

S1：查询根据给定的键值查询缓存层是否包含数据。

S2：如果包含了所要的数据，直接从缓存层返回数据或影像文件信息。

S3：如果未命中缓存信息，则进入数据存储层的对应数据库获取数据信息。

S4：系统将获取的信息返回给上层客户端，并回写至缓存中。

（4）数据存储层用于整个系统的数据存储和备份，采用MongoDB及GridFS集群实现。其中MongoDB负责存储和管理遥感元数据，GridFS集群负责存储和管理遥感影像文件。

架构模型通过引入哈希一致性算法，建立数据与分片节点之间的映射关系，均衡各分片之间的数据数量，减少分片之间的数据迁移次数。

使用哈希一致性算法分配存储节点的过程如下：

初始化分片节点的ip地址序列－＞shards＿queue；

while（shards＿queue）｛

node＿ip＝shards＿queue.pop（）；

node＿key＝node＿id mod（232）；／／计算对应节点的key

node＿map.push（＜node＿ip，node＿key＞）；

｝

data＿key＝hash（data.item）；／／计算待存数据散列值

select＿ip＝selectNode（data＿key，node＿map）；／／选择存储的分片IP节点

return select＿ip；

2.2 遥感元数据模型的设计

高效的数据模型能够很好满足应用程序的需求，设计文档数据结构的关键在于考虑是使用嵌入式数据模型还是使用规范化的数据模型。如图4所示，Location和TerrainInfo属性字段作为子文档嵌入到父级文档中，这种嵌入式结构是指与给定文档相关联的文档以子文档的形式存放于给定文档内部；规范化数据模型指各文档之间通过使用、引用来表达对象之间的关系，如图5所示，该结构类似于关系型数据库的外键关联方式［12］。

图4 嵌入式数据模型

图5 规范化数据模型

存储模型的设计需要权衡存储空间的利用率和系统的查询性能。遥感元数据包含一对多、多对多的实体关系，考虑到遥感元数据的特点，属于读占优类型的数据，数据一旦写入，修改可能性较小，因此选择内嵌式数据模型。另外选择内嵌式数据模型便于对遥感数据进行大规模的聚合和分析操作，提高系统对遥感数据的分析性能。

2.3 遥感元数据MongoDB存储片键选择

集合片键决定了数据在集群分片中的分布情况，影响系统的存储性能，因此片键的选择对于存储系统的设计至关重要。良好设计的片键应具备升序片键和随机片键的优点。既要具备良好的数据局部性，也不至于由于数据分布过于局部出现数据热点造成系统的读写瓶颈，要达到这种效果可以采用复合片键［13］。本文在分析遥感元数据的基础上，提出了“升序键＋搜索键”的片键设计方案。

升序键一般选择文档中的自增＿id或时间戳，在遥感数据文档中符合升序片键的字段有自增＿id和文档记录时间ObserveTime。字段＿id的自增特性会导致某个节点成为数据热点造成数据过于集中，观测时间字段ObserveTime既具有升序的特点又不至于使分片数据过于集中［14］；而应用程序对数据的访问主要是集中在系统新数据的访问，按照文档时间进行数据分片能够使新数据尽可能的保存于内存中，提高数据的访问效率［15］。

搜索键的选择是根据应用需求设计的，为了保证查询数据的隔离，搜索键采用常用的搜索字段［16］。对于本文中的遥感数据而言，较为频繁使用的查询字段是经纬度，因此选择经纬度作为分片搜索键能够让经纬度较近的数据分布集中，减少在查询时访问分片的次数。

本文选择“记录时间＋经度＋纬度”作为复合片键，记录时间片键能够使文档数据均匀分布在各分片上。选择经纬度作为搜索片键能够提高系统的查询性能和聚合分析能力，如图6所示。

图6 基于分片标签的复合片键选择策略

3 性能测试与分析

为验证本文提出的基于MongoDB的多层分布式存储系统的性能，基于上文提出的数据格式和文件类型进行一系列测试实验。首先针对不同片键选择策略下的数据分布和查询性能的测试；然后验证在引入内存型缓存的情况下，对系统查询性能的提升。

3.1 数据模拟

根据上文提出的遥感元数据模型，基于既有遥感数据信息库模拟出20万条遥感数据记录，占用存储空间约2.3 GB。模拟数据的选取范围：

（1）数据的观测时间从2017年1月到2017年8月份。

（2）遥感数据的观测方式从“ht－yc－fengyun－01”和“ht－yc－fengyun－02”中随机选取。

（3）观测经度数据在［115.6，119］区间内产生随机数，纬度数据在［28.2，35.7］区间内产生随机数。

对于选取的遥感数据模型中的其他字段，采用模拟填充方式生成字段内容。

3.2 测试环境搭建

测试环境采用八台微型计算机搭建成分布式的存储平台，存储节点基本配置：内存1 GB，硬盘大小120 GB，CPU Intel／英特尔 i5 7500，操作系统 CentOS 6.3。其中6个节点作为数据存储的分片节点，选取1个节点作为运行配置服务器，1个节点作为路由服务器。测试环境的网络拓扑结构如图7所示。

图7 测试环境拓扑结构图

3.3 数据分片性能测试

本节针对2.3节提出的｛记录时间，经度，纬度｝复合片键方案，通过模拟数据验证该方案对数据分布的均衡性和查询性能的提升。测试数据采用上文中提到的20万条模拟数据，通过对比多组片键组合方案，验证该复合片键方案的性能优势。片键策略的实验分组见表2。

表2 片键策略的实验分组

将模拟生成的20万条数据按照表2的片键策略存入图5所示的存储平台中，文档分布结果见表3。

表3 文档数量分布测试结果

对于表3中得到的测试数据，采用统计学中的标准差衡量数据分布是否均衡，计算结果见表4。

通过表4的标准差统计数据，｛ObserveTime，Longitude，Latitude｝片键方案文档数据在集群中分布的比较均衡，说明｛ObserveTime，Longitude，Latitude｝片键选择方案能够优化数据在集群中的分布。

表4 文档数量分布标准差

图8为基于测试数据的查询性能统计情况，从中可以看出，总体上复合片键的查询性能优于单片方案，对于复合片键值｛ItemId，ItemName｝的查询性能较差的原因，主要是由于该方案下数据分布的均衡性较差。复合片键｛Longitude，Latitude｝和｛ObserveTime，Longitude，Latitude｝的查询性能明显好于其他方案；其中｛ObserveTime，Longitude，Latitude｝方案不仅平均查询时间较短，且查询性能的稳定性表现较好，后期数据量增大后性能波动较小，能较快实现收敛。

3.4 缓存模块对查询性能的影响

设置两组对比实验：一组是不使用缓存的分布式架构设计（架构一），另一种是在原来2.1节提出的增加了内存型缓存的分布式存储架构（架构二），通过计算文档记录平均查询时间来衡量两种架构不同的性能表现，见表5。

图8 查询性能统计分析结果图

表5 两种不同架构模型的平均文档查询时间

图9为两种架构模型的文档查询的平均耗时对比图。由图9可知，在数据量较少时，两种架构模型的平均查询耗时差距不大，随着数据量的增大，架构二（缓存模型）的性能优势逐渐凸显出来，平均查询时间明显低于架构一，且平均查询耗时也趋于稳定；因此可以看出缓存模型能够较好地改善遥感数据的查询性能。

图9 两种架构模型的平均耗时对比

4 结束语

本文基于非关系型数据库MongoDB，提出了一种海量遥感数据的分布式存储方案，通过引入内存型缓存提高遥感数据的查询和存储效率，使用一种针对遥感数据特点的分片数据方案；并通过实验验证了该存储方案对海量遥感数据的存储具有一定的优越性。该方案具有一般性意义，能够运用到其他场景中；下一步工作将进一步对这种存储方案进行优化，以提高其整体性能。

参考文献：

[1]孙敬杰,曾李阳,张尧.基于MongoDB的Web空间数据存储与管理研究[J].测绘,2017,40(2):72-74,89.

[2]祁兰.基于MongoDB的数据存储与查询优化技术研究[D].南京:南京邮电大学,2016.

[3]高锐.基于MongoDB的黑河流域时空数据云存储关键技术研究[D].兰州:兰州大学,2016.

[4]徐旭东,郭瑞,文瑞洁.分布式下MongoDB对激光点云的存储和处理研究[J].计算机应用与软件,2017,34(2):71-73,168.

[5]潘永华,闭应洲,符云琴.基于MongoDB的医学图像管理技术研究[J].广西师范学院学报:自然科学版,2017,34(2):54-59.

[6]王震,余洋,张志强,等.基于MongoDB的遥感影像存取方案的探讨与实现[J].测绘地理信息,2017,42(3):39-43.

[7]田帅.一种基于MongoDB和HDFS的大规模遥感数据存储系统的设计与实现[D].杭州:浙江大学,2013.

[8]赖积保,罗晓丽,余涛,等.一种支持云计算的遥感影像数据组织模型研究[J].计算机科学,2013,40(7):80-83,115.

[9]秦强,王晏民,黄明.基于MongoDB的海量遥感影像大数据存储[J].北京建筑大学学报,2015,31(1):62-66.

[10]梁海.MongoDB数据库中Sharding技术应用研究[J].计算机技术与发展,2014,24(7):60-62,67.

[11]冯东煜,朱立谷,肖子达,等.一种MongoDB集群数据布局优化方法研究[J].计算机工程与应用,2017,53(17):77-84.