基于分布式數據庫的礦山生態評價系統基于分布式數據庫的礦山生態評價系統

陳振武，黃澤坤，盧文濤，林 柯，張哲涵，林思思，蘭添才

(1.龍巖學院；2.大數據挖掘與應用福建省重點實驗室 福建龍巖 364000)

對礦山生態環境的評價數據廣泛分布于礦山各個角落，對數據的收集、存儲與加工處理具有實時的特性，對于這些數據的收集、加工、處理、存儲，具備了去中心化的分布式數據存儲與應用特性。近年來，國內外諸多專家學者進行了相應的研究并應用于物流管理、倉儲管理以及礦山信息管理領域。

文獻[1]研究云計算、服務器虛擬化、分布式數據庫等技術，建設了具有中心數據庫并實現各地分布式數據庫交互的兗礦應急救援示范平臺。在企業資產管理應用方面，可以利用非關系數據庫MongoDB設計實現[2]。

由于關系型數據庫的橫向數據存儲的擴展在Web應用設計中是比較困難的，而非關系型數據庫對數據的存儲一般以文檔的形式進行，對數據的查詢操作沒有橫向的概念，也可以無須建立固定的鍵值[3]。文獻[4]證明了將使用MongoDB數據庫提供Web存儲服務融合前端交互設計，比傳統的關系數據庫具有更好性能(數據處理速度及資源占用率)優勢。史曄翎等[5]也證明了這種結合，可以彌補關系型數據庫在數據存儲方面的缺點。

本文利用端開源框架Angular以及MongoDB在分布式存儲系統的高可用特性，將Angular與傳感器自動獲取相關環境指標數據技術融合，將礦山企業各分支機構的生態數據存儲系統整合，實現對異地分布的礦山生態實時數據的高效存儲與評價管理。

1 系統高可用性架構

本系統高可用性設計的基礎思想包括[6-7]：

(1)業務服務器的建立。邏輯上將一些位于同一地點或不同地點的服務器集中建立業務服務器系統；

(2)數據庫分層架構。物理上采用分布式架構，系統架構示意參見圖1所示；

(3)數據分區的設計。整個系統需依據數據庫的規模設定一個或多個數據分區；

(4)為每個分區選擇設定相應的“key”。該“key”是對數據存儲所在的分區位置的標識，也可做為共享數據元素的相應“key”的拷貝；

(5)系統重構功能的設定。通過共享數據元素“key”對分區位置的標識設定，構成可復制的若干系統重構Replica_Set節點及樹形結構(包括主節點與從節點的定義)，其中，同級節點間須有相同數據備份；

(6)分區服務器設置。包括端口、IP及名稱的設置；

(7)節點服務器配置。為分區內的每個節點配置至少一個或多個路由器，提供客戶端連接路由服務申請，并向數據分區分發客戶端的路由申請。

2 數據庫分層架構

利用數據庫的分層架構，也叫N層架構[7]，本文采用4層數據倉庫結構模型，架構示意參見圖2所示。

3 數據庫分區與操作均衡

3.1 數據庫系統用例

數據庫系統的超級用戶、普通用戶用例參見圖3所示。

圖3 數據庫系統用例

超級用戶：能夠對普通用戶進行管理與設定，也可以對生態環境指標監測的傳感器終端設備進行設置(包括設備的啟/停、初始化、IP地址，客戶端數據庫訪問權限，評價系統的指標比例因子，數據庫服務的啟/停等)；

普通用戶：可以按照需求申請數據庫，獲得對相應云數據庫訪問的地址、端口及數據庫名稱等信息。功能主要包括啟/停數據庫、修改用戶信息、日常維護以及對相關節點的生態環境信息進行采集、錄入、管理、回存等基本操作。

3.2 建立分區數據庫

由于MongoDB可以支持依據數據分類將數據拆分并自動存儲到相應分區的功能，這就為建立分布式系統架構進而對大量分散數據進行分區存儲提供依據。

分區數據庫的建立關鍵點，首先需對相應數據進行分組，分組的依據是屬性的定義。各分區具有代表性的屬性一般都是被定義成關鍵屬性或稱為共享鍵(如Share_key01、Share_key02……)，并作為建立數據分區的依據。如使用“聲環境”sound_key可以用來定義各噪音污染傳感節點數據庫、傳感節點設置位置等數據庫表的共享屬性鍵?？蛻舳藢Α奥暛h境”sound_key查詢時，如果發現該key屬于某礦山“聲環境”數據庫，則將該key發送到該礦山“聲環境”數據分區所在的分區服務器或客戶端上；獲取該“聲環境”數據的對應傳感器節點或通過人工錄入數據的節點所屬的指標庫信息發送到相應的分區數據庫中。然后將分組數據分別存儲于較大的一級分區中，再對一級分區進一步細分為基于稍小些的二級分區并負責存儲上一級分區總數據的一部分，依此類推。這里需要對分區數據庫的連接狀態進行分別定義，包括主控程序創建相應的管理進程、客戶端對分區數據庫的連接申請進程，很明顯此兩進程須為不同名，否則，系統會產生沖突。

