李宏志，李莧蘭

（1.滁州學院信息學院，安徽 滁州 239000；2.福建師范大學光電與信息工程學院，福州 350000）

引言

高精度的遙感數(shù)據(jù)作為一種大容量的信息載體，在國土勘測和軍事安全方面有著重要的作用。隨著我國的航天遙感技術(shù)的發(fā)展，遙感數(shù)據(jù)的數(shù)量和質(zhì)量都在逐步的提高，單個的遙感文件可達到數(shù)百MB，甚至達到數(shù)GB的大小，如何高效且安全地存儲和管理這些遙感數(shù)據(jù)已成為當前空間信息科學領域的重要研究方向。

由于MongoDB集群在存儲和管理遙感數(shù)據(jù)方面具有一定的優(yōu)勢［1-3］，使得基于MongoDB集群在遙感數(shù)據(jù)存儲方面的研究成為熱點。文獻［4－6］詳細介紹了使用MongoDBGridFS分布式文件系統(tǒng)存儲和管理影像圖片文件的方法；田帥［7］提出了一種基于 MongoDB和HDFS的大規(guī)模遙感數(shù)據(jù)存儲方案，該方案將遙感元數(shù)據(jù)和遙感影像文件分開存儲和管理，由MongoDB存儲非結(jié)構(gòu)化的元數(shù)據(jù)，HDFS分布式文件系統(tǒng)負責存儲大規(guī)模的影像文件。這種存儲方案需要維護元數(shù)據(jù)和影像文件的對應關(guān)系，同時涉及到的技術(shù)較復雜，不便于維護；賴積保等［8］提出了基于云計算的遙感影像存儲模型RSC－DOM，該模型采用改進的遙感數(shù)據(jù)直接存儲方式，實現(xiàn)了對遙感數(shù)據(jù)的分布式管理，但應用場景要求數(shù)據(jù)是均勻分布的，因此具有一定的局限性；秦強等［9］提出了基于MongoDB的遙感數(shù)據(jù)存儲方案，通過NoSQL技術(shù)實現(xiàn)了非結(jié)構(gòu)化的遙感元數(shù)據(jù)的存儲；梁海等［10］提出了通過MongoDB的分片技術(shù)提高數(shù)據(jù)庫的讀寫性能和效率。本文在上述研究成果基礎上提出了基于高速緩存和MongoDB數(shù)據(jù)庫的存儲模型，底層存儲模塊采用MongoDB及其分布式文件系統(tǒng)GridFS。在底層存儲之上新建一層基于內(nèi)存型存儲器的緩存層用于快速存儲遙感元數(shù)據(jù)，結(jié)合一致性哈希算法，提高遙感數(shù)據(jù)在分布式集群中分布的均勻性，減少各存儲節(jié)點之間的數(shù)據(jù)遷移次數(shù)，提高系統(tǒng)的訪問效率。

1 MongoDB的存儲架構(gòu)簡介

1.1 MongoDB的數(shù)據(jù)存儲機制

MongoDB存儲的內(nèi)容是結(jié)構(gòu)松散的類似于JSON結(jié)構(gòu)的BSON格式數(shù)據(jù)，支持MapReduce功能，以保證其可以對數(shù)據(jù)進行復雜的關(guān)系和分析；除此之外，MongoDB支持對于地理信息的索引及檢索操作。

GridFS是構(gòu)建于MongoDB之上的分布式文件系統(tǒng)，利用MongoDB的分布式存儲機制實現(xiàn)遙感影像文件的存儲；GridFS默認使用 fs.files和 fs.chunks集合來存儲文件的元數(shù)據(jù)和文件塊。MongoDBGridFS支持對存儲的大文件自動分片，分布式文件存儲架構(gòu)如圖1所示。

圖1 GridFS的文件存儲分片架構(gòu)

MongoDB的存儲架構(gòu)主要由三個部分組成：分片存儲服務器、集群路由服務器以及配置服務器。其中存儲服務器負責集群數(shù)據(jù)和文件的存儲，路由服務器負責請求的尋址和定位，而配置服務器保存集群服務器所有的配置信息。

