基于倒排索引的鐵道供電集群監(jiān)控H-CRQ技術

屈志堅，范明明，趙 亮,朱 丹，孫旭兵，王子瀟

(1.華東交通大學 電氣與自動化工程學院，江西 南昌 330013; 2. 常州市軌道交通發(fā)展有限公司，江蘇 常州 213000)

隨著我國高速鐵路規(guī)模越來越大，牽引供電系統(tǒng)、鐵路電力系統(tǒng)、鐵路通信信號電源和接觸網隔離開關等四電設備的綜合調度監(jiān)控，已逐步應用于高速客運專線供電系統(tǒng)所有重要高、低壓回路，納入近全景采集的鐵路配電網、牽引變電網及接觸網等各類測控終端和監(jiān)控線路中，使鐵路供電綜合調度監(jiān)測系統(tǒng)采集信息呈指數(shù)級增長[1-4]。據(jù)調研，浙贛鐵路10 kV電力調度監(jiān)控系統(tǒng)僅2個月獲取監(jiān)測數(shù)據(jù)量即達300 GB以上，按此計算，1年監(jiān)測數(shù)據(jù)量為1.8 TB，以服役期15年算，總存儲量可達27 TB，監(jiān)測數(shù)據(jù)的體量明顯超出了常規(guī)關系數(shù)據(jù)庫TB級容量限制[5]，且數(shù)據(jù)體量的增長速度遠超計算機性能的增長，在工程中須進行轉存儲處理，否則就會由于鐵路10 kV電力系統(tǒng)監(jiān)測數(shù)據(jù)體量的持續(xù)增大使系統(tǒng)響應速度達到1 min左右，而該系統(tǒng)的查詢響應時間應控制在百毫秒級。海量監(jiān)測數(shù)據(jù)一方面增加了系統(tǒng)的維護工作量，另一方面使傳統(tǒng)數(shù)據(jù)存取方式產生越來越大的延遲，千萬級以上的海量監(jiān)測數(shù)據(jù)查詢響應慢易造成調度界面卡屏，影響調度信息的實時處理，嚴重時甚至可能導致關鍵故障信息的遲報、漏報甚至丟失，威脅行車安全[6]。因此，迫切需要研究鐵路供電監(jiān)測的高效查詢響應技術，提出新的海量監(jiān)測數(shù)據(jù)的快速處理方法[7]。

現(xiàn)有針對海量監(jiān)測數(shù)據(jù)快速查詢問題的研究方法主要分為兩大類。第一類為擴展數(shù)據(jù)庫方法，具體有2種：①采用分布式磁盤數(shù)據(jù)庫技術[8]，通過將海量監(jiān)測數(shù)據(jù)存入分布式數(shù)據(jù)庫中，把數(shù)據(jù)分別存儲在不同主機磁盤上，與關系數(shù)據(jù)庫相比，可利用分布式磁盤數(shù)據(jù)庫擴展存儲海量監(jiān)測數(shù)據(jù)，但由于數(shù)據(jù)仍存儲于硬盤介質，存取實時性受到限制[9]，難以滿足海量監(jiān)測數(shù)據(jù)的快速存取需求。②采用內存數(shù)據(jù)庫技術[10]，將監(jiān)測實時數(shù)據(jù)駐留內存，獲得比關系數(shù)據(jù)庫快幾個數(shù)量級的存取速度，隨機訪問時間可達0.05 ms，約為磁盤訪問的5‰，但內存數(shù)據(jù)庫容量易受物理內存的限制，如俄羅斯Knizhnik研發(fā)的開放內存數(shù)據(jù)庫FastDB，嵌入式內存數(shù)據(jù)庫SQLite，容量均限制為100 GB以內，內存造價高，存儲空間遠小于磁盤容量，難以擴展。

