基于MongoDB的海量活斷層探測文件存儲入庫方法

劉堅　陳曉琳

摘 要：針對關系型數據庫無法滿足海量活斷層探測文件入庫效率要求與存儲無法橫向線性擴展的問題，基于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，∥文件大?。▎挝蛔止潱?/p>

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