趙德基　狄軍峰

摘要：將現(xiàn)有的運檢管理業(yè)務(wù)系統(tǒng)與NoSQL技術(shù)進(jìn)行結(jié)合，是在互聯(lián)網(wǎng)技術(shù)不斷發(fā)展的趨勢下，傳統(tǒng)工業(yè)與大數(shù)據(jù)技術(shù)互相融合的一次探索。傳統(tǒng)的變電運檢管理系統(tǒng)由于需要接收、處理的數(shù)據(jù)量過大，系統(tǒng)的負(fù)載太大，無法對數(shù)據(jù)進(jìn)行高準(zhǔn)確率、實時、和復(fù)雜運算邏輯的處理，因此，傳統(tǒng)的系統(tǒng)無法接收大量數(shù)據(jù)，或者只能接收一些但不能存儲或分析它們。尤其地，受限于數(shù)據(jù)庫技術(shù)，變電運檢管理系統(tǒng)的功能和性能均受到了交大的限制。本文將通過對NoSQL中的MongoDB數(shù)據(jù)庫進(jìn)行研究，和傳統(tǒng)的關(guān)系型數(shù)據(jù)庫MySQL進(jìn)行對比，分析出MongoDB數(shù)據(jù)庫更加合適使用的業(yè)務(wù)場景，為現(xiàn)有的運檢管理系統(tǒng)提供改造和優(yōu)化的思路，進(jìn)而逐步的利用“大云物移”技術(shù)，實現(xiàn)國家電網(wǎng)智能運檢體系的建設(shè)。

關(guān)鍵詞：數(shù)據(jù)庫；MongoDB；MySQL；智能電網(wǎng)；變電運檢管理平臺

中圖分類號：TM76 文獻(xiàn)標(biāo)識碼：A 文章編號：1007-9416（2018）09-0023-04

隨著電網(wǎng)規(guī)模快速發(fā)展和運檢要求不斷提升，變電設(shè)備運檢工作量大幅提升。如何通過智能化手段，解決運檢工作量、質(zhì)量與運檢人員數(shù)量、人員結(jié)構(gòu)間日益突出的矛盾，成為亟需解決的問題。自2011年以來，圍繞運檢工作開發(fā)的生產(chǎn)信息系統(tǒng)和設(shè)備運維管理系統(tǒng)，一定程度上緩解了運檢工作中的突出矛盾；但已有的管理系統(tǒng)側(cè)重于運檢基礎(chǔ)工作管理，無論從系統(tǒng)構(gòu)架、功能、數(shù)據(jù)接口方面都無法適應(yīng)第三代智能站的需求。

其中，受限于傳統(tǒng)的數(shù)據(jù)存儲技術(shù)，現(xiàn)有運檢管理系統(tǒng)的功能和性能均受到了交大的限制。設(shè)備運行歷史數(shù)據(jù)和復(fù)雜分析數(shù)據(jù)都無法進(jìn)行有效保存，致使大量有分析價值的數(shù)據(jù)無法得到充分利用，進(jìn)而造成現(xiàn)有運檢管理系統(tǒng)無法對設(shè)備運行趨勢、狀態(tài)特征、故障預(yù)警等進(jìn)行有效的分析，大大影響了運檢效率。

因此，本文研究了當(dāng)今大數(shù)據(jù)時代的數(shù)據(jù)存儲與傳統(tǒng)運檢領(lǐng)域信息化系統(tǒng)的數(shù)據(jù)存儲技術(shù)的對比，通過大數(shù)據(jù)存儲技術(shù)的介入，加快運檢工作面向第三代智能變電站的變電運檢管理平臺建設(shè)，提高運檢效率。

1 關(guān)系型數(shù)據(jù)庫和NOSQL的特點

隨著大規(guī)?；ヂ?lián)網(wǎng)應(yīng)用的不斷發(fā)展以及云計算所需的海量存儲和高速計算的發(fā)展，傳統(tǒng)的關(guān)系數(shù)據(jù)庫已無法滿足這一需求。NoSQL數(shù)據(jù)庫的不斷發(fā)展和成熟可以更好地解決大容量存儲和大規(guī)模計算的應(yīng)用需求。NoSQL指的是非關(guān)系數(shù)據(jù)庫。MongoDB是一種NoSQL數(shù)據(jù)庫。它是一個開源，無架構(gòu)，面向文檔的分布式數(shù)據(jù)庫。它是關(guān)系數(shù)據(jù)庫和非關(guān)系數(shù)據(jù)庫之間的產(chǎn)品。本文將使用MongoDB作為數(shù)據(jù)存儲性能研究的代表。

