電網(wǎng)圖形數(shù)據(jù)管理MongoDB數(shù)據(jù)庫的應(yīng)用①

趙 越, 李 培, 王 震, 張聲圳

?

電網(wǎng)圖形數(shù)據(jù)管理MongoDB數(shù)據(jù)庫的應(yīng)用①

趙 越1, 李 培1, 王 震2, 張聲圳2

1(國網(wǎng)江蘇省電力公司揚(yáng)州供電公司, 揚(yáng)州 225000)2(廈門億力吉奧信息科技有限公司, 廈門 361008)

國家電網(wǎng)公司正推進(jìn)資產(chǎn)全壽命周期管理體系建設(shè), 電網(wǎng)GIS圖形作為電網(wǎng)的信息化表征, 為了實現(xiàn)電網(wǎng)異動信息的全過程管理, 通過電網(wǎng)圖形多時態(tài)多級管理機(jī)制, 同時引入MongoDB非關(guān)系型數(shù)據(jù)庫, 提升了數(shù)據(jù)讀寫效率, 最終滿足電網(wǎng)各業(yè)務(wù)部門海量數(shù)據(jù)信息化應(yīng)用的性能需求.

電網(wǎng)圖形; 多時態(tài)多級; 分布式及分片; MongoDB

隨著電網(wǎng)公司信息化建設(shè)的推進(jìn), 電網(wǎng)GIS作為電網(wǎng)設(shè)備資源管理的平臺, 目前已實現(xiàn)了全電壓等級的設(shè)備的信息錄入, 大網(wǎng)省的設(shè)備數(shù)量以億計; 同時其作為一線人員工作業(yè)務(wù)支撐平臺, 并發(fā)量大, 業(yè)務(wù)操作復(fù)雜. 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫難以提供超大規(guī)模的數(shù)據(jù)存儲以及高并發(fā)的讀寫訪問能力, 以至于隨著圖形數(shù)量等級的上升, 系統(tǒng)已無法及時響應(yīng)高并發(fā)的復(fù)雜業(yè)務(wù)操作.

在此背景下, 亟需采取新的技術(shù)手段來提升海量數(shù)據(jù)大并發(fā)讀寫的效率. 非關(guān)系型數(shù)據(jù)庫存儲的廣義定義, 不需要固定的表結(jié)構(gòu), 使其在大數(shù)據(jù)量高并發(fā)的讀寫操作有很高的效率. 除此之外, 一線業(yè)務(wù)人員對相關(guān)電網(wǎng)專題圖的管理要求不一, 同時為了實現(xiàn)圖形版本管理融入時態(tài)、空間、人物等基本特征, 構(gòu)建多時態(tài)、多級數(shù)據(jù)管理模式, 實現(xiàn)電網(wǎng)圖形從規(guī)劃、設(shè)計、運(yùn)行整個過程的實時跟蹤, 滿足各業(yè)務(wù)部門甚至不同業(yè)務(wù)人員特定圖形應(yīng)用需求, 實現(xiàn)電網(wǎng)的全過程管理.

為了提高海量圖形數(shù)據(jù)的處理效率, 本文提出基于MongoDB數(shù)據(jù)庫進(jìn)行電網(wǎng)圖形的多時態(tài)多級分布式存儲機(jī)制, 實現(xiàn)了電網(wǎng)從規(guī)劃、設(shè)計、投運(yùn)的全過程動態(tài)實時跟蹤, 并根據(jù)業(yè)務(wù)部門及人員的不同圖形需求實現(xiàn)多級管理, 同時利用MongoDB非關(guān)系型數(shù)據(jù)庫大數(shù)據(jù)量高并發(fā)讀取效率高的特點, 大大提升了圖形應(yīng)用效果.

1　多時態(tài)多級圖形管理機(jī)制

空間、屬性和時間是GIS的三個基本特征, 同時是其數(shù)據(jù)的三種基本數(shù)據(jù)成分. 傳統(tǒng)GIS系統(tǒng)記錄的只是不斷變化的實際的某一“瞬間”特性. 當(dāng)數(shù)據(jù)隨時間變化時, 我們用新數(shù)據(jù)代替舊數(shù)據(jù), 系統(tǒng)又稱為世界的另一個“瞬間”[1]. 這種模式忽略了其時間特性, 但是在另外一些領(lǐng)域, 如電網(wǎng)領(lǐng)域其狀態(tài)隨時間的緊密關(guān)聯(lián), 不同時刻電網(wǎng)所處的狀態(tài)千變?nèi)f化, 采用傳統(tǒng)電網(wǎng)圖形管理方式僅僅是從版本角度進(jìn)行管理, 電網(wǎng)圖形發(fā)生了變動即增加一個相應(yīng)的圖形版本, 并未實現(xiàn)多維度上的時態(tài)化管理, 為了滿足國家電網(wǎng)公司多業(yè)務(wù)部門的應(yīng)用需求, 實現(xiàn)電網(wǎng)圖形的全過程管理. 本文提出多時態(tài)多級數(shù)據(jù)管理方式.