鑒于高速鐵路供電數(shù)據(jù)的典型特征是集群化處理，另一類解決方法是使用集群技術，具體有2種：一種為使用Hive查詢引擎對數(shù)據(jù)預處理[11-12]，將海量監(jiān)測數(shù)據(jù)映射為數(shù)據(jù)表，并將查詢命令轉換為MapReduce操作進行批量查詢處理，但MapReduce進程的查詢啟動慢、開銷大，文獻[13]中使用Hive查詢引擎查詢千萬級數(shù)據(jù)耗時達120 s，難以滿足海量監(jiān)測數(shù)據(jù)的快速查詢要求。另一種為基于非關系型(Not only SQL,NoSQL)HBase數(shù)據(jù)庫集群，通過熱點緩存和熱點評分處理，將數(shù)據(jù)量大、出現(xiàn)頻繁的數(shù)據(jù)駐留HBase數(shù)據(jù)庫集群節(jié)點緩存，檢索時可直接從緩存中搜索結果[14-16]。但一方面，由于常規(guī)熱點緩存(Hotspot-Cache Query，H-CQ)技術通過更新關鍵詞索引緩存的時間戳，區(qū)分緩存被訪問的頻繁度，為避免同時讀寫時間戳沖突，需對數(shù)據(jù)更新操作加互斥鎖，同一時間只允許一個線程操作，須等待寫入完成才能進入查詢線程，故對多線程讀寫操作支持不夠，而牽引負荷波動幅度大且變化頻繁，間歇短時過負荷甚至超出200%，母線電壓波動超出20%，因此監(jiān)測數(shù)據(jù)的頻繁更新將使常規(guī)H-CQ技術的多線程讀寫性能受到較大影響。另一方面因HBase數(shù)據(jù)庫集群是一種以鍵值對形式存儲的數(shù)據(jù)庫，對非主行鍵索引查詢的支持不夠，難以滿足鐵路供電監(jiān)測系統(tǒng)按站所和設備編號等非主行鍵快速查詢的要求，若能利用倒排索引技術改變數(shù)據(jù)存取結構[17]，從非主行鍵進行索引定位，就可完成非主行鍵數(shù)據(jù)的快速搜索，同時，改變H-CQ技術的更新替換方法，避免緩存時間戳操作，以提高H-CQ技術的多線程讀寫性能，該研究尚未見文獻報道。

本文設計出了一種新的基于倒排二級索引結構的熱點緩存替換(Hotspot-Cache Replace Query，H-CRQ)技術，改變鐵路供電監(jiān)測數(shù)據(jù)索引結構以實現(xiàn)在鐵路供電監(jiān)測集群中進行關鍵詞查詢，并在倒排索引的熱度緩存環(huán)節(jié)中設計訪問順序編碼，通過順序編碼更新淘汰緩存數(shù)據(jù)，避免對緩存時間戳系統(tǒng)屬性操作，提高熱點緩存處理在鐵路供電監(jiān)測集群中的多線程讀寫性能。以工程實測數(shù)據(jù)進行算例測試，驗證本文所提集群監(jiān)控處理的新方法，可有效提高鐵路調度監(jiān)測海量數(shù)據(jù)查詢效率與多線程讀寫性能。

1 鐵路供電海量監(jiān)控數(shù)據(jù)索引設計

1.1 鐵路供電監(jiān)測數(shù)據(jù)采集

鐵路供電系統(tǒng)與設施是鐵路行車裝備的重要組成部分，沿線的車站、變電站、接觸網等設備裝配有大量電壓互感器、電流互感器和各類傳感器，收集了大量運行參數(shù)信息，同時測控終端的采樣頻率越來越高，使監(jiān)測數(shù)據(jù)體量越來越大，數(shù)據(jù)采集過程見圖1。

