基于實時同步和全文搜索技術的方劑學多維實訓平臺

魏培陽，史曉雨，周杰三，邢曉方，梁佳豪，劉 洋

（1.重慶郵電大學計算機科學與技術學院，重慶 400065；2.成都信息工程大學軟件工程學院，四川 成都 610225；3.中國科學院重慶綠色智能技術研究院，重慶 400714；4.軟件自動生成與智能服務四川省重點實驗室，四川 成都 610225；5.獲嘉縣史莊鎮高廟小學，河南 新鄉 453800）

0 引 言

當前高等教育更加注重學生綜合素質，特別是實踐能力的培養，基于此背景的工程教育認證在各高校正如火如荼的展開。相應地，中醫藥人才教育更加重視學生學習的主動性和參與性，其中，方劑學是闡明和研究中醫治法、方劑配伍規律及其臨床運用的一門極其重要的學科，是中醫基礎向臨床過渡的橋梁課和專業核心課[1]，具有學習人數多、知識識記量大、概念易混淆等特點。與此同時，隨著數字化時代的到來，云計算、大數據、虛擬現實以及智能移動設備等構筑的數字孿生世界結合具體的業務應用逐漸增多并成為重要的研究課題[2]。因此，利用信息化技術構建并發量大、響應及時且便于對方劑學知識全文搜索的實踐實訓平臺成為可能。

針對方劑學與信息技術的應用結合，國內外相關學者在諸多領域給出了不同的方案。粟栗等建設了一個方劑學在線學習平臺，初步實現了方劑學知識學習與測試，但是對系統的高并發帶來的可靠性未提及[3]。許霞等提出一種中醫專業實踐教學軟件，實現模擬處方、視頻教學、課后作業等功能，一定程度上提高了學生方劑學自主學習能力，但是對數據如何有效同步等未做說明[4]。王寶瑩等開發了基于Android 的中藥方劑學移動應用平臺，主要用于展示方劑學藥方知識，但對方劑知識存儲量及表示類型等未做明確說明[5]。另外，蔣羽利用中藥藥理文獻，針對方劑配伍的藥理作用做了有益的探索[6]。尹丹利用方劑學教材知識，構建了中醫常用方劑知識圖譜，為方劑智能推理提供數據支持[7]。

然而，面對方劑學平臺大用戶量的并發使用、多維知識的全文搜索，以及基于方劑學知識的組方、練習、PK 對戰等多任務的實時同步和及時響應等要求，上述文獻并未提及或較少描述。其他領域學者為解決此類問題提供了思路。如張積存等使用ElasticSearch 作為存儲平臺和搜索引擎，設計并實現基于結構化過車數據的車輛大數據分析系統，對數據的檢索和分析做了有益的探索[8]。施曉峰將分布式NoSQL 數據庫、分布式文件系統、ElasticSearch 搜索引擎應用于檔案大數據的管理，設計一套大數據存儲與檢索方案[9]。許賢慧等利用ElasticSearch 實現工程數據檢索，并對性能做了優化提升[10]。陶磊等利用知識圖譜技術整合復雜的教學資源，并在此基礎上實現了一種基于ElasticSearch 和語義相似度匹配的教學資源搜索策略，保證了檢索速度[11]。何運田等基于Kong 和ElasticSearch 設計并實現了一套API 網關集成及監控系統，將不同協議、編程語言等進行整合，達到全文搜索的目的[12]。楊婷等針對關系型數據庫現有全文搜索方案存在的效率低下、資源占用高等問題，提出一種基于Redis 的增強式伴隨輔助緩存的輕量級關系型數據庫全文搜索模型[13]。甘一鳴等設計一種基于Redis 的高并發潛艇部隊訓練信息管理系統[14]。Zhou Lijuan 等針對圖片存儲，提出了一種基于HBase 和Redis 的緩存優化模型[15]。Liu Q 等提出了一種高性能的內存鍵值對數據庫Redis++[16]。通過使用ElasticSearch 框架優化其性能和實時查詢效率，分析日志數據，達到追蹤系統故障和提升其健壯性的目標[17-18]。B. C. Ghosh 等針對無服務器架構中性能損失問題，提出一種緩存機制用以縮短響應時間[19]。Li Y等針對大數據量查詢分析的性能受限的問題，使用Spark 和ElasticSearch 構建一種基于云架構的日志挖掘框架[20]。