電網(wǎng)圖形從規(guī)劃設(shè)計、基建、運(yùn)行的整個過程實時跟蹤, 記錄不同時刻的電網(wǎng)狀態(tài)變化, 滿足了各業(yè)務(wù)部門甚至不同業(yè)務(wù)人員特定圖形應(yīng)用需求, 并實現(xiàn)了整個電網(wǎng)異動的全過程管理. 具體管理機(jī)制如下:

圖1　多時態(tài)多級管理機(jī)制

根據(jù)電網(wǎng)的設(shè)計、建設(shè)和運(yùn)行分別對應(yīng)一個時態(tài)集, 每個時態(tài)集合分別有一個基準(zhǔn)線, 在基準(zhǔn)版本上進(jìn)行迭代更新演化, 同時只支持時態(tài)的推進(jìn)不支持回退, 即規(guī)劃設(shè)計的最后一個基準(zhǔn)版本演化成建設(shè)的基準(zhǔn)版, 建設(shè)的最后一個基準(zhǔn)版本演化成運(yùn)行態(tài)的基準(zhǔn)版. 同時在同一時態(tài)內(nèi), 如在設(shè)計態(tài)基準(zhǔn)線中, 基準(zhǔn)版與基準(zhǔn)版1和基準(zhǔn)版2的轉(zhuǎn)化方式如下所示:

基準(zhǔn)版本i+1只能基于基準(zhǔn)版i的基礎(chǔ)上進(jìn)行“增量”滾動遞歸更新, 同時記錄每次基準(zhǔn)版更新的所有記錄以及修改人員.

同時, 在運(yùn)行態(tài)支持不同業(yè)務(wù)人員對圖形版本的個性設(shè)置, 實現(xiàn)多級的管理方式. 該展示方式是基于當(dāng)前運(yùn)行基準(zhǔn)版本進(jìn)行個性化選擇展示的.

然而, 隨著電網(wǎng)的不斷發(fā)展與壯大, 電網(wǎng)設(shè)備數(shù)量特別是配網(wǎng)設(shè)備呈指數(shù)級增長, 如江蘇電網(wǎng)的圖形數(shù)據(jù)量以億計, 如何在高效快速地實現(xiàn)圖形相關(guān)功能滿足用戶的體驗需求是亟需解決的問題. 故本文進(jìn)行了非結(jié)構(gòu)化數(shù)據(jù)庫技術(shù)的應(yīng)用探索.

圖2　同一時態(tài)下圖形版本轉(zhuǎn)化

2　基于MongoDB的分布式存儲設(shè)計

2.1 非關(guān)系型數(shù)據(jù)庫

傳統(tǒng)關(guān)系型數(shù)據(jù)庫具有高穩(wěn)定性、使用簡單, 功能強(qiáng)大等優(yōu)點[2], 隨著智能電網(wǎng)的建設(shè), 電網(wǎng)數(shù)據(jù)以億計, 隨著“大數(shù)據(jù)”技術(shù)的應(yīng)用不斷深入, 對海量數(shù)據(jù)的分析與應(yīng)用需求不斷加深, 然而傳統(tǒng)的關(guān)系型數(shù)據(jù)庫難以提供超大規(guī)模的數(shù)據(jù)存儲以及高并發(fā)高速讀寫訪問能力.

隨著技術(shù)的發(fā)展, NoSQL數(shù)據(jù)庫應(yīng)運(yùn)而生, 其不需要固定的表結(jié)構(gòu), 通常也不存在連接操作. 采用key-Value存儲、文檔型、xml等方式存儲數(shù)據(jù)模型. 其具有易擴(kuò)展性、大數(shù)據(jù)量高性能、靈活的數(shù)據(jù)模型等優(yōu)點. 而MongoDB作為非關(guān)系型數(shù)據(jù)庫的典型代表, 其支持自動分片且可以水平方向的數(shù)據(jù)庫集群; 同時支持豐富的查詢表達(dá)式, 可支持查詢文檔中內(nèi)嵌的對象及數(shù)組, 該特性在拓?fù)渥匪莘治鰰r非常重要; 其還具備全索引等優(yōu)點. 本項目選取MongoDB作為應(yīng)用的數(shù)據(jù)庫.