非關(guān)系型數(shù)據(jù)庫的特點和優(yōu)勢：

（1）性能：NOSQL基于鍵值對，不需要由SQL層解析，可以想象為主鍵和表中的值之間的對應(yīng)關(guān)系，因此具有非常高的性能。

（2）可擴展性：另外，由于基于鍵值對的數(shù)據(jù)之間沒有耦合，因此水平擴展非常容易。

關(guān)系型數(shù)據(jù)庫的特點和優(yōu)勢：

（1）支持復(fù)雜查詢：可以使用SQL語句輕松地在表和多個表之間執(zhí)行非常復(fù)雜的數(shù)據(jù)查詢。

（2）支持事物（transaction）：非關(guān)系型數(shù)據(jù)庫對事務(wù)的支持實現(xiàn)了對安全性的高數(shù)據(jù)訪問要求

可以看出，對于這兩種類型的數(shù)據(jù)庫，另一方的優(yōu)勢是他們自己的弱點。近年來這兩個數(shù)據(jù)庫都朝著另一個方向發(fā)展，但這些特征的增加也將削弱其固有優(yōu)勢。因此，如何構(gòu)建系統(tǒng)的短期和長期存儲策略，并利用各自的優(yōu)勢是架構(gòu)師需要考慮的重要問題。

本文將MySQL作為關(guān)系型數(shù)據(jù)庫的代表，與非關(guān)系型數(shù)據(jù)庫MongoDB進(jìn)行特點及性能的對比。

1.1 MongoDB的存儲特點

MongoDB采用類JSON的documents來存儲數(shù)據(jù)。在mongoDB的查詢語句中，相關(guān)信息由于可以采用靈活的數(shù)據(jù)結(jié)構(gòu)存儲在一塊，所以查詢速率非?？?。當(dāng)mongoDB需要更新文檔documents的時候，可以輕松增加新的字段名或者刪除舊的字段。

MongoDB會在啟動后將數(shù)據(jù)庫中的數(shù)據(jù)作為文件加載到內(nèi)存中。如果內(nèi)存資源非常豐富，這將大大提高數(shù)據(jù)庫的查詢速度。

1.2 MongoDB的缺陷

作為新產(chǎn)品，MongoDB也有許多缺點。雖然它為開發(fā)人員提供了便利，但在操作和維護(hù)方面面臨許多困難，沒有成熟的操作和維護(hù)經(jīng)驗，需要不斷探索。MongoDB中的數(shù)據(jù)存儲是非常隨意的，與開始時定義的MySQL不同。對于操作和維護(hù)人員，MongoDB內(nèi)部數(shù)據(jù)的數(shù)據(jù)格式會給數(shù)據(jù)庫的操作和維護(hù)帶來麻煩。

MongoDB和MySQL是兩種不同類型的數(shù)據(jù)庫。當(dāng)存儲越來越多的記錄時，插入和讀取效率將如何受到影響，這是本研究的重點。

2 測試系統(tǒng)組成

在這一部分，我們模擬變電運維業(yè)務(wù)中的場景。當(dāng)管理平臺接入所轄區(qū)域內(nèi)的多個變電站時，平臺需要對數(shù)量眾多的主輔設(shè)備信息進(jìn)行處理，系統(tǒng)將面臨非常大的數(shù)據(jù)上送的壓力，因此數(shù)據(jù)庫會受到頻繁讀寫操作的巨大壓力。我們準(zhǔn)備了1億條待測試數(shù)據(jù)，數(shù)據(jù)格式模擬變電運維實際業(yè)務(wù)，字段共有30個字段（不逐一列出），大致如Table1。我們會選用MongoDB數(shù)據(jù)庫和MySQL數(shù)據(jù)庫分別測試數(shù)據(jù)插入性能和數(shù)據(jù)讀取性能。如表1、2所示。

3 性能對比