綜上，結合文獻表述，針對方劑學多維實訓平臺（Multi - dimensional Training Platform for Formulation,MTPF）存在的問題，本文提出一種使用Canal 作為數據同步框架，以ElasticSearch 的倒排索引構建和全文搜索為核心，同時將Redis 緩存優化功能融入體系框架的高實時、高并發的全文搜索算法。最后，通過平臺部署以及多用戶場景測試及應用，并對比了不同檢索方法，有針對性地做了指標的量化測試。

1 相關技術

1.1 ElasticSearch

ElasticSearch 是一個開源的全文搜索和分析引擎，它可以近乎實時地存儲、檢索和分析大量的文本數據。ElasticSearch 使用Lucene 作為其核心實現，并且具有高度的可擴展性，可以輕松地擴展到上百臺服務器，處理PB 級別的數據。同時ElasticSearch 具有以下的特點：

1）配置方便、使用簡單。用戶創建索引，即可對文檔進行全文搜索、分析、排序和展示。支持結構化和部分半結構化數據類型，同時還支持分布式搜索和聚合查詢。

2）分片存儲、自動備份。索引是框架存儲數據的基本單位，當索引上數據量較大時，可以將數據做水平拆分，形成分片，在數據寫入時通過計算文檔ID 的哈希值來確定要寫入的分片；同時會自動對數據進行備份，形成副本，以確保某臺服務器在宕機后其數據不會丟失，保證了服務的高可用性。

3）實時監控、響應迅速。方便獲取指定時間段內的數據變化情況，幫助用戶及時發現數據異常和問題。同時，ElasticSearch 也存在對硬件資源要求較高、索引和搜索需要較長時間等問題，這也是本文關注的重點。

1.2 Redis

Redis 是一個開源的內存數據結構存儲系統，支持多種數據結構，包括字符串、哈希表、列表、集合和有序集合。Redis 可以將常用的數據存儲在內存中，提高讀取速度，從而加快應用程序的響應時間。在消息隊列方面，Redis 支持多個發送者和接收者，實現高效的消息傳遞。在分布式系統和實時數據處理方面，Redis 可以用作數據庫、緩存和消息代理等多種角色。

1.3 Canal

Canal 是一個開源的數據庫管理系統，具有性能優勢和安全性能保證，廣泛應用于大型企業和高性能計算環境中。由于Canal 使用了增量日志解析技術，所以其實時性非常高，幾乎可以實時同步不同數據的變更，并將其傳遞給后續業務處理。同時，Canal 支持單點、集群、嵌入和云端等多種部署模式，可以根據需求選擇合適的方式來保證實時性和可靠性，用以滿足絕大多數實時數據同步和數據分發場景需求。

2 系統模型

基于實時同步和全文搜索的方劑學實訓平臺框圖如圖1 所示，其主要由請求分發、數據存儲、數據同步、全文搜索等模塊構成。

圖1 方劑學實訓平臺框圖

2.1 模塊說明

2.1.1 請求分發模塊

請求分發模塊以Nginx 網絡服務器為中心，主要針對系統存在大容量多用戶并發在線使用的情況而設置。Nginx 起到處理諸如圖片、HTTP 請求、全文檢索等不同需求類型響應的作用，從而提高系統加載速度；同時面對高并發時，可以開啟負載均衡和動態內容分發服務，以便分擔請求負載，從而提升服務器的可用性和性能。

2.1.2 數據存儲模塊

數據存儲模塊由負責關系型數據持久化的MySQL數據庫、圖片存儲的FTP 文件服務和用于緩存數據的Redis 等三種類型的存儲服務組成。其中：MySQL 主要用于存儲平臺系統結構化數據信息，為系統的管理和應用層提供基礎數據服務；FTP 文件服務主要為平臺應用層的具體場景提供圖片的讀取、載入、存儲等服務；Redis 則主要為了提升系統訪問性能，通過定時任務熱更新機制，將經常訪問的數據存儲在Redis 中，以提升請求訪問的命中率，從而達到有效優化訪問速度的目的。