鐵路供電監(jiān)測系統(tǒng)的終端單元，如遠程控制終端(RTU)、饋線終端設備(FTU)、信號電源監(jiān)控終端(STU)、開閉所測控終端(DTU)、變壓器監(jiān)測終端(TTU)等，裝有大量傳感器和互感器，收集鐵道供電系統(tǒng)的供電設備參數(shù)、信號電源狀態(tài)、配電所變壓器運行狀況、開關設備運行參數(shù)以及報警信息等數(shù)據(jù)，通過通信網絡傳遞給通信前置機。通信前置機按統(tǒng)一標準將監(jiān)測數(shù)據(jù)解析處理后上傳至調度中心HBase海量數(shù)據(jù)庫集群，生成監(jiān)測數(shù)據(jù)的倒排索引進行存儲并運用H-CRQ技術將熱點部分存儲在分布式集群緩存中，集群調度工作站通過海量數(shù)據(jù)庫集群查詢讀取監(jiān)測數(shù)據(jù)和報警信息，對鐵路供電系統(tǒng)運行狀態(tài)進行實時監(jiān)控并調度管理，形成鐵路供電海量數(shù)據(jù)集群監(jiān)控的信息流。

圖1 鐵路供電監(jiān)控系統(tǒng)數(shù)據(jù)的采集

1.2 鐵路供電監(jiān)測數(shù)據(jù)的倒排索引結構

鐵路供電調度系統(tǒng)的主要任務是監(jiān)視整個鐵路供電系統(tǒng)的電氣設備運行狀態(tài)并調度管理，實際工程應用中存在需根據(jù)調度人員的需求查找特定數(shù)據(jù)的場景，例如在鐵路供電調度系統(tǒng)中通過采集時間和站所號查看某一時間該站所有設備的運行狀態(tài)或是通過測控終端編號查看某一測電氣設備隨時間變化的運行狀態(tài)報表，如何在海量監(jiān)測數(shù)據(jù)中快速定位數(shù)據(jù)是搜索的關鍵。圖1中鐵路供電監(jiān)測數(shù)據(jù)存入數(shù)據(jù)庫集群時會生成主行鍵Id作為惟一標識編號，而監(jiān)測數(shù)據(jù)中的測控終端編號、采樣值、采集時間、歸屬站所等屬于非主行鍵。由于HBase數(shù)據(jù)庫是一種以鍵值對形式存儲的數(shù)據(jù)，對非主行鍵查詢支持不夠，因此設計一種監(jiān)測數(shù)據(jù)的倒排索引結構。倒排索引以關鍵詞為索引核心和鏈表訪問入口，由屬性值及該屬性值所屬數(shù)據(jù)的地址組成，由于不通過數(shù)據(jù)主行鍵，而是非主行鍵關鍵詞來定位數(shù)據(jù)，所以稱為倒排索引。

倒排索引的儲存形式定義為關鍵詞及它的位置、主行鍵Id，在查詢時直接根據(jù)關鍵詞檢索，避免逐條查找數(shù)據(jù)。以鐵道供電監(jiān)測數(shù)據(jù)記錄為例，描述倒排索引設計，見圖2。包括數(shù)據(jù)主行鍵Id，鐵道供電監(jiān)控終端的采集時間Timestamp，歸屬站所Station，測控終端編號Rtu，采集對象標識Analogname以及采樣值Analogvalue。

圖2 鐵路供電監(jiān)測數(shù)據(jù)的倒排索引設計

如圖2所示，鐵道供電監(jiān)測數(shù)據(jù)記錄正序索引搜索關鍵詞時需按搜索要求逐條索引對比，對關鍵詞的搜索效率不高。重新構造的倒排索引，由監(jiān)測信息表中關鍵詞及其出現(xiàn)的位置組成，如關鍵詞“站所443”，出現(xiàn)位置為“Id:1_Station”“Id:1_Rtu”“Id:2_Station”“Id:2_Rtu”，其中“Id:1_Station”代表關鍵詞出現(xiàn)位置為主行鍵Id為1，列名為Station。這種倒排索引結構可直接根據(jù)關鍵詞索引數(shù)據(jù)位置，通過二級索引快速定位目標數(shù)據(jù)。

2 鐵道供電監(jiān)控數(shù)據(jù)的查詢

2.1 構建鐵道供電監(jiān)控數(shù)據(jù)的二級索引

在HBase數(shù)據(jù)庫分布式存儲的基礎上，利用倒排索引設計一種鐵路供電監(jiān)測數(shù)據(jù)的二級索引方法，二級索引系統(tǒng)的讀寫訪問架構見圖3。

