劉堅　陳曉琳

摘 要：針對關(guān)系型數(shù)據(jù)庫無法滿足海量活斷層探測文件入庫效率要求與存儲無法橫向線性擴展的問題，基于MongoDB非關(guān)系型數(shù)據(jù)庫的海量活斷層探測文件存儲入庫方法，充分利用MongoDB內(nèi)存文件映射方式，可動態(tài)增加節(jié)點以擴展性能、提高負(fù)載。以南水北調(diào)中線核心水源區(qū)活斷層管理系統(tǒng)為例進行測試，與傳統(tǒng)關(guān)系數(shù)據(jù)庫存儲入庫文件方式進行性能對比試驗分析，結(jié)果表明：該方法顯著提高了海量活斷層探測文件的存儲入庫與查詢效率，能有效解決關(guān)系數(shù)據(jù)庫存取非結(jié)構(gòu)化數(shù)據(jù)時的性能瓶頸問題。

關(guān)鍵詞：MongoDB；活斷層；非關(guān)系型數(shù)據(jù)庫；南水北調(diào)

DOI：10.11907/rjdk.171390

中圖分類號：TP301 文獻標(biāo)識碼：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 引言

活斷層突發(fā)性錯動是引起地震災(zāi)害的主要原因，確定活斷層滑動速度、位置等參數(shù)，建立相應(yīng)數(shù)據(jù)庫可幫助社會有效降低震害損失。美國地質(zhì)調(diào)查局（USGS）公布了全美范圍內(nèi)第四紀(jì)活斷層與褶皺匯編數(shù)據(jù)庫；新西蘭地質(zhì)與核科學(xué)院（GNS）建成了新西蘭活動斷層數(shù)據(jù)庫；1996年中國已初步建成了第1個活動構(gòu)造數(shù)據(jù)庫[1]，僅存儲了活斷層幾何學(xué)與運動學(xué)基本信息，信息單一且不具備開放性。隨著多種先進技術(shù)探測手段的運用，面對獲取目標(biāo)區(qū)域最全、最新、精細(xì)化海量探測文件數(shù)據(jù)，怎樣保證數(shù)據(jù)高效分類入庫及提供高性能查詢服務(wù)，是建立開放性活斷層探測信息管理系統(tǒng)的關(guān)鍵環(huán)節(jié)。

傳統(tǒng)活斷層探測信息系統(tǒng)采用關(guān)系型數(shù)據(jù)庫（RDBMS）管理[2]?？紤]到多種探測數(shù)據(jù)，特別是地形地貌等遙感數(shù)據(jù)的多時態(tài)、大數(shù)據(jù)量，且隨時間推移數(shù)據(jù)量指數(shù)增長的特點，RDBMS難以支撐海量數(shù)據(jù)的存儲擴展與高效查詢時遇到的性能瓶頸問題。非關(guān)系型數(shù)據(jù)庫（NoSQL）具有高效存儲與訪問、高并發(fā)讀寫、高可用性、高可擴展性等特點，能極大提高數(shù)據(jù)庫讀寫性能與系統(tǒng)擴展能力，而MongoDB是NoSQL的典型代表。鑒于此，本文提出一種基于MongoDB的海量活斷層探測文件存儲入庫方法。

1 MongoDB簡介

MongoDB是一個基于分布式文件存儲的數(shù)據(jù)庫，由C++語言編寫，旨在為應(yīng)用提供可擴展的高性能數(shù)據(jù)存儲解決方案[3]。數(shù)據(jù)分不同類型存儲在同一個數(shù)據(jù)集中，成為一個集合，支持的數(shù)據(jù)結(jié)構(gòu)非常松散，是類似JSON的BSON格式，因此可以存儲比較復(fù)雜的數(shù)據(jù)類型。MongoDB最大的特點是支持的查詢語言非常強大，其語法類似于面向?qū)ο蟮牟樵冋Z言，幾乎可以實現(xiàn)類似關(guān)系數(shù)據(jù)庫單表查詢的絕大部分功能，而且還支持對數(shù)據(jù)建立索引。

