刘坚　陈晓琳

摘 要：针对关系型数据库无法满足海量活断层探测文件入库效率要求与存储无法横向线性扩展的问题，基于MongoDB非关系型数据库的海量活断层探测文件存储入库方法，充分利用MongoDB内存文件映射方式，可动态增加节点以扩展性能、提高负载。以南水北调中线核心水源区活断层管理系统为例进行测试，与传统关系数据库存储入库文件方式进行性能对比试验分析，结果表明：该方法显著提高了海量活断层探测文件的存储入库与查询效率，能有效解决关系数据库存取非结构化数据时的性能瓶颈问题。

关键词：MongoDB；活断层；非关系型数据库；南水北调

DOI：10.11907/rjdk.171390

中图分类号：TP301 文献标识码：A 文章编号：1672-7800（2017）009-0004-03

Abstract：In a relational database can not meet the massive active fault detection and storage file storage efficiency requirements can not be horizontal linear expansion of the problem， try to use non relational database MongoDB massive active fault detection method based on file storage， which makes full use of MongoDB memory file mapping， dynamically add nodes to extend and improve the performance. Taking water source area core active fault management system as an example for testing， analysis， performance comparison test with the traditional relational database storage file results show that this method significantly improved the massive file active fault detection in storage and query efficiency， effectively solved the bottleneck problem of relational database access to unstructured data.

Key Words：MongoDB； active fault； non relational database； the south-to-north water diversion project

0 引言

活斷层突发性错动是引起地震灾害的主要原因，确定活断层滑动速度、位置等参数，建立相应数据库可帮助社会有效降低震害损失。美国地质调查局（USGS）公布了全美范围内第四纪活断层与褶皱汇编数据库；新西兰地质与核科学院（GNS）建成了新西兰活动断层数据库；1996年中国已初步建成了第1个活动构造数据库[1]，仅存储了活断层几何学与运动学基本信息，信息单一且不具备开放性。随着多种先进技术探测手段的运用，面对获取目标区域最全、最新、精细化海量探测文件数据，怎样保证数据高效分类入库及提供高性能查询服务，是建立开放性活断层探测信息管理系统的关键环节。

传统活断层探测信息系统采用关系型数据库（RDBMS）管理[2]。考虑到多种探测数据，特别是地形地貌等遥感数据的多时态、大数据量，且随时间推移数据量指数增长的特点，RDBMS难以支撑海量数据的存储扩展与高效查询时遇到的性能瓶颈问题。非关系型数据库（NoSQL）具有高效存储与访问、高并发读写、高可用性、高可扩展性等特点，能极大提高数据库读写性能与系统扩展能力，而MongoDB是NoSQL的典型代表。鉴于此，本文提出一种基于MongoDB的海量活断层探测文件存储入库方法。

1 MongoDB简介

MongoDB是一个基于分布式文件存储的数据库，由C++语言编写，旨在为应用提供可扩展的高性能数据存储解决方案[3]。数据分不同类型存储在同一个数据集中，成为一个集合，支持的数据结构非常松散，是类似JSON的BSON格式，因此可以存储比较复杂的数据类型。MongoDB最大的特点是支持的查询语言非常强大，其语法类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

它的特点是高性能、易使用、易部署，存储数据快捷方便。主要功能特性有：①面向集合存储易存储对象类型的数据；②模式自由；③支持动态查询；④支持完全索引，包含内部对象；⑤支持查询；⑥支持复制与故障恢复；⑦使用高效的二进制数据存储，包括大型对象（如视频等）；⑧自动处理碎片，以支持云计算层次的扩展性；⑨支持RUBY、PYTHON、JAVA、C++、PHP、C#等多种语言；⑩文件存储格式为BSON（一种JSON的扩展）；可通过网络访问。

2 基于MongoDB的存储原理

2.1 存储原理

以南水北调中线核心水源区活断层管理系统为例，活断层数据库包括的数据成果类型比较多，具体包括基础地理信息（GIS）、地球化学类探测数据成果、电磁探测数据成果、探地雷达探测数据成果、深层/浅层地震探测数据成果、地震危害性评估成果等专业库。

根据以上文件类型，按文件大小大致分为两类：第一类，对于小文件（小于等于16MB），MongoDB使用BSON对象进行文件存储，这类存储比较简单，不赘述；第二类，针对大于16MB的大文件是采用GridFS规范进行存储。其中将文件名作为键 （Key），具体内容数据作为值 （Value）[4]，GridFS规范是将大文件分割成许多小块文件进行存储，每块文件存储的信息包括两部分：第一部分存储自己以及相邻两小块文件的位置信息，第二部分存储具体数据信息，块与块之间用块序号连接[5]。文件分块后，信息被存于两个集合里，分别是Files（元数据对象）集合与chunks（相关信息的二进制格式）集合。两子集存储结构格式如下所示：endprint

Files={

_ID：ObjectId（“2016071500232”），

filename：”test.png”，∥文件名

length：1543，∥文件大小（单位字节）

ChunkSize：165，∥chunks大小

uploadDate：ISODate（“2016071508351234”），

md5：“XXX”

}

Chunks集合中的file_id与files集合中的_ID相同，chunks集合的文档格式如下：

chunks={

_ID：ObjectId（“201607234678”），

file_id：ObjectId（“2016071500232”）

n：NumberInt（2），//代表chunks序号，从0开始

data：BinaData（“…”）//数据

}

_ID默认情况下是MongoDB用时间戳、进程标识（PID）、机器名等组合关键字计算获得的ObjectID，它具有很高的唯一性与很强的辨识度[6]。

2.2 存储入库方法