在存儲在數(shù)據(jù)庫中的數(shù)據(jù)中，有一個稱為主鍵的特殊鍵，用于唯一標(biāo)識表中的記錄。即表不能有多個主鍵，主鍵不能為空。無論是MongoDB還是MySQL，都有主鍵的定義。對于MongoDB，主鍵名稱為“_id”。生成數(shù)據(jù)時，如果用戶沒有主動為其分配主鍵，MongoDB將自動為其生成隨機分配的值。在MySQL中，當(dāng)MySQL插入數(shù)據(jù)時，通過指定PRIMARYKEY來指定主鍵。如果未指定主鍵，則另一個工具（索引）等效于主鍵的功能。如果既未指定主鍵也未指定索引，MySQL將自動為數(shù)據(jù)創(chuàng)建數(shù)據(jù)。

3.1 研究過程

此次研究過程有如下步驟：

（1）為數(shù)據(jù)庫表條目創(chuàng)建字段模板，并根據(jù)此模板將數(shù)據(jù)插入數(shù)據(jù)庫。

（2）將準(zhǔn)備好的1億條待測試數(shù)據(jù)執(zhí)行插入操作。每條數(shù)據(jù)的大小大概有1K。要測試的數(shù)據(jù)格式的關(guān)鍵字段之一是各不相同的md5值1-100，000，000，剩余字段的內(nèi)容，按照變電運檢業(yè)務(wù)實際情況進(jìn)行補充。

（3）以下列四種模式將數(shù)據(jù)插入數(shù)據(jù)庫。插入每1000個數(shù)據(jù)后，記錄所用時間：

1）在MongoDB中插入數(shù)據(jù)，其md5值對應(yīng)到_id為1-100，000，000。

2）不指定MongoDB中的主鍵值，將md5值1-100，000，000視為普通字段插入。

3）在MySQL中插入數(shù)據(jù)，md5值為1-100，000，000，將其作為主鍵。

4）不要在MySQL中指定主鍵，將md5值視為1-100，000，000作為正常的字段插入。

（4）根據(jù)記錄的時間，對比MySQL和MongoDB的插入性能。

（5）此外，基于上述四種描述，分別測試數(shù)據(jù)庫的讀取性能。

3.2 插入性能對比

按照第四章的測試步驟插入數(shù)據(jù)得到以下結(jié)果。

圖1上的數(shù)據(jù)橫坐標(biāo)是以上描的四種插入方式對應(yīng)的數(shù)據(jù)庫類型；縱坐標(biāo)是插入平均1000個數(shù)據(jù)所需的時間。單位是秒。

結(jié)果分析：

（1）指定主鍵時，兩個數(shù)據(jù)庫將在插入時處理索引值，并在數(shù)據(jù)庫中查找相同的鍵值，這將降低插入速率。

（2）使用MongoDB時，指定索引的插入操作比不指定索引要慢得多。因為MongoDB中每個數(shù)據(jù)的_id值是唯一的。在未指定_id的情況下插入數(shù)據(jù)時，系統(tǒng)會使用計算機時間、特征值、進(jìn)程號和randomnumber來確保生成唯一_id。指定主鍵插入數(shù)據(jù)時，MongoDB需要檢查此_id是否不適用于每個數(shù)據(jù)。當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)量太大時，此步驟的查詢開銷將降低整個數(shù)據(jù)庫的插入速度。

（3）MongoDB有一個非常好的功能：將充分利用系統(tǒng)內(nèi)存作為緩存。測試機器有64G的內(nèi)存。插入數(shù)據(jù)后，MongoDB會在數(shù)據(jù)寫入內(nèi)存后盡快將數(shù)據(jù)保存到硬盤中。這就是為什么MongoDB在未指定_id時遙遙領(lǐng)先。但是，當(dāng)通過指定_id模式插入數(shù)據(jù)時，當(dāng)數(shù)據(jù)量很大時，MongoDB需要將磁盤中的信息讀入內(nèi)存來檢查權(quán)重，這樣插入效率會很慢。

（4）無論是指定主鍵還是未指定插入數(shù)據(jù)的主鍵，MySQL效率都沒有太大差異。

3.3 查詢性能對比

接下來我們測試MongoDB和MySQL在數(shù)據(jù)查詢時的性能對比。我們預(yù)期數(shù)據(jù)量的查詢基本可以滿足運檢管理系統(tǒng)的業(yè)務(wù)量。同樣，我們把每查詢1000條數(shù)據(jù)的時間記錄下來。