2.2 架構(gòu)設(shè)計

分片是指將數(shù)據(jù)拆分, 將其分散存在不同的機(jī)器上的過程, 其作為MongoDB的擴(kuò)展方式, 其基本思想就是將集合切分成小塊, 再將這些塊分散到若干片里面, 每個片只負(fù)責(zé)總數(shù)據(jù)的一部分[3]. 再通過路由進(jìn)程Mongos記錄數(shù)據(jù)的存儲位置, 應(yīng)用通過連接它來正常發(fā)送請求. 本文基于這種思想設(shè)計圖形的多級多時態(tài)的分布式存儲框架.

2.2.1分布式存儲框架

① 服務(wù)器上分別部署9個Mongo節(jié)點 3個配置服務(wù)節(jié)點(ConfigSvr)1個路由節(jié)點Mongos.

圖3 基于Mongo分布式存儲框架圖

② 不同服務(wù)器上面的節(jié)點A1、B1、C1構(gòu)建成一個復(fù)制集1( Replica Sets). 復(fù)制集中的節(jié)點A1、B1、C1的存放的數(shù)據(jù)是相同的, 能夠相互復(fù)制, 異步同步. 構(gòu)建復(fù)制集的作用是防止一個服務(wù)器或者一個節(jié)點不能工作導(dǎo)致數(shù)據(jù)丟失.

③ 配置服務(wù)器是用于構(gòu)建記錄分片(Shards)存儲信息. 數(shù)據(jù)集按照數(shù)據(jù)集數(shù)據(jù)范圍或者使用哈希值進(jìn)行數(shù)據(jù)分片存儲. 分片信息記錄在配置服務(wù)器上, 所有的配置服務(wù)器共享這些信息.

④ Mongos就是MongoDB中的路由器進(jìn)程, 它路由所有請求, 然后將結(jié)果聚合, 其本身不存儲數(shù)據(jù)或者配置信息(但會緩存配置服務(wù)器的信息).

2.2.2分片存儲方式

由于基于范圍的分片方式具有高效的范圍查詢, 但是會導(dǎo)致數(shù)據(jù)在不同分片上的不均衡; 基于哈希的分片方式使得所有分片數(shù)據(jù)分布均衡, 但是查詢時候會訪問所有的分片, 影響查詢效率. 本發(fā)明對數(shù)據(jù)的讀寫效率要求較高, 故采取基于范圍的分片方式. 本項目的分配存儲方式如下:

圖4 分片存儲架構(gòu)

2.3 存儲設(shè)計

本管理機(jī)制主要涉及版本數(shù)據(jù)管理、圖檔數(shù)據(jù)結(jié)構(gòu)以及設(shè)備關(guān)系結(jié)構(gòu)三個大的方面, 下面重點介紹這些數(shù)據(jù)的存儲設(shè)計.

2.3.1版本數(shù)據(jù)結(jié)構(gòu)設(shè)計

通過實現(xiàn)對版本的遞歸轉(zhuǎn)化以及同時態(tài)的多級管理, 實現(xiàn)不同人員對專題圖的不同需求以及版本的全過程管理. 結(jié)構(gòu)形式如下:

{

TreeId //樹節(jié)點編號, 數(shù)字

Code //節(jié)點對應(yīng)編碼(如饋線ID), 字符串

VersionId //版本編碼, 字符串

VersionName //版本名稱, 字符串

VersionType //版本類型, 字符串

VersionCode //版本編碼, 字符串

UserName //版本更新人, 字符串

CreateTime //版本創(chuàng)建時間, 字符串

EditTime //版本更新時間, 字符串

DataSource //更新來源(PMS,GIS), 字符串

SchematicType //圖紙類型, 字符串

VersionState //版本狀態(tài), 圖檔狀態(tài)

CoordinateOrigin //坐標(biāo)原點, 嵌套

{

x //坐標(biāo)點, 數(shù)字

y //坐標(biāo)點, 數(shù)字

}

}

下面以規(guī)劃人員繪制的一個單線圖版本為例, 具體如下:

