電網圖形數據管理MongoDB數據庫的應用①

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

?

電網圖形數據管理MongoDB數據庫的應用①

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

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

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

電網圖形; 多時態多級; 分布式及分片; MongoDB

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

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

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

1　多時態多級圖形管理機制

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

電網圖形從規劃設計、基建、運行的整個過程實時跟蹤, 記錄不同時刻的電網狀態變化, 滿足了各業務部門甚至不同業務人員特定圖形應用需求, 并實現了整個電網異動的全過程管理. 具體管理機制如下:

圖1　多時態多級管理機制

根據電網的設計、建設和運行分別對應一個時態集, 每個時態集合分別有一個基準線, 在基準版本上進行迭代更新演化, 同時只支持時態的推進不支持回退, 即規劃設計的最后一個基準版本演化成建設的基準版, 建設的最后一個基準版本演化成運行態的基準版. 同時在同一時態內, 如在設計態基準線中, 基準版與基準版1和基準版2的轉化方式如下所示:

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

同時, 在運行態支持不同業務人員對圖形版本的個性設置, 實現多級的管理方式. 該展示方式是基于當前運行基準版本進行個性化選擇展示的.

然而, 隨著電網的不斷發展與壯大, 電網設備數量特別是配網設備呈指數級增長, 如江蘇電網的圖形數據量以億計, 如何在高效快速地實現圖形相關功能滿足用戶的體驗需求是亟需解決的問題. 故本文進行了非結構化數據庫技術的應用探索.

圖2　同一時態下圖形版本轉化

2　基于MongoDB的分布式存儲設計

2.1 非關系型數據庫

傳統關系型數據庫具有高穩定性、使用簡單, 功能強大等優點[2], 隨著智能電網的建設, 電網數據以億計, 隨著“大數據”技術的應用不斷深入, 對海量數據的分析與應用需求不斷加深, 然而傳統的關系型數據庫難以提供超大規模的數據存儲以及高并發高速讀寫訪問能力.

隨著技術的發展, NoSQL數據庫應運而生, 其不需要固定的表結構, 通常也不存在連接操作. 采用key-Value存儲、文檔型、xml等方式存儲數據模型. 其具有易擴展性、大數據量高性能、靈活的數據模型等優點. 而MongoDB作為非關系型數據庫的典型代表, 其支持自動分片且可以水平方向的數據庫集群; 同時支持豐富的查詢表達式, 可支持查詢文檔中內嵌的對象及數組, 該特性在拓撲追溯分析時非常重要; 其還具備全索引等優點. 本項目選取MongoDB作為應用的數據庫.

2.2 架構設計

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

2.2.1分布式存儲框架

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

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

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

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

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

2.2.2分片存儲方式

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

圖4 分片存儲架構

2.3 存儲設計

本管理機制主要涉及版本數據管理、圖檔數據結構以及設備關系結構三個大的方面, 下面重點介紹這些數據的存儲設計.

2.3.1版本數據結構設計

通過實現對版本的遞歸轉化以及同時態的多級管理, 實現不同人員對專題圖的不同需求以及版本的全過程管理. 結構形式如下:

{

TreeId //樹節點編號, 數字

Code //節點對應編碼(如饋線ID), 字符串

VersionId //版本編碼, 字符串

VersionName //版本名稱, 字符串

VersionType //版本類型, 字符串

VersionCode //版本編碼, 字符串

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

CreateTime //版本創建時間, 字符串

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

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

SchematicType //圖紙類型, 字符串

VersionState //版本狀態, 圖檔狀態

CoordinateOrigin //坐標原點, 嵌套

{

x //坐標點, 數字

y //坐標點, 數字

}

}

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

{

VersionId:"10000001",

TreeId:"10102010101",

Code:"321002001001",

VersionType:"規劃圖紙",--規劃圖紙, 設計圖紙, 運行圖紙

VersionName:"規劃圖紙單線圖未發布版本v003",

VersionCode:"v003",

UserName:"規劃人員",

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

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

DataSource:"PMS",--PMS,GIS

SchematicType:"單線圖",--單線圖, 網絡圖, 沿布圖

VersionState:"未發布",

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

}

2.3.2圖檔數據結構設計