測試結(jié)果：如表3所示。

本案例簡單數(shù)據(jù)模型下時間范圍內(nèi)的等值查詢應(yīng)用場景下，MongoDB在高并發(fā)條件下的大數(shù)據(jù)量查詢性能并沒有比MySQL更好。另外還有一點需要注意的是，在本案例中，數(shù)據(jù)總量由百萬級別到千萬級別再到億級別的變化過程中，對于查詢性能的影響都不是很大，但對于查詢數(shù)據(jù)量的數(shù)倍增長卻十分敏感。

4 結(jié)語

經(jīng)過以上章節(jié)的測試對比，我們得到以下結(jié)論：

（1）相比較MySQL，MongoDB側(cè)重頻繁數(shù)據(jù)寫入的性能，適合業(yè)務(wù)系統(tǒng)中有大量數(shù)據(jù)接入的場景，符合變電運檢管理系統(tǒng)中變電站主輔設(shè)備大量數(shù)據(jù)上送的場景。如果機器的內(nèi)存資源豐富，MongoDB充分利用內(nèi)存資源，插入效率將會很高。

（2）使用“_id”插入數(shù)據(jù)時，MongoDB的插入效率實際上并不高。如果要充分利用MongoDB性能，建議不要使用“_id”插入方法。在設(shè)計系統(tǒng)和功能時，您需要專注于數(shù)據(jù)庫的選擇。在設(shè)計系統(tǒng)和功能時需要側(cè)重考慮數(shù)據(jù)庫的選型。

（3）在千萬級別的查詢上，MongoDB在高并發(fā)條件下的大數(shù)據(jù)量查詢性能并沒有比MySQL更好。

經(jīng)過對MongoDB和MySQL的插入性能和查詢性能的對比，能夠發(fā)現(xiàn)兩者在不同的場景下性能有所側(cè)重。我們可以根據(jù)不同的業(yè)務(wù)需要，選擇相應(yīng)的數(shù)據(jù)庫。并且應(yīng)基于不同數(shù)據(jù)庫的特性，設(shè)計系統(tǒng)的功能，以達(dá)到對數(shù)據(jù)庫的充分利用，將數(shù)據(jù)庫的性能達(dá)到最優(yōu)化。

此次測試只是使用單體數(shù)據(jù)庫進(jìn)行測試，nosql數(shù)據(jù)庫絕不僅僅用于插入和查詢，后續(xù)可以將NoSQL的水平擴展能力、動態(tài)增列特性、副本集機制結(jié)合變電運檢業(yè)務(wù)進(jìn)行研究，發(fā)掘出NoSQL更多適應(yīng)于運檢業(yè)務(wù)場景的技術(shù)優(yōu)勢。

參考文獻(xiàn)

[1]Ming Wang， Qian Zhang， The constrction of E-business： a case study. Journal of Peiking University， Vol 243， pp.102-103， April 2003 （In Chinese）.

[2]G. Eason， B. Noble， and I. N. Sneddon， “On certain integrals of Lipschitz-Hankel type involving products of Bessel functions，” Phil. Trans. Roy. Soc. London， vol. A247， pp. 529-551， April 1955. （references）

[3]J. Clerk Maxwell， A Treatise on Electricity and Magnetism， 3rd ed.， vol. 2. Oxford： Clarendon， 1892， pp.68-73.

[4]I. S. Jacobs and C. P. Bean， “Fine particles， thin films and exchange anisotropy，” in Magnetism， vol. III， G. T. Rado and H. Suhl， Eds. New York： Academic， 1963， pp. 271-350.

[5]K. Elissa， “Title of paper if known，” unpublished.

[6]R. Nicole， “Title of paper with only first word capitalized，” J. Name Stand. Abbrev.， in press.

[7]Y. Yorozu， M. Hirano， K. Oka， and Y. Tagawa，“Electron spectroscopy studies on magneto-optical media and plastic substrate interface，” IEEE Transl. J. Magn. Japan， vol. 2， pp. 740-741， August 1987 [Digests 9th Annual Conf. Magnetics Japan， p. 301，1982].

[8]M. Young， The Technical Writer's Handbook. Mill Valley， CA： University Science， 1989.