MongoDB采用數(shù)據(jù)塊的概念作為基本的存儲單元，當單個數(shù)據(jù)塊的大小達到某個閾值之后，系統(tǒng)會進行數(shù)據(jù)塊分裂，各分片服務器通過數(shù)據(jù)塊存儲應用數(shù)據(jù)，當系統(tǒng)中各分片中的存儲塊的數(shù)量出現(xiàn)失衡時，會啟動再平衡算法，在各分片之間進行數(shù)據(jù)遷移，具體過程如圖2所示。

圖2 MongoDB數(shù)據(jù)存儲機制

1.2 MongoDB數(shù)據(jù)分片的片鍵選擇

MongoDB分片機制能夠根據(jù)文件的大小將數(shù)據(jù)劃分到不同的分片服務器上，數(shù)據(jù)分片一般應在數(shù)據(jù)庫建立早期進行，避免由于分片操作造成過多的系統(tǒng)開銷。要進行數(shù)據(jù)分片必須要選擇集合中一個或多個索引作為數(shù)據(jù)分片的基準，稱之為片鍵。片鍵的選擇關(guān)乎到集群的性能。MongoDB根據(jù)片鍵進行數(shù)據(jù)分塊主要包括以下幾個步驟：

（1）開啟集合的數(shù)據(jù)分片。

（2）創(chuàng)建集合字段索引。

（3）選定索引字段作為片鍵。

（4）系統(tǒng)會依據(jù)集合選定的片鍵對文檔數(shù)據(jù)進行分塊，使文檔數(shù)據(jù)按照片鍵分布在不同的數(shù)據(jù)塊中。

（5）各分片按照數(shù)據(jù)塊（chunk）的數(shù)量調(diào)整分片之間的數(shù)據(jù)分布。

2 基于高速緩存和MongoDB的遙感影像文件的存儲系統(tǒng)

MongoDB數(shù)據(jù)庫能夠兼容多種數(shù)據(jù)格式的遙感元數(shù)據(jù)，對于遙感影像文件的管理也較為方便，遙感數(shù)據(jù)滿足如下模型：

其中，Object Data指的是遙感元數(shù)據(jù)及其對象，Object Image表示遙感影像數(shù)據(jù)，Object Vector代表矢量數(shù)據(jù)對象。

通常對于遙感數(shù)據(jù)的訪問和操作主要集中于遙感元數(shù)據(jù)，因此可以使用內(nèi)存型緩存來加速這部分數(shù)據(jù)的訪問過程。本文研究的遙感元數(shù)據(jù)見表1。

表1 遙感元數(shù)據(jù)示例

根據(jù)對MongoDB分片機制的研究可知，當數(shù)據(jù)量過大時，各數(shù)據(jù)分片之間存在數(shù)據(jù)遷移操作，這會使系統(tǒng)開銷較大，影響系統(tǒng)的穩(wěn)定性。因此可以通過一致性哈希算法建立應用數(shù)據(jù)與分片節(jié)點之間的映射關(guān)系，減少系統(tǒng)級的數(shù)據(jù)平衡操作的執(zhí)行次數(shù)。

2.1 存儲系統(tǒng)的架構(gòu)設計

在設計存儲系統(tǒng)時，除了考慮遙感數(shù)據(jù)的存儲和管理之外，還需要保證與其他系統(tǒng)平臺兼容，要求系統(tǒng)具備接受和處理來自其他平臺的數(shù)據(jù)并且能夠為其他的應用平臺提供數(shù)據(jù)服務的能力。為了保證整個平臺的可靠性和擴展性，系統(tǒng)采用層次化設計，可分為交互層、服務層、數(shù)據(jù)緩存層和數(shù)據(jù)存儲層，系統(tǒng)分層結(jié)構(gòu)如圖3所示。

圖3 基于MongoDB的存儲系統(tǒng)的多層架構(gòu)模