它的特點是高性能、易使用、易部署，存儲數(shù)據(jù)快捷方便。主要功能特性有：①面向集合存儲易存儲對象類型的數(shù)據(jù)；②模式自由；③支持動態(tài)查詢；④支持完全索引，包含內(nèi)部對象；⑤支持查詢；⑥支持復(fù)制與故障恢復(fù)；⑦使用高效的二進制數(shù)據(jù)存儲，包括大型對象（如視頻等）；⑧自動處理碎片，以支持云計算層次的擴展性；⑨支持RUBY、PYTHON、JAVA、C++、PHP、C#等多種語言；⑩文件存儲格式為BSON（一種JSON的擴展）；可通過網(wǎng)絡(luò)訪問。

2 基于MongoDB的存儲原理

2.1 存儲原理

以南水北調(diào)中線核心水源區(qū)活斷層管理系統(tǒng)為例，活斷層數(shù)據(jù)庫包括的數(shù)據(jù)成果類型比較多，具體包括基礎(chǔ)地理信息（GIS）、地球化學(xué)類探測數(shù)據(jù)成果、電磁探測數(shù)據(jù)成果、探地雷達探測數(shù)據(jù)成果、深層/淺層地震探測數(shù)據(jù)成果、地震危害性評估成果等專業(yè)庫。

根據(jù)以上文件類型，按文件大小大致分為兩類：第一類，對于小文件（小于等于16MB），MongoDB使用BSON對象進行文件存儲，這類存儲比較簡單，不贅述；第二類，針對大于16MB的大文件是采用GridFS規(guī)范進行存儲。其中將文件名作為鍵 （Key），具體內(nèi)容數(shù)據(jù)作為值 （Value）[4]，GridFS規(guī)范是將大文件分割成許多小塊文件進行存儲，每塊文件存儲的信息包括兩部分：第一部分存儲自己以及相鄰兩小塊文件的位置信息，第二部分存儲具體數(shù)據(jù)信息，塊與塊之間用塊序號連接[5]。文件分塊后，信息被存于兩個集合里，分別是Files（元數(shù)據(jù)對象）集合與chunks（相關(guān)信息的二進制格式）集合。兩子集存儲結(jié)構(gòu)格式如下所示：endprint

Files={

_ID：ObjectId（“2016071500232”），

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

length：1543，∥文件大小（單位字節(jié)）

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（“…”）//數(shù)據(jù)

}

_ID默認(rèn)情況下是MongoDB用時間戳、進程標(biāo)識（PID）、機器名等組合關(guān)鍵字計算獲得的ObjectID，它具有很高的唯一性與很強的辨識度[6]。

2.2 存儲入庫方法

各類探測數(shù)據(jù)不僅涉及文件的存儲，還有相關(guān)各類屬性（時間、大小、備注等）信息需要存儲，且文件探測數(shù)據(jù)的類型不一樣，所需存儲的屬性信息也不同。MongoDB文檔型存儲，基于GridFS的大文件型存儲方式都有各自的不足：一方面，文檔型存儲方式雖然能存儲探測數(shù)據(jù)的屬性信息，但對于大于16 M的探測數(shù)據(jù)卻無法有效存儲；另一方面，基于GridFS的大文件存儲方式能有效存儲探測數(shù)據(jù)，但不能存儲探測數(shù)據(jù)的各種屬性信息。

因此，筆者設(shè)計了一種新的存儲方法，將以上兩種存儲模式優(yōu)勢互補進行有效結(jié)合，以發(fā)揮更大的存儲優(yōu)勢。首先，將探測數(shù)據(jù)以GridFS大文件存儲方式寫入保存至數(shù)據(jù)庫中。其次，利用GridFS提供相應(yīng)的接口自動或手動錄入來獲取探測數(shù)據(jù)的相關(guān)屬性信息。第三，將該屬性信息以一條文檔信息形式，通過MongoDB傳統(tǒng)的文檔型存儲模式插入數(shù)據(jù)庫。此過程中最關(guān)鍵一步是將該探測數(shù)據(jù)_ID號作為一條記錄存入文檔信息中，并以此關(guān)聯(lián)探測數(shù)據(jù)的_ID編號與文檔的id編號，該方法實現(xiàn)了用一條文檔中記錄的探測數(shù)據(jù)_ID編號即可快速檢索到與該文檔記錄信息對應(yīng)的探測數(shù)據(jù)[7]。

3 存儲方法實現(xiàn)