{

VersionId:"10000001",

TreeId:"10102010101",

Code:"321002001001",

VersionType:"規(guī)劃圖紙",--規(guī)劃圖紙, 設(shè)計圖紙, 運(yùn)行圖紙

VersionName:"規(guī)劃圖紙單線圖未發(fā)布版本v003",

VersionCode:"v003",

UserName:"規(guī)劃人員",

CreateTime:"2015-07-29 09:04:31",

EditTime:"2015-07-29 09:04:31",

DataSource:"PMS",--PMS,GIS

SchematicType:"單線圖",--單線圖, 網(wǎng)絡(luò)圖, 沿布圖

VersionState:"未發(fā)布",

CoordinateOrigin:[{x:10.23423424,y:111:2423442343}]

}

2.3.2圖檔數(shù)據(jù)結(jié)構(gòu)設(shè)計

圖檔數(shù)據(jù)存儲結(jié)構(gòu)是存儲機(jī)制的一個重點, 具體存儲結(jié)構(gòu)如下:

{

VersionId //版本編號, 字符串

GisFeatureType //設(shè)備類型(點, 線, 面, 標(biāo)注), 字符串

Fid //設(shè)備唯一編碼, 字符串

Fno //設(shè)備類型編碼, 字符串

FeatureFid //設(shè)備臺賬ID, 字符串

FeederFid //設(shè)備所屬饋線FID, 字符串

OwnerFeatureFid //設(shè)備從屬設(shè)備FID, 字符串

IsContact //是否聯(lián)絡(luò)設(shè)備, 布爾值

ModifyStatus //設(shè)備修改狀態(tài), 字符串

RoleId

ShapeComponents:[ //設(shè)備組件,嵌套ShapeComponent

{

GisFeatureFid //設(shè)備FID, 字符串

GisFeatureFno //設(shè)備FNO, 字符串

Angle //角度, 數(shù)字

SymbolSid //組件樣式ID,數(shù)字

SchematicPoints:[ //坐標(biāo)集, 嵌套

{x:10.23423424,y:111:2423442343},

{x:12.23423424,y:114:2423442343}

],

ShapeComponentType //組件類型, 字符串

}

],

LabelComponents:[//設(shè)備標(biāo)注,嵌套LabelComponent

{

GisFeatureFid: //設(shè)備FID, 字符串

GisFeatureFno://設(shè)備FNO, 字符串

Angle: //角度, 數(shù)字

SymbolSid: //組件樣式ID,數(shù)字

SchematicPoints:[//坐標(biāo)集, 嵌套point

{x:10.23423424,y:111:2423442343},

{x:12.23423424,y:114:2423442343}

],

ShapeComponentType //組件類型, 字符串

SymbolText //標(biāo)注內(nèi)容, 字符串

TextStyle:{ //標(biāo)注樣式, 嵌套TextStyle

FontFamily //字體名稱, 字符串

FontSize //字體大小, 數(shù)字

Fill //字體顏色, 字符串

}

}

],

GisAttribute:{ GisAttribute//設(shè)備的功能屬性, 嵌套

Name //功能位置名稱, 字符串

ShortName//短名稱(桿塔), 字符串

KGBH //運(yùn)行編號, 字符串

Length //長度, 數(shù)字

EleStatus //帶點狀態(tài), 字符串

Basevoltage//基級電壓, 字符串

Zone //所屬區(qū)域, 字符串

Normalopen //開關(guān)狀態(tài), 字符串

PoleId //所屬桿塔ID, 字符串

YYHH //字符串

Rates //字符串

Pfixed //電壓等級

UserType //字符串

OperatingCapacity //工作效率

LineModel //線模型

LineLength //線長

}

}

2.3.3設(shè)備關(guān)系存儲結(jié)構(gòu)

{

Fid //設(shè)備ID, 字符串

RelationShipFid//拓?fù)鋵?yīng)的設(shè)備ID, 字符串

VersionId //版本ID, 字符串

RelationType //包含關(guān)系(連接關(guān)系), 字符串

},

{

PrimaryFid //主設(shè)備Fid, 字符串

ThroughFid //經(jīng)過的設(shè)備, 字符串

AccessoryFid //附屬設(shè)備, 字符串

RelationType//包含關(guān)系(包含關(guān)系), 字符串

VersionId //版本ID, 字符串

}