（1）交互層位于整個系統(tǒng)的最前端，負責與其他系統(tǒng)或用戶進行交互。交互層提供了PULL和PUSH的兩種集成方式，支持多種傳輸協(xié)議和數(shù)據(jù)格式，一方面用戶可以通過PUSH方式定義的通用接口向系統(tǒng)提交遙感數(shù)據(jù)，另一方面用戶可以通過PULL方式獲取系統(tǒng)中的遙感數(shù)據(jù)，便于與其他系統(tǒng)集成。同時，交互層負責為客戶端提供遙感元數(shù)據(jù)的格式規(guī)范，影像文件以及高程文件的上傳接口。

（2）服務層為整個系統(tǒng)架構(gòu)的核心層，主要包括消息隊列模塊、任務調(diào)度模塊、數(shù)據(jù)庫操作服務以及元數(shù)據(jù)解析模塊。系統(tǒng)消息隊列負責接收用戶的上傳的數(shù)據(jù)，由服務程序?qū)崿F(xiàn)隊列數(shù)據(jù)的存儲，這樣能夠減少數(shù)據(jù)庫系統(tǒng)的瞬時壓力，以提高系統(tǒng)的并發(fā)能力。任務調(diào)度模塊負責調(diào)度和管理系統(tǒng)中的各種任務進程的執(zhí)行，任務調(diào)度模塊包含了任務執(zhí)行隊列、調(diào)度器以及觸發(fā)器等核心模塊［11］。任務調(diào)度模塊與消息隊列配合共同完成請求的分發(fā)和系統(tǒng)的負載均衡。

（3）緩存層用于緩存遙感元數(shù)據(jù)，使用內(nèi)存型緩存，如Memcache、Redis緩存服務器；通過高速緩存使常用數(shù)據(jù)常駐內(nèi)存，提高數(shù)據(jù)的訪問效率。通過緩存層訪問遙感數(shù)據(jù)的基本步驟：

S1：查詢根據(jù)給定的鍵值查詢緩存層是否包含數(shù)據(jù)。

S2：如果包含了所要的數(shù)據(jù)，直接從緩存層返回數(shù)據(jù)或影像文件信息。

S3：如果未命中緩存信息，則進入數(shù)據(jù)存儲層的對應數(shù)據(jù)庫獲取數(shù)據(jù)信息。

S4：系統(tǒng)將獲取的信息返回給上層客戶端，并回寫至緩存中。

（4）數(shù)據(jù)存儲層用于整個系統(tǒng)的數(shù)據(jù)存儲和備份，采用MongoDB及GridFS集群實現(xiàn)。其中MongoDB負責存儲和管理遙感元數(shù)據(jù)，GridFS集群負責存儲和管理遙感影像文件。

架構(gòu)模型通過引入哈希一致性算法，建立數(shù)據(jù)與分片節(jié)點之間的映射關(guān)系，均衡各分片之間的數(shù)據(jù)數(shù)量，減少分片之間的數(shù)據(jù)遷移次數(shù)。

使用哈希一致性算法分配存儲節(jié)點的過程如下：

初始化分片節(jié)點的ip地址序列－＞shards＿queue；

while（shards＿queue）｛

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

node＿key＝node＿id mod（232）；／／計算對應節(jié)點的key

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

｝

data＿key＝hash（data.item）；／／計算待存數(shù)據(jù)散列值

select＿ip＝selectNode（data＿key，node＿map）；／／選擇存儲的分片IP節(jié)點

return select＿ip；

2.2 遙感元數(shù)據(jù)模型的設計

高效的數(shù)據(jù)模型能夠很好滿足應用程序的需求，設計文檔數(shù)據(jù)結(jié)構(gòu)的關(guān)鍵在于考慮是使用嵌入式數(shù)據(jù)模型還是使用規(guī)范化的數(shù)據(jù)模型。如圖4所示，Location和TerrainInfo屬性字段作為子文檔嵌入到父級文檔中，這種嵌入式結(jié)構(gòu)是指與給定文檔相關(guān)聯(lián)的文檔以子文檔的形式存放于給定文檔內(nèi)部；規(guī)范化數(shù)據(jù)模型指各文檔之間通過使用、引用來表達對象之間的關(guān)系，如圖5所示，該結(jié)構(gòu)類似于關(guān)系型數(shù)據(jù)庫的外鍵關(guān)聯(lián)方式［12］。