2.1.3 數據同步模塊

數據同步模塊主要以開源的Canal 框架為中心實施，解析訂閱的存儲系統主要數據的MySQL 的binlog（二進制日志文件），并及時將數據庫的變更操作解析成SQL 語句；然后將這些SQL 語句發送到目標ElasticSearch，實現數據同步。

Canal實現數據同步的主要步驟如下：

1）連接到系統的數據存儲MySQL 數據庫，并獲取binlog 的文件名和位置，實現變更日志的訂閱功能。

2）使用binlog 文件中的數據解析MySQL 數據庫中的每次變更操作。Canal 使用具有獨立服務進程的Canal Server，一端連接到MySQL 數據庫，并監聽binlog變化。當數據庫發生變更時，Canal Server 會將變更操作解析成SQL 語句，并將其發送到Canal Client。

3）Canal Client 接收到SQL 語句后，會將其發送到ElasticSearch，從而實現快速索引，達到實現數據同步的目標。

在數據同步的Canal 應用中，針對方劑學實訓平臺諸如簡繁體字處理、按規則篩選冗余數據、算術運算等具體業務需求做有目的性的優化和完善，以進一步提升同步的效率和準確性。

2.1.4 全文搜索模塊

全文搜索模塊利用ElasticSearch 及時響應用戶對系統的各類查詢請求，達到準實時狀態，實現業務數據的全量檢索；但是針對中醫方劑業務的適應性方面，其性能還有優化的空間。為了解決這個問題，本文對ElasticSearch 的底層原理進行深入研究，通過對ElasticSearch 索引、分詞器進行修改并設置黑白名單機制，制定自定義的擴展詞和停用詞詞典，達到進一步過濾需求，提升數據查詢性能的目的。

2.2 執行過程步驟

本文主要依據圖1 平臺框圖，基于數據檢索的流程描述其執行過程：

1）將源于PC 端和移動端等不同類型終端的多用戶請求通過Nginx 網絡服務器轉發。

2）根據不同的請求類型轉發到相應的對象。針對業務數據，首先訪問Redis，若未能命中，再次訪問MySQL 數據庫，同時通過輪巡更新機制將訪問信息存放至Redis 中，以便后續訪問，提高效率。針對高級檢索請求，將其轉發至ElasticSearch 服務器。

3）各類型請求響應服務器獲取相關資源數據并反饋結果。其中：圖片等非結構化數據通過FTP 文件服務器加載；業務信息熱數據通過Redis 獲取，普通數據通過MySQL 響應；高級檢索需求通過ElasticSearch 響應。

4）如果Canal 監測到MySQL 的binlog 發生變更，將自動啟動同步操作，保持業務數據與ElasticSearch 索引庫數據的一致。

5）ElasticSearch 服務器在索引庫中將經過算法過濾的數據信息反饋展示。

3 算法說明

3.1 Canal同步算法設計

中醫方劑學中存在著異體字、簡繁體轉換、無實意的繁體語氣助詞以及對部分業務數據的科學計算等情況，同時存在小批量、多頻次的數據更新現象，影響同步效率。針對上述問題，本文通過優化改進開源的Canal框架，在監控同步間隔和替換適配器組件等方面做了完善工作，Canal具體的同步算法優化框圖如圖2 所示。

圖2 Canal同步算法優化框圖

設當前從MySQL 獲取的數據為Gdata，同步開始的時間戳為Ts，同步數據為Sdata，是否開啟適配器為ISabaptor。

1）監控同步間隔

Canal 通過訂閱觸發MySQL 的數據同步事件，獲取數據Gdata，同時計時器Timer 記錄本批次Batch 數據處理開始的時間戳Ts。通過式（1）的指數加權平均函數達到去除噪聲、平滑數據的效果，也能夠較為容易地刻畫原數據趨勢。結合鄰近的數據同步周期，動態計算調整同步至ElasticSearch 的時間周期，以達到同步速度與資源消耗的再平衡。

