基于MongoDB的HIAF Archive Engine設計與實現

馬 濤，岳 敏，袁 超，茍世哲，王永平，張 瑋

(中國科學院 近代物理研究所，甘肅 蘭州 730000)

強流重離子加速器裝置(HIAF)是目前在建的超導直線加速器、超導同步加速器和儲存環組合的先進重離子研究裝置。HIAF采用實驗物理和工業控制系統(EPICS)作為控制架構，目前在蘭州重離子研究裝置(HIRFL)上使用Control System Studio(CSS)提供的存儲工具作為HIRFL運行數據采集、存儲的工具[1]。在長時間的部署使用后，發現當前基于EPICS的存儲工具在HIAF或更大規模的研究裝置上使用時會存在以下不足：1) 僅支持Oracle、MySQL等關系型數據庫的存儲接口，對大數據量和多元數據格式的存儲缺乏靈活性，系統性能存在瓶頸；2) 提供的存儲模式較單一，不支持對不同子系統數據和實驗相關信息的手動存儲方式，導致歷史數據利用率低；3) 未考慮數據量累積后利用分庫分表的方案來提升系統可用性和可靠性的方法。

本文針對實際使用中出現的具體問題，從非關系型數據庫接口支持、基于標志位PV的手動存儲模式添加及數據庫分布式部署和優化的角度實現基于MongoDB的HIAF運行數據存儲系統(Archive Engine)。

1 Archive Engine的非關系型數據庫接口設計與實現

基于EPICS的存儲系統通過注冊PV的方式從IOC獲取需要采集的PV信息，同時提供了基于SQL的關系型數據庫接口[2]，圖1為基于EPICS的存儲系統中數據庫表的邏輯模型。可看出，對于復雜的數據類型，如浮點數數組類型的數據存儲，需通過標識位記錄數據類型，數據表只存入數組第1個值，其余值存入單獨表中的多表操作實現。對于圖像、視頻等實驗數據的存儲也同樣缺少靈活性。根據實際使用情況，HIAF Archive Engine選擇MongoDB作為非關系型數據庫，為Archive工具擴展非關系數據庫接口的支持。

1.1 Archive Engine非關系型數據庫MongoDB

MongoDB是一種分布式文件存儲數據庫，其可嵌套的數據存儲方式可為復雜的數據類型提供簡單易用的存儲方案，無需多表間的join操作[3]。提供動態查詢、排序、第二索引等豐富的功能接口，可方便地對內嵌數據進行查詢。同時GridFS作為MongoDB的內置功能，能很好地實現對其他文件類型數據的存儲[4]。此外，MongoDB有非常好的可擴展性，可在本地或網絡上快速部署分布式分片。

圖1 基于EPICS的存儲系統中關系型數據庫表邏輯模型Fig.1 Relational database logical model of archive tool based on EPICS

1.2 MongoDB接口實現和寫入性能測試

HIAF Archive Engine在支持關系型數據庫存儲的基礎上，從配置模塊的配置參數加載和導出、數據存儲模塊的數據讀取和寫入層上增加對MongoDB的接口支持。使用中只需配置文件中指定MongoDB的URL路徑。且MongoDB支持JavaScript腳本對數據庫進行管理，本文為Archive Engine的MongoDB數據庫實現了一鍵部署的功能。利用MongoDB可嵌套文件存儲的特點對表結構進行簡化后，Archive Engine的寫入效率得到了極大提升，圖2為用float類型數據持續寫入時MongoDB Archive Engine和Oracle Archive Engine寫入速率的對比。

2 基于標志位PV的手動存儲方案

基于EPICS的存儲系統提供3種模式的數據存儲方案：1) Monitored模式，將每個采集到的數據寫入數據庫存儲；2) Monitored with Threshold模式，當接收到的值和上一次存儲的值相比，其變化幅度超過用戶預設的threshold值時才將該值寫入數據庫；3) Scanned模式，將數據按照用戶設定的Period間隔時間寫入數據庫存儲[5]。

其數據存儲流程如圖3a所示。

圖2 MongoDB Archive Engine和Oracle Archive Engine持續寫入速率對比Fig.2 Writing speed comparison between Oracle Archive Engine and MongoDB Archive Engine

運行歷史數據的持續存儲是加速器裝置運行歷史數據記錄和后期實驗數據分析處理的基礎[6]，但現有的基于EPICS的存儲系統提供的存儲策略缺少對實驗離子類型、實驗條件和實驗人員等實驗信息的記錄，導致歷史數據有效信息檢索困難、數據利用率低的問題[7]。HIAF Archive Engine 實現了基于標志位PV的手動存儲方案，前端由CSS界面為實驗人員提供數據存儲界面(圖4)。后端Archive Engine注冊相關子系統和存儲命令的PV監聽，收到存儲命令后讀取相關實驗信息的PV值作為檢索條件存入數據庫，并開始對該子系統下運行數據的采集和存儲，流程如圖3b所示。

圖3 HIAF Archive Engine自動(a)和手動(b)存儲策略Fig.3 Automatic archive strategy (a) and manual archive strategy (b) of HIAF Archive Engine

圖4 數據保存CSS界面Fig.4 Manual archive GUI in CSS

3 HIAF Archive Engine數據庫分布式分片部署

隨著歷史數據的積累，Archive Engine的數據存儲負載將持續增加。傳統的數據庫分區方案中，多表操作和事務操作等會受到分區方案影響，甚至大規模數據遷移時會造成服務中斷，MongoDB有更高效的自動分片和動態均衡技術[8]。

Archive Engine的MongoDB分片主要分為3個部分，即分片節點Shard、配置節點Config Server和路由節點Mongos(圖5)。其中路由節點Mongos主要負責在Archive Engine和分片節點間做數據路由、數據遷移和負載平衡；分片節點Shard是實際的數據節點；配置節點Config Server存儲元數據，記錄數據的位置和分片節點的部署情況[9]。Archive Engine根據數據檢索以單次實驗子系統數據為檢索條件的特點，將子系統名稱和時間戳組合作為分片的Shard Key，有效提升Archive Engine的讀寫性能[10]。

圖5 Archive Engine MongoDB分片部署結構Fig.5 Archive Engine MongoDB sharding structure

4 結論及展望

HIAF Archive Engine在現有的運行數據歸檔系統的基礎上，增加了基于MongoDB的NoSQL接口支持，提升了運行數據存儲系統對非格式化數據存儲的靈活性和效率；增加了手動存儲數據的方案，提升了歷史數據檢索的準確性和數據利用率；通過部署分布式分片的MongoDB數據庫，解決了歷史數據累積后整個系統運行效率降低的問題。HIAF Archive Engine在后續使用中還將根據新的需求持續改進。