圖4 嵌入式數(shù)據(jù)模型

圖5 規(guī)范化數(shù)據(jù)模型

存儲模型的設計需要權(quán)衡存儲空間的利用率和系統(tǒng)的查詢性能。遙感元數(shù)據(jù)包含一對多、多對多的實體關(guān)系，考慮到遙感元數(shù)據(jù)的特點，屬于讀占優(yōu)類型的數(shù)據(jù)，數(shù)據(jù)一旦寫入，修改可能性較小，因此選擇內(nèi)嵌式數(shù)據(jù)模型。另外選擇內(nèi)嵌式數(shù)據(jù)模型便于對遙感數(shù)據(jù)進行大規(guī)模的聚合和分析操作，提高系統(tǒng)對遙感數(shù)據(jù)的分析性能。

2.3 遙感元數(shù)據(jù)MongoDB存儲片鍵選擇

集合片鍵決定了數(shù)據(jù)在集群分片中的分布情況，影響系統(tǒng)的存儲性能，因此片鍵的選擇對于存儲系統(tǒng)的設計至關(guān)重要。良好設計的片鍵應具備升序片鍵和隨機片鍵的優(yōu)點。既要具備良好的數(shù)據(jù)局部性，也不至于由于數(shù)據(jù)分布過于局部出現(xiàn)數(shù)據(jù)熱點造成系統(tǒng)的讀寫瓶頸，要達到這種效果可以采用復合片鍵［13］。本文在分析遙感元數(shù)據(jù)的基礎上，提出了“升序鍵＋搜索鍵”的片鍵設計方案。

升序鍵一般選擇文檔中的自增＿id或時間戳，在遙感數(shù)據(jù)文檔中符合升序片鍵的字段有自增＿id和文檔記錄時間ObserveTime。字段＿id的自增特性會導致某個節(jié)點成為數(shù)據(jù)熱點造成數(shù)據(jù)過于集中，觀測時間字段ObserveTime既具有升序的特點又不至于使分片數(shù)據(jù)過于集中［14］；而應用程序?qū)?shù)據(jù)的訪問主要是集中在系統(tǒng)新數(shù)據(jù)的訪問，按照文檔時間進行數(shù)據(jù)分片能夠使新數(shù)據(jù)盡可能的保存于內(nèi)存中，提高數(shù)據(jù)的訪問效率［15］。

搜索鍵的選擇是根據(jù)應用需求設計的，為了保證查詢數(shù)據(jù)的隔離，搜索鍵采用常用的搜索字段［16］。對于本文中的遙感數(shù)據(jù)而言，較為頻繁使用的查詢字段是經(jīng)緯度，因此選擇經(jīng)緯度作為分片搜索鍵能夠讓經(jīng)緯度較近的數(shù)據(jù)分布集中，減少在查詢時訪問分片的次數(shù)。

本文選擇“記錄時間＋經(jīng)度＋緯度”作為復合片鍵，記錄時間片鍵能夠使文檔數(shù)據(jù)均勻分布在各分片上。選擇經(jīng)緯度作為搜索片鍵能夠提高系統(tǒng)的查詢性能和聚合分析能力，如圖6所示。

圖6 基于分片標簽的復合片鍵選擇策略

3 性能測試與分析

為驗證本文提出的基于MongoDB的多層分布式存儲系統(tǒng)的性能，基于上文提出的數(shù)據(jù)格式和文件類型進行一系列測試實驗。首先針對不同片鍵選擇策略下的數(shù)據(jù)分布和查詢性能的測試；然后驗證在引入內(nèi)存型緩存的情況下，對系統(tǒng)查詢性能的提升。

3.1 數(shù)據(jù)模擬

根據(jù)上文提出的遙感元數(shù)據(jù)模型，基于既有遙感數(shù)據(jù)信息庫模擬出20萬條遙感數(shù)據(jù)記錄，占用存儲空間約2.3 GB。模擬數(shù)據(jù)的選取范圍：

（1）數(shù)據(jù)的觀測時間從2017年1月到2017年8月份。