各类探测数据不仅涉及文件的存储，还有相关各类属性（时间、大小、备注等）信息需要存储，且文件探测数据的类型不一样，所需存储的属性信息也不同。MongoDB文档型存储，基于GridFS的大文件型存储方式都有各自的不足：一方面，文档型存储方式虽然能存储探测数据的属性信息，但对于大于16 M的探测数据却无法有效存储；另一方面，基于GridFS的大文件存储方式能有效存储探测数据，但不能存储探测数据的各种属性信息。

因此，笔者设计了一种新的存储方法，将以上两种存储模式优势互补进行有效结合，以发挥更大的存储优势。首先，将探测数据以GridFS大文件存储方式写入保存至数据库中。其次，利用GridFS提供相应的接口自动或手动录入来获取探测数据的相关属性信息。第三，将该属性信息以一条文档信息形式，通过MongoDB传统的文档型存储模式插入数据库。此过程中最关键一步是将该探测数据_ID号作为一条记录存入文档信息中，并以此关联探测数据的_ID编号与文档的id编号，该方法实现了用一条文档中记录的探测数据_ID编号即可快速检索到与该文档记录信息对应的探测数据[7]。

3 存储方法实现

分两类实现：一类是大文件利用GridFS方式实现，另一类是属性数据通过BSON方式实现。第一类GridFS方式读写实现函数代码如下：

采用 C#语言开发的存储文件函数如下：

private void UpLoadFile（IMongoDatabase database， string sourceFilename）

{ //建立GridFS 存取对象

IGridFSBucket bucket = new GridFSBucket（database）；

//以流的方式上传文件

using （var stream = bucket.OpenUploadStream（sourceFilename））

{ var id = stream.Id；

stream.Close（）；

}

}

读取文件的函数如下：

private void DownloadFile（IMongoDB database，string sourceFilename，string targetFilename）

{ //建立GridFS 存取对象

IGridFSBucket bucket = new GridFSBucket（database）；

//建立下载文件目的地

FileStream destination = new FileStream（targetFilename， FileMode.Create）；

//以流的方式下载文件

bucket.DownloadToStreamByName（sourceFilename， destination）；

using （var stream = bucket.OpenDownloadStreamByName（sourceFilename））

{stream.Close（）；}

}

对于属性数据，具体存储的部分实现代码如下：

BsonDocument T = new BsonDocument{

{“編号”，_id}，

{“名字”，name}，

……

}；

Col.Insert（T）

4 应用分析

4.1 测试环境与实例

为测试检验MongoDB数据库存取海量探测文件与属性信息的性能，在测试代码的关键处设置秒表起止时间点，以统计所耗时间。将MongoDB数据库与Mysql数据库在读写性能方面进行比较，目前Mysql支持几乎所有数据类型，且在开源关系型数据库管理系统中被认为功能是较强大的。

采用的测试平台为：Intel Core i7处理器、8G内存、2TB硬盘、Windows10 64位操作系统、C#编程语言、MongoDB版本为3.0、Mysql版本为5.1.48。测试平台软、硬件环境如表1所示。

该测试分两类，分别测试大文件插入数据库性能及从数据库中查询数据效率。以南水北调中线核心水源区的探测文件批量入库为例，如图1所示，进行测试分析。endprint

4.2 存储性能对比

分别对MongoDB3.0与Mysql-5.1.48做30、70、150、300、800、10 000次文件写入试验，文件大小约为30MB/个，两者的二进制文件存储耗时（单位：ms）性能对比结果如图2所示。Mysql所耗时间随文件个数增多而剧增，而MongoDB耗时变化不大，可以看出，当存储写入数据库文件数量越来越多时，MongoDB的性能优势越来越明显。

4.3 查询性能对比

分别对MongoDB3.0与Mysql-5.1.48做数据量MB为50、100、200、300、500的查询性能测试，从图3可以看出，MongoDB耗时（单位：ms）比较小，而Mysql查询耗时随数据量增长变化幅度陡然增大。

5 结论

本文提出一种基于MongoDB的海量活断层探测文件存储入库方法，并与传统关系型数据库Mysql在存取效率上进行性能比对分析测试，结果表明：该方法在数据存储与查询等性能方面具有显著优势，特别是数据量大时更加明显。为更进一步深入研究，体现该方法在海量文件数据入库存储的优势，同时为更高层次的应用提供有益参考，未来将继续开展与其它典型关系数据库对比测试工作。

参考文献：

[1] 于贵华，邓起东，邬伦.利用GIS系统建立中国活动断裂信息咨询分析系统[J].地震地质，1996，18（2）：156-160.

[2] 于贵华，徐锡伟，孙怡，等.城市活断层探测信息系统的设计与实现——以福州市活断层信息管理系统为例[J].地震地质，2006，28（4）：655-662.

[3] ELOISE GIEGERICH. MongoDB certified professional spotlight： may mascenik[EB/OL].http：// blog.mongodb.org.

[4] 霍多罗夫，迪洛尔夫.MongoDB权威指南[M].北京：人民邮电出版社，2011.

[5] 张艳霞，丰继林，郝伟，等.基于NoSQL的文件型大数据存储技术研究[J].制造业自动化，2014，36（3）：27-30.

[6] SATTAR ABDUL， LORENZEN， TORBEN， NALLAMADDI， et al. Incorporating NoSQL into a database course[J].ACM Inroads，2013，4（2）：50-53.

[7] 劉坚，李盛乐，戴苗，等.基于Hbase的地震大数据存储研究[J].大地测量与地球动力学，2015，35（5）：890-893.

（责任编辑：何 丽）endprint