式中：θt為第t次的實際響應時間；修正設置同步周期為vt，vt是要代替θt的估計值，也就是第t次的指數加權平均值；β為vt-1的權重，是可調節的超參數（0 ＜β＜1）。

2）重寫Canal適配器組件

提前靈活構建滿足要求的各類處理函數，根據業務需求在本批次Batch 中啟用相應函數。例如，處理簡繁體轉換函數（SimAndComFun）、異體字函數（DiffCharFun）、去除語氣詞函數（DropModalFun），科學計算函數（ComputeFun）等。通過傳入參數ISabaptor確定是否增加配置過濾器方法，對Canal 同步做二次優化處理。若ISabaptor值為False，不開啟過濾器；反之開啟，針對具體要求配置需要用到的處理函數。過濾器函數處理結束，返回經過清洗后的同步數據Sdata。同步算法關鍵代碼如下：

3.2 ElasticSearch 詞典優化算法設計

中醫方劑學資料不僅有結構化數據，還存在圖片、文本等非結構化數據，同時業務數據中存在著“乎”“兮”“之”等不需要參與檢索的停用詞，以及專有名詞、高頻詞等組成的擴展詞問題。針對上述提及的業務要求，本文通過對ElasticSearch 設立自定義擴展詞分詞詞典及停用詞詞典的方法構建索引，以優化解決存在的問題。具體優化框圖如圖3 所示。

圖3 ElasticSearch 詞典優化算法框圖

設接收的數據為Rmsg，是否是文本數據為ISf，結構化數據為Smsg，文本數據為Fmsg，分詞詞元為Wu，擴展分詞器為Ew，停用詞分詞器為Sw，倒排索引為Idata。利用ElasticSearch 進行全文搜索時，需要對接收的數據Rmsg建立索引，這里通過ISf標志位確定數據是否為文本類型。因為針對非文本類數據使用元數據創建，對于文本類數據Fmsg則需通過文件操作依次讀取數據，然后調用自定義的分詞器Ew和Sw做運算后再進行分詞。經過上述運算最終得到用于構建倒排索引的分詞Wu。其中，自定義分詞器Ew和Sw通過熱更新技術實現，從而達到提升搜索結果的效率和準確性的目的，并且通過實時更新分詞器的字典的方式，可以在不重啟應用的情況下讓自定義的分詞器更加實時地對文本進行分析，以滿足用戶高效搜索需求。

4 系統應用與測試

4.1 Canal與Logstash 同步時延對比

當前的主流同步框架為Logstash，但其存在時效性較差、資源消耗高、數據二次處理與過濾能力不足等問題。為此，本文提出對開源同步框架Canal 結合SpringBoot 技術做優化的解決方案。

為驗證MTPF 使用的同步技術性能，設計基于2 臺Intel?Core i7 CPU，16 GB RAM 的計算機設備的同步時延實驗。其中一臺安裝MySQL 和ElasticSearch 并完成配置，以提供數據支持并實時監控同步情況；另一臺分別配置Canal 和Logstash 環境，并與MySQL 和ElasticSearch 連通。

表1展示數據分別在10 000條、100 000條、1 000 000條記錄時，兩種同步框架的時延對比情況。

表1 同步時延對比

首先，在大數據量同步過程配置實時監控文件，跟蹤數據變化和ElasticSearch 中索引更新情況。

其次，計算Canal 的同步時間為從MySQL 到ElasticSearch 的正常時間間隔，此時間間隔使用指數加權平均做優化；Logstash 的同步時間為從MySQL 到ElasticSearch 的理想時間間隔，即當前批次數據更新結束，新一輪的批量數據立即又開啟同步，表1 中Logstash的同步時延即基于理想間隔完成。正常情況下，Logstash 同步數據時間遵循以下公式：

式中：Tinterval為自定義設置的Logstash時間間隔；sp為數據更新至MySQL 時距離上次同步完成的時間；data 為此時的數據量；Idata表示該數據量對應的理想同步時間。由此可知，若在實際業務場景，Logstash的時延要更長。