圖3 鐵路供電海量監(jiān)測數(shù)據(jù)二級索引設計

以向鐵路調度監(jiān)測系統(tǒng)寫入如圖2所示的鐵路供電監(jiān)測數(shù)據(jù)為例，說明該架構實現(xiàn)二級索引的具體步驟，見圖3。

(1)鐵路調度監(jiān)測系統(tǒng)的二級索引查詢架構見圖3(a)，寫入數(shù)據(jù)時：

wd1：數(shù)據(jù)“Id:1，Timestamp: 2018-09-24 00:00: 00.04，Station：站所443，Rtu：站所443，Analogname：遙測16385，Analogvalue：1800.0”寫入鐵路供電調度系統(tǒng)中。

wd2：鐵路供電調度客戶端將正序監(jiān)測數(shù)據(jù)存入HBase數(shù)據(jù)庫集群。

wd3：更新HBase數(shù)據(jù)庫集群正序監(jiān)測數(shù)據(jù)，重新構造索引結構同步至倒排索引庫完成更新。

(2)讀取數(shù)據(jù)時，通過二級索引架構讀取：

rd1：在鐵路供電調度主機客戶端查詢界面中輸入所需數(shù)據(jù)關鍵詞，如“Analogname：遙測16385”等。

rd2：調度客戶端在倒排索引庫中找出“Analogname：遙測16385”的倒排索引。

rd3：調度客戶端根據(jù)所得倒排索引在集群HBase數(shù)據(jù)庫中檢索相應數(shù)據(jù)。

該架構實現(xiàn)二級索引查詢的具體步驟見圖3(b)。在調度主機查詢界面輸入數(shù)據(jù)非主行鍵關鍵詞，如“遙測16385”；鐵路供電監(jiān)測集群將接收的倒排索引查詢請求送至集群節(jié)點協(xié)調器，分發(fā)給集群節(jié)點倒排索引庫。倒排索引庫將檢索到的關鍵詞“遙測16385”相應倒排索引“Id:1_Analogname”返回監(jiān)測集群；監(jiān)測集群根據(jù)接收的倒排索引主行鍵“Id:1”發(fā)出主行鍵查詢任務給集群節(jié)點協(xié)調器，分發(fā)給集群各節(jié)點HBase數(shù)據(jù)庫中進行搜索。數(shù)據(jù)庫進行一級索引，將主行鍵“Id:1”對應的數(shù)據(jù)返回鐵路供電監(jiān)測集群和調度主機。

通過非主行鍵條件查詢快速定位所查數(shù)據(jù)主行鍵，再按主行鍵查詢到調度主機需要的數(shù)據(jù)，以實現(xiàn)非主行鍵的二級索引和快速查詢。

2.2 集群監(jiān)控數(shù)據(jù)索引緩存

由于監(jiān)測數(shù)據(jù)庫體量大，采集時間、歸屬站所、測控終端編號等關鍵詞重復度高，鐵路供電調度系統(tǒng)進行監(jiān)測和報警信息查詢時，關鍵詞查詢結果過多影響讀取速度，導致調度系統(tǒng)工作效率下降，可將這部分關鍵詞倒排索引存入鐵路供電調度集群的緩存中處理。而單臺調度主機緩存處理能力有限，所以在HBase數(shù)據(jù)庫集群中設置分布式緩存空間，實現(xiàn)多臺集群節(jié)點緩存資源的共享，緩存查詢系統(tǒng)工作流程見圖4。

圖4 緩存查詢工作流程圖

調度主機客戶端接收查詢請求，先檢查鐵路供電監(jiān)測集群管理節(jié)點緩存是否存有此關鍵詞檢索結果。若無，則由任務調度模塊將請求轉發(fā)到其余鐵路供電監(jiān)測集群節(jié)點中繼續(xù)查詢。如果檢索到相應緩存，則將查詢結果送至調度客戶端，同時更新緩存中此條記錄的相關信息。若所有集群節(jié)點均未緩存所需信息，將請求轉發(fā)至倒排索引庫中查詢。當集群倒排索引庫中未儲存相應數(shù)據(jù)時，將“無相應記錄”返回調度客戶端。當檢索到相應數(shù)據(jù)時將查詢結果送至調度客戶端，同時將查詢結果加入緩存，緩存服務器需要檢查緩存區(qū)是否存滿，若不滿則寫入緩存，否則刪除部分緩存寫入新數(shù)據(jù)。