3.3 數據分區的均衡性

分析MongoDB的特性可以發現，其對數據的存儲與處理機制是通過將用戶或系統訪問的數據緩存至本地進行的。這種機制中，對數據庫的數據添加造成對節點的工作負載遠比對數據的讀取、寫入負載大，會造成數據塊所在的節點的負載不均衡[8]，系統需對這種負載不均衡進行適時調節，否則系統很容易產生因對某個節點數據、文檔高密度訪問而造成系統擁堵甚至崩潰，但調節過程又會造成系統資源的浪費[9]。

對節點數據庫的均衡操作關鍵是如何將對數據的插入、查找、修改等操作比重進行均衡性調節，文獻[3]采用在計算對數據庫的插入數據頻率時乘上一個大于1的調節系數(λ)的方法來實現對插入、查找、修改等操作的均衡性。同時，利用文獻[9]所提出的基于數據操作的頻率(FODO)改進的均衡算法設計，以實現對分區節點數據庫的均衡操作。算法的Python描述如下：

(1)初始化

#導入python的random庫及numpy模塊中的隨機函數

import random

import numpy

#數據操作頻率計算，p為節點數，M[i][j]文檔操作參數矩陣

p = input(“集群節點數”)

p = int(p)

M = [[0]*5]*p #第一列文檔塊 第二列操作頻率 第三列插入操作頻率 第四列查詢操作頻率 第五列更改操作頻率

for i in range(0，p):

for j in range(0，5):

M[i][j]= random.randint(1，10)

print(M)

(2)計算各節點各文檔塊總體操作頻率及各種操作頻率

#變量SUM_O、SUM_I、SUM_F、SUM_C、SUM_SUM_DO分別用于存放對各節點文檔塊的操作次數之和及插入、查詢、修改、整個分區的操作頻率之和

賦各變量初值(為零)

for i in range(0，p):

for j in range(0，5):

SUM_O = SUM_O + M[i][1]

SUM_I = SUM_I + M[i][2]

SUM_F = SUM_F + M[i][3]

SUM_C = SUM_C + M[i][4]

#DO、DI、DF、DC、SUM_DO分別用于存放對各節點文檔塊操作頻率及對文檔塊的插入、查詢、修改操作頻率、所有操作頻率之和[10].

for a in range(0，p):

print(“這是第” + str(a) +“個節點”)

DO = M[a][1] / SUM_O

DI = M[a][2] / SUM_I

DF = M[a][3] / SUM_F

DC = M[a][4] / SUM_C

print(DO)

SUM_DO = DI + DF +DC

print(SUM_DO)

(3)計算引入調節參數λ后各節點文檔塊數據操作頻率SUM_DOX

#λ是為了調整插入操作與查找、修改操作的均衡關系參數，λ>1

λ = input(“調節參數”)

SUM_DOX = λ*DI + DF +DC

print(SUM_DOX)

(4)計算整個分區的操作頻率

#用每個節點中所有文檔數據的操作頻率之和即是整個分區的操作頻率

SUM_SUM_DO = SUM_SUM_DO + M[a][0]*SUM_DO

print(SUM_SUM_DO)

4 系統設計與實現

4.1 系統功能模塊

模塊包括指標統計、數據庫設計、指標數據獲取與輸入(傳感器采集與人工獲取兩部分數據)、管理與維護、節點訪問均衡性設置共五個模塊，采用B/S模式。各服務器均可存儲數據并運行數據管理程序。

(1)指標統計。為了克服定性評價對結論的影響，采用融合層次分析與模糊數學分析方法對綜合評價指標進行統計計算，層次分析法中的評價結構分為三層；

(2)數據庫設計。系統數據庫共需四張表用于存儲指標權重、判斷矩陣、實測指標(人工)、傳感器指標(自動采集)，分別為Q_zhong表、PD_max表、RG_sc表、CG_cj表；

(3)數據獲取與輸入。通過傳感器獲取的數據主要包括聲音、水質、空氣等數據(如噪音指標、空氣的PM值、水質的PH值，等等)送入數據庫；無法布設傳感器則通過人工實測獲取(如廢棄物的排放量、地災頻度與規模、土地壓占面積或圧占率、土地復墾面積或復墾率，等等)，并可以在任一節點上進行手工輸入，以體現分布式存儲的優點；