圖檔數據存儲結構是存儲機制的一個重點, 具體存儲結構如下:

{

VersionId //版本編號, 字符串

GisFeatureType //設備類型(點, 線, 面, 標注), 字符串

Fid //設備唯一編碼, 字符串

Fno //設備類型編碼, 字符串

FeatureFid //設備臺賬ID, 字符串

FeederFid //設備所屬饋線FID, 字符串

OwnerFeatureFid //設備從屬設備FID, 字符串

IsContact //是否聯絡設備, 布爾值

ModifyStatus //設備修改狀態, 字符串

RoleId

ShapeComponents:[ //設備組件,嵌套ShapeComponent

{

GisFeatureFid //設備FID, 字符串

GisFeatureFno //設備FNO, 字符串

Angle //角度, 數字

SymbolSid //組件樣式ID,數字

SchematicPoints:[ //坐標集, 嵌套

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

{x:12.23423424,y:114:2423442343}

],

ShapeComponentType //組件類型, 字符串

}

],

LabelComponents:[//設備標注,嵌套LabelComponent

{

GisFeatureFid: //設備FID, 字符串

GisFeatureFno://設備FNO, 字符串

Angle: //角度, 數字

SymbolSid: //組件樣式ID,數字

SchematicPoints:[//坐標集, 嵌套point

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

{x:12.23423424,y:114:2423442343}

],

ShapeComponentType //組件類型, 字符串

SymbolText //標注內容, 字符串

TextStyle:{ //標注樣式, 嵌套TextStyle

FontFamily //字體名稱, 字符串

FontSize //字體大小, 數字

Fill //字體顏色, 字符串

}

}

],

GisAttribute:{ GisAttribute//設備的功能屬性, 嵌套

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

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

KGBH //運行編號, 字符串

Length //長度, 數字

EleStatus //帶點狀態, 字符串

Basevoltage//基級電壓, 字符串

Zone //所屬區域, 字符串

Normalopen //開關狀態, 字符串

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

YYHH //字符串

Rates //字符串

Pfixed //電壓等級

UserType //字符串

OperatingCapacity //工作效率

LineModel //線模型

LineLength //線長

}

}

2.3.3設備關系存儲結構

{

Fid //設備ID, 字符串

RelationShipFid//拓撲對應的設備ID, 字符串

VersionId //版本ID, 字符串

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

},

{

PrimaryFid //主設備Fid, 字符串

ThroughFid //經過的設備, 字符串

AccessoryFid //附屬設備, 字符串

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

VersionId //版本ID, 字符串

}

通過以上的存儲設計, 同時通過設計、建設和運行態的管理機制, 實現圖形多級多時態管理.

3　與關系型數據庫效率對比

基于本存儲機制進行存儲效率驗證, 通過基于MongoDB數據庫的電網圖形多時態多級的分布式存儲機制進行千萬級數據效率測試, 同時對比傳統關系型數據庫Oracle的讀寫效率.

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

① 基于27000000數量級數據, 由于存儲結構形式不同, 數量上略有百條數據量的差別;

② 分頁查詢、插入數據以及指定查詢條件相同, 同時查詢結果也需相同.

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

表1　讀寫操作效率記錄表

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

4　結語

國家電網公司不斷加強電網設備狀態檢修管理, 實現設備管理向電網管理, 不斷推進“多時態的統一電網”[4], 但基于傳統的關系型數據庫在性能上有一定的效率瓶頸. 本文基于MongoDB非關系型數據庫的實現多時態多級的圖形管理機制, 同時與傳統的關系型數據庫的效率進行對比, 結果表明非結構化數據庫MongoDB在提升海量圖形數據的處理效率上有很高的應用價值, 同時可將其應用在其它領域. 本文通過圖形數據管理的Mongo應用提升專題圖圖形版本管理和應用效果, 對支撐調度、營銷和運檢的實際業務有重大意義.

1 劉茂華.時態-基礎地理信息數據庫的版本化管理[碩士學位論文].阜新:遼寧工程技術大學,2005.

2 張華強.關系型數據庫與NoSQL數據庫.電腦知識與技術,2011,41(20):25–27.

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

4 吳淑瑋.多時態統一電網模型.計算機系統應用,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]