直接按加入緩存順序刪除已有數(shù)據(jù)緩存的原生替換方法未考慮參考時間、歸屬站所、測控終端編號等重復度高的熱點關鍵詞進出緩存機制，可以通過熱點緩存技術將熱點關鍵詞駐留緩存，提高搜索效率。

3 熱點緩存的改進替換方法

3.1 熱點緩存

緩存系統(tǒng)從邏輯上包括調度層和緩存層：調度層管理調度主機與集群節(jié)點緩存及數(shù)據(jù)交換，由節(jié)點管理模塊和任務調度模塊組成；緩存層包括緩存更新模塊和緩存替換模塊，對集群緩存中數(shù)據(jù)進行更新與淘汰，緩存系統(tǒng)架構見圖5。

圖5 緩存系統(tǒng)架構

在緩存系統(tǒng)處理時，將關鍵詞查詢的倒排索引結果，如關鍵詞“站所173”位置為“Id:4_Station”，“站所427”位置為“Id:3_Rtu”，“1800.0”位置為“Id:1_Analogvalue”等儲存在緩存中。H-CQ方法儲存結構為鏈表，系統(tǒng)初始階段緩存大量空閑，記錄直接寫入緩存，按寫入順序將關鍵詞及其位置保存于緩存中。當緩存空間存滿，緩存系統(tǒng)開始根據(jù)替換方法對緩存中的記錄進行淘汰替換。

H-CQ方法以緩存歷史訪問時間進行替換，若緩存近期被訪問，則未來可能被再次訪問，緩存未被訪問的時間越長，未來再次被訪問的概率越低，當緩存空間存滿時，將未被訪問時間最久的數(shù)據(jù)淘汰，熱點緩存淘汰過程見圖6。

圖6 熱點緩存淘汰過程

以關鍵詞倒排索引查詢結果集“索引結果1”到“索引結果8”，組成鏈表式緩存存儲在集群節(jié)點的緩存中，當調度主機提交查詢申請“站所443”時，檢查緩存空間可得“索引結果9(關鍵詞：站所443，出現(xiàn)位置：Id：2_Rtu)”并未存入緩存，則將“索引結果9”保存至緩存中鏈表式緩存結構的頭部，并把尾部未被訪問時間最長的記錄“索引結果8”從緩存中刪除。當調度主機提交查詢申請“遙測16385”時，可得“索引結果4(關鍵詞：遙測16385，出現(xiàn)位置Id:4_ Analogname)”已存入緩存，則直接將“索引結果4”緩存記錄返回調度主機，再把“索引結果4”提到鏈表式緩存結構的頭部，其余數(shù)據(jù)順次后移。

H-CQ方法管理更新緩存記錄的時間戳，淘汰時根據(jù)時間戳淘汰未被訪問時間最長的倒排索引記錄，保留被訪問可能性較高的記錄。但為避免同時讀寫時間戳沖突，同一時間只允許一個線程對時間戳操作，對讀寫操作加互斥鎖，故H-CQ方法對多線程讀寫的支持不夠。

3.2 改進緩存淘汰策略及命中率

在工程應用中，鐵路供電監(jiān)測數(shù)據(jù)實時寫入，若緩存系統(tǒng)僅支持單線程讀寫將嚴重影響讀寫效率，因此設計了一種新的熱點緩存的淘汰策略，對H-CQ方法進行改進。改進的H-CRQ方法為每個緩存記錄添加一個順序編碼AccessNum，表示訪問順序號，通過順序編碼管理更新緩存，避免對時間戳系統(tǒng)屬性進行操作，提高H-CQ方法的多線程讀寫能力。同時設計一個自增型整數(shù)變量X，新增或訪問緩存記錄時將X賦值給AccessNum并不斷自增。