（2）遙感數(shù)據(jù)的觀測方式從“ht－yc－fengyun－01”和“ht－yc－fengyun－02”中隨機選取。

（3）觀測經(jīng)度數(shù)據(jù)在［115.6，119］區(qū)間內(nèi)產(chǎn)生隨機數(shù)，緯度數(shù)據(jù)在［28.2，35.7］區(qū)間內(nèi)產(chǎn)生隨機數(shù)。

對于選取的遙感數(shù)據(jù)模型中的其他字段，采用模擬填充方式生成字段內(nèi)容。

3.2 測試環(huán)境搭建

測試環(huán)境采用八臺微型計算機搭建成分布式的存儲平臺，存儲節(jié)點基本配置：內(nèi)存1 GB，硬盤大小120 GB，CPU Intel／英特爾 i5 7500，操作系統(tǒng) CentOS 6.3。其中6個節(jié)點作為數(shù)據(jù)存儲的分片節(jié)點，選取1個節(jié)點作為運行配置服務器，1個節(jié)點作為路由服務器。測試環(huán)境的網(wǎng)絡拓撲結(jié)構(gòu)如圖7所示。

圖7 測試環(huán)境拓撲結(jié)構(gòu)圖

3.3 數(shù)據(jù)分片性能測試

本節(jié)針對2.3節(jié)提出的｛記錄時間，經(jīng)度，緯度｝復合片鍵方案，通過模擬數(shù)據(jù)驗證該方案對數(shù)據(jù)分布的均衡性和查詢性能的提升。測試數(shù)據(jù)采用上文中提到的20萬條模擬數(shù)據(jù)，通過對比多組片鍵組合方案，驗證該復合片鍵方案的性能優(yōu)勢。片鍵策略的實驗分組見表2。

表2 片鍵策略的實驗分組

將模擬生成的20萬條數(shù)據(jù)按照表2的片鍵策略存入圖5所示的存儲平臺中，文檔分布結(jié)果見表3。

表3 文檔數(shù)量分布測試結(jié)果

對于表3中得到的測試數(shù)據(jù)，采用統(tǒng)計學中的標準差衡量數(shù)據(jù)分布是否均衡，計算結(jié)果見表4。

通過表4的標準差統(tǒng)計數(shù)據(jù)，｛ObserveTime，Longitude，Latitude｝片鍵方案文檔數(shù)據(jù)在集群中分布的比較均衡，說明｛ObserveTime，Longitude，Latitude｝片鍵選擇方案能夠優(yōu)化數(shù)據(jù)在集群中的分布。

表4 文檔數(shù)量分布標準差

圖8為基于測試數(shù)據(jù)的查詢性能統(tǒng)計情況，從中可以看出，總體上復合片鍵的查詢性能優(yōu)于單片方案，對于復合片鍵值｛ItemId，ItemName｝的查詢性能較差的原因，主要是由于該方案下數(shù)據(jù)分布的均衡性較差。復合片鍵｛Longitude，Latitude｝和｛ObserveTime，Longitude，Latitude｝的查詢性能明顯好于其他方案；其中｛ObserveTime，Longitude，Latitude｝方案不僅平均查詢時間較短，且查詢性能的穩(wěn)定性表現(xiàn)較好，后期數(shù)據(jù)量增大后性能波動較小，能較快實現(xiàn)收斂。

3.4 緩存模塊對查詢性能的影響

設置兩組對比實驗：一組是不使用緩存的分布式架構(gòu)設計（架構(gòu)一），另一種是在原來2.1節(jié)提出的增加了內(nèi)存型緩存的分布式存儲架構(gòu)（架構(gòu)二），通過計算文檔記錄平均查詢時間來衡量兩種架構(gòu)不同的性能表現(xiàn)，見表5。

圖8 查詢性能統(tǒng)計分析結(jié)果圖

表5 兩種不同架構(gòu)模型的平均文檔查詢時間