分兩類實現(xiàn)：一類是大文件利用GridFS方式實現(xiàn)，另一類是屬性數(shù)據(jù)通過BSON方式實現(xiàn)。第一類GridFS方式讀寫實現(xiàn)函數(shù)代碼如下：

采用 C#語言開發(fā)的存儲文件函數(shù)如下：

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（）；

}

}

讀取文件的函數(shù)如下：

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（）；}

}

對于屬性數(shù)據(jù)，具體存儲的部分實現(xiàn)代碼如下：

BsonDocument T = new BsonDocument{

{“編號”，_id}，

{“名字”，name}，

……

}；

Col.Insert（T）

4 應(yīng)用分析

4.1 測試環(huán)境與實例

為測試檢驗MongoDB數(shù)據(jù)庫存取海量探測文件與屬性信息的性能，在測試代碼的關(guān)鍵處設(shè)置秒表起止時間點，以統(tǒng)計所耗時間。將MongoDB數(shù)據(jù)庫與Mysql數(shù)據(jù)庫在讀寫性能方面進行比較，目前Mysql支持幾乎所有數(shù)據(jù)類型，且在開源關(guān)系型數(shù)據(jù)庫管理系統(tǒng)中被認(rèn)為功能是較強大的。

采用的測試平臺為：Intel Core i7處理器、8G內(nèi)存、2TB硬盤、Windows10 64位操作系統(tǒng)、C#編程語言、MongoDB版本為3.0、Mysql版本為5.1.48。測試平臺軟、硬件環(huán)境如表1所示。

該測試分兩類，分別測試大文件插入數(shù)據(jù)庫性能及從數(shù)據(jù)庫中查詢數(shù)據(jù)效率。以南水北調(diào)中線核心水源區(qū)的探測文件批量入庫為例，如圖1所示，進行測試分析。endprint

4.2 存儲性能對比

分別對MongoDB3.0與Mysql-5.1.48做30、70、150、300、800、10 000次文件寫入試驗，文件大小約為30MB/個，兩者的二進制文件存儲耗時（單位：ms）性能對比結(jié)果如圖2所示。Mysql所耗時間隨文件個數(shù)增多而劇增，而MongoDB耗時變化不大，可以看出，當(dāng)存儲寫入數(shù)據(jù)庫文件數(shù)量越來越多時，MongoDB的性能優(yōu)勢越來越明顯。

4.3 查詢性能對比

分別對MongoDB3.0與Mysql-5.1.48做數(shù)據(jù)量MB為50、100、200、300、500的查詢性能測試，從圖3可以看出，MongoDB耗時（單位：ms）比較小，而Mysql查詢耗時隨數(shù)據(jù)量增長變化幅度陡然增大。

5 結(jié)論

本文提出一種基于MongoDB的海量活斷層探測文件存儲入庫方法，并與傳統(tǒng)關(guān)系型數(shù)據(jù)庫Mysql在存取效率上進行性能比對分析測試，結(jié)果表明：該方法在數(shù)據(jù)存儲與查詢等性能方面具有顯著優(yōu)勢，特別是數(shù)據(jù)量大時更加明顯。為更進一步深入研究，體現(xiàn)該方法在海量文件數(shù)據(jù)入庫存儲的優(yōu)勢，同時為更高層次的應(yīng)用提供有益參考，未來將繼續(xù)開展與其它典型關(guān)系數(shù)據(jù)庫對比測試工作。

參考文獻：

[1] 于貴華，鄧起東，鄔倫.利用GIS系統(tǒng)建立中國活動斷裂信息咨詢分析系統(tǒng)[J].地震地質(zhì)，1996，18（2）：156-160.

[2] 于貴華，徐錫偉，孫怡，等.城市活斷層探測信息系統(tǒng)的設(shè)計與實現(xiàn)——以福州市活斷層信息管理系統(tǒng)為例[J].地震地質(zhì)，2006，28（4）：655-662.

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

[4] 霍多羅夫，迪洛爾夫.MongoDB權(quán)威指南[M].北京：人民郵電出版社，2011.

[5] 張艷霞，豐繼林，郝偉，等.基于NoSQL的文件型大數(shù)據(jù)存儲技術(shù)研究[J].制造業(yè)自動化，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的地震大數(shù)據(jù)存儲研究[J].大地測量與地球動力學(xué)，2015，35（5）：890-893.

（責(zé)任編輯：何 麗）endprint