改進的H-CRQ方法先設定期望保存的緩存記錄數(shù)為KeepNum，期望刪除的緩存記錄數(shù)為RemoveNum，Xmax為變量X當前的值，Xmin為遍歷緩存后記錄中AccessNum的最小值。緩存更新時，遍歷關鍵詞索引緩存，對AccessNum進行討論：

(1)若某一倒排緩存記錄的AccessNum

(2)若某一倒排緩存記錄的AccessNum>Xmax+KeepNum，表示該緩存記錄在近期被訪問過，保留符合此條件的緩存；

(3)對于Xmin+RemoveNum≤AccessNum≤Xmax+KeepNum的緩存記錄，若一次遍歷直接將緩存記錄數(shù)量降到了KeepNum，則完成淘汰過程；若仍需繼續(xù)淘汰關鍵詞索引緩存，則對符合此條件的緩存重新遍歷。如此反復淘汰，可使緩存容量降至KeepNum。

3.3 H-CRQ方法的命中率

緩存空間的大小L為鏈表長度，即關鍵詞索引緩存記錄從鏈表頭部到尾部被淘汰的替換次數(shù)，可反映緩存替換方法的更新速度。緩存記錄被放入緩存后若在被淘汰前被再次訪問視為緩存被命中，命中率代表監(jiān)測數(shù)據(jù)集群進行的非主行鍵查詢時該關鍵詞索引已被緩存的概率。

因冪律分布適用于描述關鍵詞的重復度與被使用頻率的關系，所以關鍵詞被查詢的次數(shù)分布服從冪律分布，被查詢的頻率與它重復度排名的常數(shù)次冪成反比關系

pr∝r-c

(1)

式中：pr為按重復度排名后，排序為r的關鍵詞被查詢訪問的概率；c為冪律函數(shù)的常數(shù)。

根據(jù)熱點緩存方法的替換策略，將按重復度排名后，排序為r的關鍵詞索引結果緩存記錄于緩存空間的概率，表示為

(2)

由于緩存空間包含有L個關鍵詞索引結果緩存，令改進熱點緩存算法的命中率為P，可得到命中率P的計算式

(3)

由于泊松分布用于描述單位時間內隨機事件發(fā)生的次數(shù)，故關鍵詞單位時間內被多次訪問的概率服從泊松分布，由此可得排序為r的關鍵詞單位時間內查詢k次的概率Pt為

(4)

結合式(3)、式(4)可得，單位時間內排序為r的關鍵詞被查詢k次的命中率P′為

P′(Xr=k)=PtP=

(5)

從式(5)可得，緩存空間的大小L對熱點緩存算法的命中率P′有影響，呈正相關的關系。但根據(jù)最近最小使用原則，熱點緩存容量一般設置為當前可用內存容量的1/8，緩存空間設置過大會影響計算機處理性能，導致查詢的實時性下降。

4 實驗與結果分析

4.1 搭建測試集群

以天水—蘭州鐵路10 kV供電監(jiān)測系統(tǒng)導出的實測工程數(shù)據(jù)為算例，其供電示意圖見圖7。

圖7 鐵道供電監(jiān)測系統(tǒng)算例示意圖

根據(jù)鐵路供電監(jiān)測系統(tǒng)工程中的典型調度監(jiān)測主站配置，設置2臺數(shù)據(jù)服務器和2臺主、備調度工作站搭建集群，在CentOS 6.8系統(tǒng)環(huán)境下，部署1個主節(jié)點和3個工作節(jié)點的鐵路供電監(jiān)測數(shù)據(jù)非主行鍵查詢集群，集群環(huán)境參數(shù)見表1。

以遙測數(shù)據(jù)的采集時間Timestamp，歸屬站所Station，測控終端編號Rtu，采集對象標識Analogname以及采樣值Analogvalue進行測試，對非主行鍵數(shù)據(jù)建立二級索引，測試設置緩存大小L對集群監(jiān)控查詢性能的影響及H-CRQ方法的查詢性能。