圖9為兩種架構(gòu)模型的文檔查詢的平均耗時對比圖。由圖9可知，在數(shù)據(jù)量較少時，兩種架構(gòu)模型的平均查詢耗時差距不大，隨著數(shù)據(jù)量的增大，架構(gòu)二（緩存模型）的性能優(yōu)勢逐漸凸顯出來，平均查詢時間明顯低于架構(gòu)一，且平均查詢耗時也趨于穩(wěn)定；因此可以看出緩存模型能夠較好地改善遙感數(shù)據(jù)的查詢性能。

圖9 兩種架構(gòu)模型的平均耗時對比

4 結(jié)束語

本文基于非關(guān)系型數(shù)據(jù)庫MongoDB，提出了一種海量遙感數(shù)據(jù)的分布式存儲方案，通過引入內(nèi)存型緩存提高遙感數(shù)據(jù)的查詢和存儲效率，使用一種針對遙感數(shù)據(jù)特點的分片數(shù)據(jù)方案；并通過實驗驗證了該存儲方案對海量遙感數(shù)據(jù)的存儲具有一定的優(yōu)越性。該方案具有一般性意義，能夠運用到其他場景中；下一步工作將進一步對這種存儲方案進行優(yōu)化，以提高其整體性能。

參考文獻：

[1]孫敬杰,曾李陽,張堯.基于MongoDB的Web空間數(shù)據(jù)存儲與管理研究[J].測繪,2017,40(2):72-74,89.

[2]祁蘭.基于MongoDB的數(shù)據(jù)存儲與查詢優(yōu)化技術(shù)研究[D].南京:南京郵電大學,2016.

[3]高銳.基于MongoDB的黑河流域時空數(shù)據(jù)云存儲關(guān)鍵技術(shù)研究[D].蘭州:蘭州大學,2016.

[4]徐旭東,郭瑞,文瑞潔.分布式下MongoDB對激光點云的存儲和處理研究[J].計算機應用與軟件,2017,34(2):71-73,168.

[5]潘永華,閉應洲,符云琴.基于MongoDB的醫(yī)學圖像管理技術(shù)研究[J].廣西師范學院學報:自然科學版,2017,34(2):54-59.

[6]王震,余洋,張志強,等.基于MongoDB的遙感影像存取方案的探討與實現(xiàn)[J].測繪地理信息,2017,42(3):39-43.

[7]田帥.一種基于MongoDB和HDFS的大規(guī)模遙感數(shù)據(jù)存儲系統(tǒng)的設計與實現(xiàn)[D].杭州:浙江大學,2013.

[8]賴積保,羅曉麗,余濤,等.一種支持云計算的遙感影像數(shù)據(jù)組織模型研究[J].計算機科學,2013,40(7):80-83,115.

[9]秦強,王晏民,黃明.基于MongoDB的海量遙感影像大數(shù)據(jù)存儲[J].北京建筑大學學報,2015,31(1):62-66.

[10]梁海.MongoDB數(shù)據(jù)庫中Sharding技術(shù)應用研究[J].計算機技術(shù)與發(fā)展,2014,24(7):60-62,67.

[11]馮東煜,朱立谷,肖子達,等.一種MongoDB集群數(shù)據(jù)布局優(yōu)化方法研究[J].計算機工程與應用,2017,53(17):77-84.

[12]雷德龍,郭殿升,陳崇成,等.基于 MongoDB的矢量空間數(shù)據(jù)云存儲與處理系統(tǒng)[J].地球信息科學學報,2014,16(4):507-516.

[13]江穎,鄔群勇,唐曙光,等.基于MongoDB的閩西客家文化數(shù)據(jù)存儲設計與分析[J].測繪工程,2016,25(3):56-60.

[14]張路路.基于MongoDB的大數(shù)據(jù)存儲方法研究與應用[D].成都:成都理工大學,2015.

[15]邱儒瓊,鄭麗娜,李兵.基于MongoDB的電子地圖瓦片數(shù)據(jù)存儲和服務研究[J].地理空間信息,2014,12(6):155-157,6.

[16]張堯,甘泉,劉建川.基于MongoDB的地理信息共享數(shù)據(jù)存儲模型研究[J].測繪,2014,37(4):147-150,172.