(4)系統管理與維護。由超級管理員承擔對系統進行相關的管理與維護，包括對普通管理員帳戶的管理與修改，也可以對指標進行管理操作，如屬性定義、添加刪除修改、指標權重調整等操作；

(5)節點訪問均衡性。通過設置與調整節點訪問均衡性參數λ(λ>1)對存儲于分布式系統中的數據進行均衡性調整，實現對分區節點數據庫的均衡操作。

4.2 頂層數據流圖

頂層數據流圖主要用于描述超級管理員與普通管理員之間操作不同的功能模塊所產生的數據流向關系，功能模塊包括判斷矩陣、傳感器數據、人工數據的輸入、數據的請求與返回、超級管理員、普通管理員等模塊。系統頂層數據流參見圖4所示。

圖4 系統頂層數據流

4.3 第二層數據流圖

第二層數據流所描述的是各角色(主要是指不同管理員)操作相應功能模塊所產生的數據流向關系。不同角色具有不同的操作權限。系統第二層數據流參見圖5所示。

圖5 系統第二層數據流

4.4 系統設計與實現

4.4.1 數據庫設計

從業務數據節點、數據安全、節點數據一致性及節點數據訪問頻率等方面的需求進行分布式數據庫設計，還需對系統重構、數據備份進行相應架構與設計，系統共設計了5張表用于存放用戶信息、各分區節點服務器數據、評價要素權重、評價指標要素、傳感器信息采集[11]。

(1)用戶信息表結構應包括名稱、密碼、編號、角色、郵箱等字段；

(2)各分區節點服務器數據表結構包括節點名稱、編號、節點地址、節點IP等字段；

(3)評價要素權重表結構包括指標名稱(一級指標、二級指標、三級指標)、指標權重(對應于指標名稱分別建立指標三層權重A、ai、aij)等字段；

(4)評價指標要素表主要指因素指標的判斷矩陣格式表，判斷矩陣的建立是依據各級評價指標要素之間的關系利用層次分析及模糊數學分析融合的方法進行整理建立起來的[11]；

(5)傳感器數據采集表：所屬礦山名稱、礦山位置ID、管理員、傳感器布設位置信息、傳感器ID、指標數據采集日期時間、采集的指標數據。

4.4.2 系統前端對數據庫的訪問

系統前端對數據庫的訪問可以通過封裝在Angular中的“http客戶端”模塊、封裝在ng-alain中的“http客戶端”方法進行，通過這種基于“http客戶端”的模塊與方法可以很方便地自動添加請求并對返回的數據格式進行加工與處理。本文利用Postman軟件提供能夠根據用戶不同接口定義去選擇http的請求并進行數據接口的配置與服務器的部署。

4.4.3 功能模塊實現

系統功能模塊包括一級的登錄模塊，成功登錄后即可進行二級模塊的操作(包括判斷矩陣構建、判斷矩陣一致性校驗、傳感器管理、手工實測數據管理、評價及評價結果管理等)，依此類推。

系統登錄主界面參見圖6所示。

實現系統登錄主界面的代碼可簡單表述如下(其他模塊及實現代碼略)。

if (res.role === '') {

this.error = res.msg;

return;

}

if (res.role === 'ROLE_USER') {

this.aclService.setRole(['ROLE_USER']);

}

if (res.role === 'ROLE_ADMIN') {

this.aclService.setFull(true);

}

//路由信息清理

this.reuseTabService.clear();

// 設置用戶標志信息

this.tokenService.set(res);

//當應用信息受當前用戶授權范圍影響需要重新啟動服務

const user = {

name: res.name，

// avatar: res.avatar，

avatar: './assets/tmp/img/avatar.jpg'，

userId: res.id，

};

this.settingsService.setUser(user);

this.startupSrv.load().then(() => {

let url = this.tokenService.referrer.url || '/';

if (url.includes('/passport')) url = '/';

this.router.navigateByUrl(url);

});

}

5 結束語

針對在多點多級生態環境評價指標系統所涉及的復雜應用管理，探索將分布式數據庫、傳感器技術結合應用于指標數據的獲得與存儲，對于異地性、分布式的礦山生態環境評價的大規模數據管理與分析具有一定的借鑒意義。由于不同類型礦山的開采方式、生態影響范圍、評價指標定義及指標權重選擇、環境治理恢復方式及程度要求也不盡相同，因此，評價指標數據的可擴展性、自適應性等方面的研究還需要進一步開展；通過傳感器自動獲取生態指標數據的種類也可不斷研究擴展，以減少指標數據人工獲取的主觀影響；各層次指標權重的設定主要依據評估專家的意見建議并結合層次分析或融合層次分析與FUZZ進行，可以進一步探索通過更為合理、全面的數學方法，以獲得更為準確的評價結論。