表1 鐵路供電監(jiān)測數(shù)據(jù)非主行鍵查詢集群環(huán)境

4.2 緩存空間對查詢性能影響測試

使用鐵路供電監(jiān)測數(shù)據(jù)非主行鍵查詢集群，分別在一主一備模式和鐵路供電監(jiān)測“四機集群+查詢測試機”模式下，導入1.6×109條鐵路10 kV供電監(jiān)測數(shù)據(jù)記錄，并持續(xù)向集群數(shù)據(jù)庫中更新監(jiān)測數(shù)據(jù)，測試不使用緩存的掃描查詢、H-CQ緩存查詢和H-CRQ緩存查詢在不同緩存空間大小情況下，查詢相同關鍵詞的查詢性能，結果見圖8。

圖8 不同緩存大小時的查詢性能對比

如圖8所示，緩存空間過大時會對H-CQ緩存查詢和H-CRQ緩存查詢的性能造成影響。在鐵路供電監(jiān)測集群分布模式下，緩存中每個關鍵詞出現(xiàn)位置平均為17個字節(jié)，每條緩存記錄可返回查詢結果集記錄平均為10 000條，約占166 kB。若緩存記錄條數(shù)設置為15 000條，緩存空間約占用2.37 GB，占集群總內存的12%，接近最近最小使用原則設置的當前可用內存1/8，因此當緩存空間設置小于15 000條時，不會對集群運行產生影響，H-CQ緩存查詢和H-CRQ緩存查詢性能均優(yōu)于原生查詢。而當緩存記錄條數(shù)為18 000條時，緩存空間約占2.85 GB，占集群總內存的14%，超過了當前可用內存的1/8，對集群性能產生影響，查詢處理的實時性降低，緩存查詢耗時明顯增加。

根據(jù)式(5)可得，緩存空間記錄條數(shù)L與緩存查詢的命中率P′呈正相關關系，而命中率P′越高，鐵路供電監(jiān)測數(shù)據(jù)集群進行非主行鍵查詢時進行緩存查詢的概率越大。則可得L設置越大，鐵路供電監(jiān)測數(shù)據(jù)集群進行緩存查詢的概率越大。但緩存空間設置過大會影響集群工作性能，將給緩存查詢處理帶來一定的延時。

綜上表明，并不能一味靠增加緩存空間大小達到增加鐵路供電監(jiān)測數(shù)據(jù)集群進行緩存查詢的概率，提高查詢效率的目的。在集群中根據(jù)可用內存合理設置緩存空間記錄條數(shù)，可增加緩存查詢命中率P′且不會對鐵路供電監(jiān)測數(shù)據(jù)集群運行產生影響，能有效提升鐵路供電監(jiān)測數(shù)據(jù)集群查詢效率。

4.3 查詢性能對比測試

在四機集群中分別導入5.0×108、1.0×109和1.6×109條鐵路10 kV供電監(jiān)測數(shù)據(jù)記錄，并設置緩存空間為15 000條，使用掃描查詢和H-CRQ緩存查詢對億級鐵路供電監(jiān)測數(shù)據(jù)進行關鍵詞查詢，測試H-CRQ方法對海量重復數(shù)據(jù)查詢優(yōu)化效果。然后分別使用H-CQ緩存查詢、H-CRQ緩存查詢進行查詢測試，對比多線程讀寫的情況下2種緩存算法的查詢性能。

(1)關鍵詞二級索引查詢測試

在鐵路供電監(jiān)測數(shù)據(jù)集群正常運行情況下，以1.6×109條算例監(jiān)測數(shù)據(jù)記錄為輸入，對關鍵詞進行查詢，關鍵詞二級索引查詢結構見圖9。

圖9 關鍵詞查詢結構

(2)H-CRQ緩存查詢與掃描查詢性能對比

在鐵路供電監(jiān)測數(shù)據(jù)集群正常運行情況下，分別以5.0×108、1.0×109和1.6×109條算例監(jiān)測數(shù)據(jù)記錄為輸入，使用掃描查詢與H-CRQ緩存查詢對不同重復度的關鍵詞數(shù)據(jù)進行查詢性能測試，測試結果見圖10。