由表1 分析可知，在數據量不大于10 000 條時，Canal的時延大于Logstash，說明在處理小數據量時Canal的性能并未完全顯現。但是，在數據量大于100 000 條之后，Canal 在處理大數據量同步上的性能優勢就逐步體現出來，在1 000 000 條的結果表明，Canal 也與Logstash 的差距較大。

4.2 Canal和Logstash 的CPU 消耗對比

CPU 消耗實驗基于數據量為100 000 條的約束展開，主要通過Canal 和Logstash 將MySQL 同步至ElasticSearch 過程中，觀察CPU 消耗資源的占比情況，說明框架的性能。基于一次批量數據處理在當前用戶空間中，兩個框架全過程消耗CPU 資源的情況對比結果如圖4 所示。由于Canal 需要做業務適配運算及同步周期監控，所以在處理初期，CPU 資源占比較大。待相關運算計算完成，只做同步工作后，相比Logstash 框架，Canal 的CPU 資源占有率呈明顯下降趨勢。當然，系統中的數據同步任務并非時刻進行，在無數據同步任務時，兩個框架進程CPU 平均占有率如表2 所示。明顯可見，Canal比Logstash 消耗服務器資源更少。

表2 無數據變化時的CPU 占有率 %

圖4 系統CPU 占有率對比

由于在同步任務中，兩個框架都需要與MySQL 數據庫交互，因此MySQL 的CPU 平均占有率也可能反映出框架性能情況。表3 為統計的在執行同步任務過程中MySQL 的CPU 平均占有率。由表3 可知，在同步過程中Canal 不僅相對占用資源少，且對MySQL 數據庫的負載也相對較小。

綜上所述，在使用Canal 作為數據同步技術時，不僅對系統資源消耗較少，而且處理效率也較高。特別是面向大數據量同步時，Canal 性能更加明顯，且在未執行任務情況下，也有資源占有率較低的優點。對于在凌晨、節假日等數據變化量不大的情況下，節約系統資源消耗具有重要意義，這些特性也更加適用于當前業務場景。

4.3 MySQL 和ElasticSearch 的檢索能力對比

MySQL 數據庫本身也具備檢索查詢能力，將其與本文經過改進后的ElasticSearch 進行對比，比較兩者在檢索速度上是否具有明顯差異。考慮MySQL 的數據壓力，本文基于MySQL 和ElasticSearch 中的10 000 條數據，針對檢索性能作對比實驗。實驗使用MySQL 數據庫的模糊查詢和ElasticSearch 的多字段檢索，使用相同的字段以及檢索值進行數據搜索，獲取檢索結果并進行對比統計。通過多次實驗，求平均得出MySQL 和ElasticSearch 的檢索性能，結果如表4 所示。

表4 MySQL 與ElasticSearch 的檢索能力對比

實驗結果證明：優化后的ElasticSearch在當前10 000 條數據量的條件下的檢索性能是MySQL 的21 倍；而在更大的百萬級數據量檢索速度上，ElasticSearch 則具有更顯著的優勢。 因此，可以說明優化改進后的ElasticSearch 無論在哪個數據量級上都完全能夠滿足MTPF 使用的搜索要求，可以提供更貼合用戶語義、更加高效的全文搜索能力。

5 結 語

針對中醫方劑學實訓平臺的數據特點及業務需要，以及數據同步和全文搜索框架，提出一種優化改進技術方案，解決了方劑學實驗實訓過程中識記不便、數據零散、搜索受限等問題。通過在Canal 框架中引入指數加權平均，動態調整優化同步周期，同時自定義同步適配器，有針對性地解決了方劑學業務的特殊需求，在提高數據同步質量的同時又有效提升了同步的效率。通過在ElasticSearch 框架中引入新的分詞器，構建面向方劑學業務的擴展詞和停用詞字典。從領域問題的解決著手，構建滿足檢索性能和準確率要求的倒排索引庫，有力保障了平臺的全文搜索能力。但是對于平臺而言，仍然存在很多技術難點有待突破，例如：學習中常用方劑及藥材根據用戶不同的智能個性化推薦研究及探索；同時，隨著平臺逐步的應用，針對音頻、視頻等非結構化數據的存儲、傳輸及處理也是下一步研究的方向。

注：本文通訊作者為魏培陽。