通過以上的存儲設(shè)計, 同時通過設(shè)計、建設(shè)和運(yùn)行態(tài)的管理機(jī)制, 實現(xiàn)圖形多級多時態(tài)管理.

3　與關(guān)系型數(shù)據(jù)庫效率對比

基于本存儲機(jī)制進(jìn)行存儲效率驗證, 通過基于MongoDB數(shù)據(jù)庫的電網(wǎng)圖形多時態(tài)多級的分布式存儲機(jī)制進(jìn)行千萬級數(shù)據(jù)效率測試, 同時對比傳統(tǒng)關(guān)系型數(shù)據(jù)庫Oracle的讀寫效率.

本次對比驗證是基于以下條件:

① 基于27000000數(shù)量級數(shù)據(jù), 由于存儲結(jié)構(gòu)形式不同, 數(shù)量上略有百條數(shù)據(jù)量的差別;

② 分頁查詢、插入數(shù)據(jù)以及指定查詢條件相同, 同時查詢結(jié)果也需相同.

分別進(jìn)行1、10、100、500、1000、5000、10000、20000、30000、50000次的分頁查詢、插入數(shù)據(jù)、指定查詢操作, 并對效率進(jìn)行記錄, 具體結(jié)果如表1.

表1　讀寫操作效率記錄表

由以上驗證結(jié)果表可知, 在千萬級別以上的數(shù)據(jù)量, 基于MongoDB的分布式存儲機(jī)制的分頁查詢、數(shù)據(jù)插入和指定條件查詢的效率遠(yuǎn)高于Oracle數(shù)據(jù), 有的甚至提升了幾十倍. 由此可得知, 基于MongoDB數(shù)據(jù)庫的電網(wǎng)圖形多時態(tài)多級分布式存儲機(jī)制可提升電網(wǎng)GIS的應(yīng)用效率和效果.

4　結(jié)語

國家電網(wǎng)公司不斷加強(qiáng)電網(wǎng)設(shè)備狀態(tài)檢修管理, 實現(xiàn)設(shè)備管理向電網(wǎng)管理, 不斷推進(jìn)“多時態(tài)的統(tǒng)一電網(wǎng)”[4], 但基于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在性能上有一定的效率瓶頸. 本文基于MongoDB非關(guān)系型數(shù)據(jù)庫的實現(xiàn)多時態(tài)多級的圖形管理機(jī)制, 同時與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的效率進(jìn)行對比, 結(jié)果表明非結(jié)構(gòu)化數(shù)據(jù)庫MongoDB在提升海量圖形數(shù)據(jù)的處理效率上有很高的應(yīng)用價值, 同時可將其應(yīng)用在其它領(lǐng)域. 本文通過圖形數(shù)據(jù)管理的Mongo應(yīng)用提升專題圖圖形版本管理和應(yīng)用效果, 對支撐調(diào)度、營銷和運(yùn)檢的實際業(yè)務(wù)有重大意義.

1 劉茂華.時態(tài)-基礎(chǔ)地理信息數(shù)據(jù)庫的版本化管理[碩士學(xué)位論文].阜新:遼寧工程技術(shù)大學(xué),2005.

2 張華強(qiáng).關(guān)系型數(shù)據(jù)庫與NoSQL數(shù)據(jù)庫.電腦知識與技術(shù),2011,41(20):25–27.

3 霍多羅夫,迪洛爾夫,程顯峰.MongoDB權(quán)威指南.北京:北京郵電出版社,2011.

4 吳淑瑋.多時態(tài)統(tǒng)一電網(wǎng)模型.計算機(jī)系統(tǒng)應(yīng)用,2015,24(2): 244–247.

Management Mechanism of Power Grid Graphics Based on MongoDB

ZHAO Yue1, LI Pei1, WANG Zhen2, ZHANG Sheng-Zhen2

1(State Grid Yangzhou Power Supply Company, Yangzhou 225000, China)2(Xiamen Great Power GEO Information Technology Co. Ltd., Xiamen 361008, China)

State Grid Corp is promoting the construction of the whole life cycle management system. It takes Grid GIS graphics as the information of the power grid. In order to achieve the whole process management of the grid’s transaction information, multi temporal and multilevel management mechanism of power grid graphics based on MongoDB non relational database is introduced. The efficiency of data reading and writing is improved. Ultimately it meets the requirements of mass data information applications in the power grid.

grid graphics; multi temporal and multilevel; distributed and slicing; MongoDB

2015-09-28;

2016-06-25

[10.15888/j.cnki.csa.005312]