圖10 不同重復度的非主行鍵查詢性能對比

由圖10可得，非主行鍵二級索引查詢返回結果集大小對原生非主行鍵查詢性能有很大影響。如導入1.6×109條監(jiān)測數(shù)據(jù)記錄，當查詢結果集記錄條數(shù)為1 355條時，掃描查詢與H-CRQ緩存查詢性能無明顯差距，耗時均為160 ms左右。但當查詢結果集記錄條數(shù)達萬級以上時，掃描查詢耗時明顯增加，如查詢結果集為209 745條記錄時，掃描查詢耗時312 ms，而H-CRQ緩存查詢耗時182 ms。綜上表明，H-CRQ緩存查詢可以改善鐵路供電監(jiān)測數(shù)據(jù)非主行鍵查詢集群中海量數(shù)據(jù)非主行鍵的查詢性能，對重復度達20萬條記錄以上的數(shù)據(jù)記錄，查詢性能提高了42%。

(3)多線程讀寫情況下查詢性能對比

在鐵路供電監(jiān)測數(shù)據(jù)集群正常運行情況下，分別以5.0×108、1.0×109和1.6×109條算例監(jiān)測數(shù)據(jù)記錄為輸入，并持續(xù)向集群數(shù)據(jù)庫中更新監(jiān)測數(shù)據(jù)，同時使用H-CQ緩存查詢和H-CRQ緩存查詢對不同重復度的關鍵詞數(shù)據(jù)進行查詢性能測試，測試結果見圖11。

圖11 多線程讀寫下H-CQ與H-CRQ查詢性能對比

由圖11可知，多線程讀寫情況下，鐵路供電監(jiān)測數(shù)據(jù)寫入對H-CQ緩存查詢性能有一定影響，H-CQ緩存查詢讀取數(shù)據(jù)時，H-CQ方法對數(shù)據(jù)庫更新操作加互斥鎖，需等待寫入進程結束后開始查詢讀取數(shù)據(jù)。等待寫入操作時間不同，鐵路供電監(jiān)測數(shù)據(jù)寫入對H-CQ緩存查詢性能有不同程度的影響，而H-CRQ緩存查詢的性能并未被數(shù)據(jù)寫入操作影響，查詢時間均少于H-CQ緩存查詢。在寫入進程影響下，導入1.6×109條監(jiān)測數(shù)據(jù)記錄，H-CQ緩存查詢結果為209 745條的查詢操作比H-CRQ緩存查詢耗時多31 ms。表明H-CRQ緩存查詢在多線程讀寫情況下查詢性能優(yōu)于H-CQ緩存查詢，對重復度達20萬條記錄以上的數(shù)據(jù)記錄，查詢性能比H-CQ查詢高15%。

5 結論

(1)利用倒排二級索引和動態(tài)緩存機制，提出一種鐵道供電綜合監(jiān)控海量數(shù)據(jù)的H-CRQ集群處理方法。將監(jiān)控數(shù)據(jù)結構改變?yōu)榈古潘饕Y構，查詢直接根據(jù)特定關鍵詞檢索，并將倒排索引查詢結果儲存在緩存中，設計H-CRQ方法對緩存進行更新替換。通過四機鐵路供電監(jiān)測數(shù)據(jù)集群的非主行鍵查詢測試比較，驗證了H-CRQ緩存查詢可有效提高鐵路供電監(jiān)測集群海量重復數(shù)據(jù)查詢效率。

(2)以鐵道供電實測監(jiān)控信息數(shù)據(jù)為算例，進行多組非主行鍵查詢響應測試。結果表明，緩存空間大小設置不超過當前可用內存的1/8時，H-CRQ查詢可有效提高鐵路供電監(jiān)測集群海量重復數(shù)據(jù)查詢效率，對重復度達20萬條記錄以上的數(shù)據(jù)記錄，查詢性能比全掃描查詢高42%，且在鐵路供電監(jiān)測數(shù)據(jù)不斷寫入情況下，查詢性能比H-CQ查詢高15%。