基于實(shí)時(shí)同步和全文搜索技術(shù)的方劑學(xué)多維實(shí)訓(xùn)平臺(tái)

魏培陽(yáng)，史曉雨，周杰三，邢曉方，梁佳豪，劉 洋

（1.重慶郵電大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，重慶 400065；2.成都信息工程大學(xué)軟件工程學(xué)院，四川 成都 610225；3.中國(guó)科學(xué)院重慶綠色智能技術(shù)研究院，重慶 400714；4.軟件自動(dòng)生成與智能服務(wù)四川省重點(diǎn)實(shí)驗(yàn)室，四川 成都 610225；5.獲嘉縣史莊鎮(zhèn)高廟小學(xué)，河南 新鄉(xiāng) 453800）

0 引 言

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

針對(duì)方劑學(xué)與信息技術(shù)的應(yīng)用結(jié)合，國(guó)內(nèi)外相關(guān)學(xué)者在諸多領(lǐng)域給出了不同的方案。粟栗等建設(shè)了一個(gè)方劑學(xué)在線(xiàn)學(xué)習(xí)平臺(tái)，初步實(shí)現(xiàn)了方劑學(xué)知識(shí)學(xué)習(xí)與測(cè)試，但是對(duì)系統(tǒng)的高并發(fā)帶來(lái)的可靠性未提及[3]。許霞等提出一種中醫(yī)專(zhuān)業(yè)實(shí)踐教學(xué)軟件，實(shí)現(xiàn)模擬處方、視頻教學(xué)、課后作業(yè)等功能，一定程度上提高了學(xué)生方劑學(xué)自主學(xué)習(xí)能力，但是對(duì)數(shù)據(jù)如何有效同步等未做說(shuō)明[4]。王寶瑩等開(kāi)發(fā)了基于Android 的中藥方劑學(xué)移動(dòng)應(yīng)用平臺(tái)，主要用于展示方劑學(xué)藥方知識(shí)，但對(duì)方劑知識(shí)存儲(chǔ)量及表示類(lèi)型等未做明確說(shuō)明[5]。另外，蔣羽利用中藥藥理文獻(xiàn)，針對(duì)方劑配伍的藥理作用做了有益的探索[6]。尹丹利用方劑學(xué)教材知識(shí)，構(gòu)建了中醫(yī)常用方劑知識(shí)圖譜，為方劑智能推理提供數(shù)據(jù)支持[7]。

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

綜上，結(jié)合文獻(xiàn)表述，針對(duì)方劑學(xué)多維實(shí)訓(xùn)平臺(tái)（Multi - dimensional Training Platform for Formulation,MTPF）存在的問(wèn)題，本文提出一種使用Canal 作為數(shù)據(jù)同步框架，以ElasticSearch 的倒排索引構(gòu)建和全文搜索為核心，同時(shí)將Redis 緩存優(yōu)化功能融入體系框架的高實(shí)時(shí)、高并發(fā)的全文搜索算法。最后，通過(guò)平臺(tái)部署以及多用戶(hù)場(chǎng)景測(cè)試及應(yīng)用，并對(duì)比了不同檢索方法，有針對(duì)性地做了指標(biāo)的量化測(cè)試。

1 相關(guān)技術(shù)

1.1 ElasticSearch

ElasticSearch 是一個(gè)開(kāi)源的全文搜索和分析引擎，它可以近乎實(shí)時(shí)地存儲(chǔ)、檢索和分析大量的文本數(shù)據(jù)。ElasticSearch 使用Lucene 作為其核心實(shí)現(xiàn)，并且具有高度的可擴(kuò)展性，可以輕松地?cái)U(kuò)展到上百臺(tái)服務(wù)器，處理PB 級(jí)別的數(shù)據(jù)。同時(shí)ElasticSearch 具有以下的特點(diǎn)：

1）配置方便、使用簡(jiǎn)單。用戶(hù)創(chuàng)建索引，即可對(duì)文檔進(jìn)行全文搜索、分析、排序和展示。支持結(jié)構(gòu)化和部分半結(jié)構(gòu)化數(shù)據(jù)類(lèi)型，同時(shí)還支持分布式搜索和聚合查詢(xún)。

2）分片存儲(chǔ)、自動(dòng)備份。索引是框架存儲(chǔ)數(shù)據(jù)的基本單位，當(dāng)索引上數(shù)據(jù)量較大時(shí)，可以將數(shù)據(jù)做水平拆分，形成分片，在數(shù)據(jù)寫(xiě)入時(shí)通過(guò)計(jì)算文檔ID 的哈希值來(lái)確定要寫(xiě)入的分片；同時(shí)會(huì)自動(dòng)對(duì)數(shù)據(jù)進(jìn)行備份，形成副本，以確保某臺(tái)服務(wù)器在宕機(jī)后其數(shù)據(jù)不會(huì)丟失，保證了服務(wù)的高可用性。

3）實(shí)時(shí)監(jiān)控、響應(yīng)迅速。方便獲取指定時(shí)間段內(nèi)的數(shù)據(jù)變化情況，幫助用戶(hù)及時(shí)發(fā)現(xiàn)數(shù)據(jù)異常和問(wèn)題。同時(shí)，ElasticSearch 也存在對(duì)硬件資源要求較高、索引和搜索需要較長(zhǎng)時(shí)間等問(wèn)題，這也是本文關(guān)注的重點(diǎn)。

1.2 Redis

Redis 是一個(gè)開(kāi)源的內(nèi)存數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)系統(tǒng)，支持多種數(shù)據(jù)結(jié)構(gòu)，包括字符串、哈希表、列表、集合和有序集合。Redis 可以將常用的數(shù)據(jù)存儲(chǔ)在內(nèi)存中，提高讀取速度，從而加快應(yīng)用程序的響應(yīng)時(shí)間。在消息隊(duì)列方面，Redis 支持多個(gè)發(fā)送者和接收者，實(shí)現(xiàn)高效的消息傳遞。在分布式系統(tǒng)和實(shí)時(shí)數(shù)據(jù)處理方面，Redis 可以用作數(shù)據(jù)庫(kù)、緩存和消息代理等多種角色。

1.3 Canal

Canal 是一個(gè)開(kāi)源的數(shù)據(jù)庫(kù)管理系統(tǒng)，具有性能優(yōu)勢(shì)和安全性能保證，廣泛應(yīng)用于大型企業(yè)和高性能計(jì)算環(huán)境中。由于Canal 使用了增量日志解析技術(shù)，所以其實(shí)時(shí)性非常高，幾乎可以實(shí)時(shí)同步不同數(shù)據(jù)的變更，并將其傳遞給后續(xù)業(yè)務(wù)處理。同時(shí)，Canal 支持單點(diǎn)、集群、嵌入和云端等多種部署模式，可以根據(jù)需求選擇合適的方式來(lái)保證實(shí)時(shí)性和可靠性，用以滿(mǎn)足絕大多數(shù)實(shí)時(shí)數(shù)據(jù)同步和數(shù)據(jù)分發(fā)場(chǎng)景需求。

2 系統(tǒng)模型

基于實(shí)時(shí)同步和全文搜索的方劑學(xué)實(shí)訓(xùn)平臺(tái)框圖如圖1 所示，其主要由請(qǐng)求分發(fā)、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)同步、全文搜索等模塊構(gòu)成。

圖1 方劑學(xué)實(shí)訓(xùn)平臺(tái)框圖

2.1 模塊說(shuō)明

2.1.1 請(qǐng)求分發(fā)模塊

請(qǐng)求分發(fā)模塊以Nginx 網(wǎng)絡(luò)服務(wù)器為中心，主要針對(duì)系統(tǒng)存在大容量多用戶(hù)并發(fā)在線(xiàn)使用的情況而設(shè)置。Nginx 起到處理諸如圖片、HTTP 請(qǐng)求、全文檢索等不同需求類(lèi)型響應(yīng)的作用，從而提高系統(tǒng)加載速度；同時(shí)面對(duì)高并發(fā)時(shí)，可以開(kāi)啟負(fù)載均衡和動(dòng)態(tài)內(nèi)容分發(fā)服務(wù)，以便分擔(dān)請(qǐng)求負(fù)載，從而提升服務(wù)器的可用性和性能。

2.1.2 數(shù)據(jù)存儲(chǔ)模塊

數(shù)據(jù)存儲(chǔ)模塊由負(fù)責(zé)關(guān)系型數(shù)據(jù)持久化的MySQL數(shù)據(jù)庫(kù)、圖片存儲(chǔ)的FTP 文件服務(wù)和用于緩存數(shù)據(jù)的Redis 等三種類(lèi)型的存儲(chǔ)服務(wù)組成。其中：MySQL 主要用于存儲(chǔ)平臺(tái)系統(tǒng)結(jié)構(gòu)化數(shù)據(jù)信息，為系統(tǒng)的管理和應(yīng)用層提供基礎(chǔ)數(shù)據(jù)服務(wù)；FTP 文件服務(wù)主要為平臺(tái)應(yīng)用層的具體場(chǎng)景提供圖片的讀取、載入、存儲(chǔ)等服務(wù)；Redis 則主要為了提升系統(tǒng)訪(fǎng)問(wèn)性能，通過(guò)定時(shí)任務(wù)熱更新機(jī)制，將經(jīng)常訪(fǎng)問(wèn)的數(shù)據(jù)存儲(chǔ)在Redis 中，以提升請(qǐng)求訪(fǎng)問(wèn)的命中率，從而達(dá)到有效優(yōu)化訪(fǎng)問(wèn)速度的目的。

2.1.3 數(shù)據(jù)同步模塊

數(shù)據(jù)同步模塊主要以開(kāi)源的Canal 框架為中心實(shí)施，解析訂閱的存儲(chǔ)系統(tǒng)主要數(shù)據(jù)的MySQL 的binlog（二進(jìn)制日志文件），并及時(shí)將數(shù)據(jù)庫(kù)的變更操作解析成SQL 語(yǔ)句；然后將這些SQL 語(yǔ)句發(fā)送到目標(biāo)ElasticSearch，實(shí)現(xiàn)數(shù)據(jù)同步。

Canal實(shí)現(xiàn)數(shù)據(jù)同步的主要步驟如下：

1）連接到系統(tǒng)的數(shù)據(jù)存儲(chǔ)MySQL 數(shù)據(jù)庫(kù)，并獲取binlog 的文件名和位置，實(shí)現(xiàn)變更日志的訂閱功能。

2）使用binlog 文件中的數(shù)據(jù)解析MySQL 數(shù)據(jù)庫(kù)中的每次變更操作。Canal 使用具有獨(dú)立服務(wù)進(jìn)程的Canal Server，一端連接到MySQL 數(shù)據(jù)庫(kù)，并監(jiān)聽(tīng)binlog變化。當(dāng)數(shù)據(jù)庫(kù)發(fā)生變更時(shí)，Canal Server 會(huì)將變更操作解析成SQL 語(yǔ)句，并將其發(fā)送到Canal Client。

3）Canal Client 接收到SQL 語(yǔ)句后，會(huì)將其發(fā)送到ElasticSearch，從而實(shí)現(xiàn)快速索引，達(dá)到實(shí)現(xiàn)數(shù)據(jù)同步的目標(biāo)。

在數(shù)據(jù)同步的Canal 應(yīng)用中，針對(duì)方劑學(xué)實(shí)訓(xùn)平臺(tái)諸如簡(jiǎn)繁體字處理、按規(guī)則篩選冗余數(shù)據(jù)、算術(shù)運(yùn)算等具體業(yè)務(wù)需求做有目的性的優(yōu)化和完善，以進(jìn)一步提升同步的效率和準(zhǔn)確性。

2.1.4 全文搜索模塊

全文搜索模塊利用ElasticSearch 及時(shí)響應(yīng)用戶(hù)對(duì)系統(tǒng)的各類(lèi)查詢(xún)請(qǐng)求，達(dá)到準(zhǔn)實(shí)時(shí)狀態(tài)，實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)的全量檢索；但是針對(duì)中醫(yī)方劑業(yè)務(wù)的適應(yīng)性方面，其性能還有優(yōu)化的空間。為了解決這個(gè)問(wèn)題，本文對(duì)ElasticSearch 的底層原理進(jìn)行深入研究，通過(guò)對(duì)ElasticSearch 索引、分詞器進(jìn)行修改并設(shè)置黑白名單機(jī)制，制定自定義的擴(kuò)展詞和停用詞詞典，達(dá)到進(jìn)一步過(guò)濾需求，提升數(shù)據(jù)查詢(xún)性能的目的。

2.2 執(zhí)行過(guò)程步驟

本文主要依據(jù)圖1 平臺(tái)框圖，基于數(shù)據(jù)檢索的流程描述其執(zhí)行過(guò)程：

1）將源于PC 端和移動(dòng)端等不同類(lèi)型終端的多用戶(hù)請(qǐng)求通過(guò)Nginx 網(wǎng)絡(luò)服務(wù)器轉(zhuǎn)發(fā)。

2）根據(jù)不同的請(qǐng)求類(lèi)型轉(zhuǎn)發(fā)到相應(yīng)的對(duì)象。針對(duì)業(yè)務(wù)數(shù)據(jù)，首先訪(fǎng)問(wèn)Redis，若未能命中，再次訪(fǎng)問(wèn)MySQL 數(shù)據(jù)庫(kù)，同時(shí)通過(guò)輪巡更新機(jī)制將訪(fǎng)問(wèn)信息存放至Redis 中，以便后續(xù)訪(fǎng)問(wèn)，提高效率。針對(duì)高級(jí)檢索請(qǐng)求，將其轉(zhuǎn)發(fā)至ElasticSearch 服務(wù)器。

3）各類(lèi)型請(qǐng)求響應(yīng)服務(wù)器獲取相關(guān)資源數(shù)據(jù)并反饋結(jié)果。其中：圖片等非結(jié)構(gòu)化數(shù)據(jù)通過(guò)FTP 文件服務(wù)器加載；業(yè)務(wù)信息熱數(shù)據(jù)通過(guò)Redis 獲取，普通數(shù)據(jù)通過(guò)MySQL 響應(yīng)；高級(jí)檢索需求通過(guò)ElasticSearch 響應(yīng)。

4）如果Canal 監(jiān)測(cè)到MySQL 的binlog 發(fā)生變更，將自動(dòng)啟動(dòng)同步操作，保持業(yè)務(wù)數(shù)據(jù)與ElasticSearch 索引庫(kù)數(shù)據(jù)的一致。

5）ElasticSearch 服務(wù)器在索引庫(kù)中將經(jīng)過(guò)算法過(guò)濾的數(shù)據(jù)信息反饋展示。

3 算法說(shuō)明

3.1 Canal同步算法設(shè)計(jì)

中醫(yī)方劑學(xué)中存在著異體字、簡(jiǎn)繁體轉(zhuǎn)換、無(wú)實(shí)意的繁體語(yǔ)氣助詞以及對(duì)部分業(yè)務(wù)數(shù)據(jù)的科學(xué)計(jì)算等情況，同時(shí)存在小批量、多頻次的數(shù)據(jù)更新現(xiàn)象，影響同步效率。針對(duì)上述問(wèn)題，本文通過(guò)優(yōu)化改進(jìn)開(kāi)源的Canal框架，在監(jiān)控同步間隔和替換適配器組件等方面做了完善工作，Canal具體的同步算法優(yōu)化框圖如圖2 所示。

圖2 Canal同步算法優(yōu)化框圖

設(shè)當(dāng)前從MySQL 獲取的數(shù)據(jù)為Gdata，同步開(kāi)始的時(shí)間戳為T(mén)s，同步數(shù)據(jù)為Sdata，是否開(kāi)啟適配器為ISabaptor。

1）監(jiān)控同步間隔

Canal 通過(guò)訂閱觸發(fā)MySQL 的數(shù)據(jù)同步事件，獲取數(shù)據(jù)Gdata，同時(shí)計(jì)時(shí)器Timer 記錄本批次Batch 數(shù)據(jù)處理開(kāi)始的時(shí)間戳Ts。通過(guò)式（1）的指數(shù)加權(quán)平均函數(shù)達(dá)到去除噪聲、平滑數(shù)據(jù)的效果，也能夠較為容易地刻畫(huà)原數(shù)據(jù)趨勢(shì)。結(jié)合鄰近的數(shù)據(jù)同步周期，動(dòng)態(tài)計(jì)算調(diào)整同步至ElasticSearch 的時(shí)間周期，以達(dá)到同步速度與資源消耗的再平衡。

式中：θt為第t次的實(shí)際響應(yīng)時(shí)間；修正設(shè)置同步周期為vt，vt是要代替θt的估計(jì)值，也就是第t次的指數(shù)加權(quán)平均值；β為vt-1的權(quán)重，是可調(diào)節(jié)的超參數(shù)（0 ＜β＜1）。

2）重寫(xiě)Canal適配器組件

提前靈活構(gòu)建滿(mǎn)足要求的各類(lèi)處理函數(shù)，根據(jù)業(yè)務(wù)需求在本批次Batch 中啟用相應(yīng)函數(shù)。例如，處理簡(jiǎn)繁體轉(zhuǎn)換函數(shù)（SimAndComFun）、異體字函數(shù)（DiffCharFun）、去除語(yǔ)氣詞函數(shù)（DropModalFun），科學(xué)計(jì)算函數(shù)（ComputeFun）等。通過(guò)傳入?yún)?shù)ISabaptor確定是否增加配置過(guò)濾器方法，對(duì)Canal 同步做二次優(yōu)化處理。若ISabaptor值為False，不開(kāi)啟過(guò)濾器；反之開(kāi)啟，針對(duì)具體要求配置需要用到的處理函數(shù)。過(guò)濾器函數(shù)處理結(jié)束，返回經(jīng)過(guò)清洗后的同步數(shù)據(jù)Sdata。同步算法關(guān)鍵代碼如下：

3.2 ElasticSearch 詞典優(yōu)化算法設(shè)計(jì)

中醫(yī)方劑學(xué)資料不僅有結(jié)構(gòu)化數(shù)據(jù)，還存在圖片、文本等非結(jié)構(gòu)化數(shù)據(jù)，同時(shí)業(yè)務(wù)數(shù)據(jù)中存在著“乎”“兮”“之”等不需要參與檢索的停用詞，以及專(zhuān)有名詞、高頻詞等組成的擴(kuò)展詞問(wèn)題。針對(duì)上述提及的業(yè)務(wù)要求，本文通過(guò)對(duì)ElasticSearch 設(shè)立自定義擴(kuò)展詞分詞詞典及停用詞詞典的方法構(gòu)建索引，以?xún)?yōu)化解決存在的問(wèn)題。具體優(yōu)化框圖如圖3 所示。

圖3 ElasticSearch 詞典優(yōu)化算法框圖

設(shè)接收的數(shù)據(jù)為Rmsg，是否是文本數(shù)據(jù)為ISf，結(jié)構(gòu)化數(shù)據(jù)為Smsg，文本數(shù)據(jù)為Fmsg，分詞詞元為Wu，擴(kuò)展分詞器為Ew，停用詞分詞器為Sw，倒排索引為Idata。利用ElasticSearch 進(jìn)行全文搜索時(shí)，需要對(duì)接收的數(shù)據(jù)Rmsg建立索引，這里通過(guò)ISf標(biāo)志位確定數(shù)據(jù)是否為文本類(lèi)型。因?yàn)獒槍?duì)非文本類(lèi)數(shù)據(jù)使用元數(shù)據(jù)創(chuàng)建，對(duì)于文本類(lèi)數(shù)據(jù)Fmsg則需通過(guò)文件操作依次讀取數(shù)據(jù)，然后調(diào)用自定義的分詞器Ew和Sw做運(yùn)算后再進(jìn)行分詞。經(jīng)過(guò)上述運(yùn)算最終得到用于構(gòu)建倒排索引的分詞Wu。其中，自定義分詞器Ew和Sw通過(guò)熱更新技術(shù)實(shí)現(xiàn)，從而達(dá)到提升搜索結(jié)果的效率和準(zhǔn)確性的目的，并且通過(guò)實(shí)時(shí)更新分詞器的字典的方式，可以在不重啟應(yīng)用的情況下讓自定義的分詞器更加實(shí)時(shí)地對(duì)文本進(jìn)行分析，以滿(mǎn)足用戶(hù)高效搜索需求。

4 系統(tǒng)應(yīng)用與測(cè)試

4.1 Canal與Logstash 同步時(shí)延對(duì)比

當(dāng)前的主流同步框架為L(zhǎng)ogstash，但其存在時(shí)效性較差、資源消耗高、數(shù)據(jù)二次處理與過(guò)濾能力不足等問(wèn)題。為此，本文提出對(duì)開(kāi)源同步框架Canal 結(jié)合SpringBoot 技術(shù)做優(yōu)化的解決方案。

為驗(yàn)證MTPF 使用的同步技術(shù)性能，設(shè)計(jì)基于2 臺(tái)Intel?Core i7 CPU，16 GB RAM 的計(jì)算機(jī)設(shè)備的同步時(shí)延實(shí)驗(yàn)。其中一臺(tái)安裝MySQL 和ElasticSearch 并完成配置，以提供數(shù)據(jù)支持并實(shí)時(shí)監(jiān)控同步情況；另一臺(tái)分別配置Canal 和Logstash 環(huán)境，并與MySQL 和ElasticSearch 連通。

表1展示數(shù)據(jù)分別在10 000條、100 000條、1 000 000條記錄時(shí)，兩種同步框架的時(shí)延對(duì)比情況。

表1 同步時(shí)延對(duì)比

首先，在大數(shù)據(jù)量同步過(guò)程配置實(shí)時(shí)監(jiān)控文件，跟蹤數(shù)據(jù)變化和ElasticSearch 中索引更新情況。

其次，計(jì)算Canal 的同步時(shí)間為從MySQL 到ElasticSearch 的正常時(shí)間間隔，此時(shí)間間隔使用指數(shù)加權(quán)平均做優(yōu)化；Logstash 的同步時(shí)間為從MySQL 到ElasticSearch 的理想時(shí)間間隔，即當(dāng)前批次數(shù)據(jù)更新結(jié)束，新一輪的批量數(shù)據(jù)立即又開(kāi)啟同步，表1 中Logstash的同步時(shí)延即基于理想間隔完成。正常情況下，Logstash 同步數(shù)據(jù)時(shí)間遵循以下公式：

式中：Tinterval為自定義設(shè)置的Logstash時(shí)間間隔；sp為數(shù)據(jù)更新至MySQL 時(shí)距離上次同步完成的時(shí)間；data 為此時(shí)的數(shù)據(jù)量；Idata表示該數(shù)據(jù)量對(duì)應(yīng)的理想同步時(shí)間。由此可知，若在實(shí)際業(yè)務(wù)場(chǎng)景，Logstash的時(shí)延要更長(zhǎng)。

由表1 分析可知，在數(shù)據(jù)量不大于10 000 條時(shí)，Canal的時(shí)延大于Logstash，說(shuō)明在處理小數(shù)據(jù)量時(shí)Canal的性能并未完全顯現(xiàn)。但是，在數(shù)據(jù)量大于100 000 條之后，Canal 在處理大數(shù)據(jù)量同步上的性能優(yōu)勢(shì)就逐步體現(xiàn)出來(lái)，在1 000 000 條的結(jié)果表明，Canal 也與Logstash 的差距較大。

4.2 Canal和Logstash 的CPU 消耗對(duì)比

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

表2 無(wú)數(shù)據(jù)變化時(shí)的CPU 占有率 %

圖4 系統(tǒng)CPU 占有率對(duì)比

由于在同步任務(wù)中，兩個(gè)框架都需要與MySQL 數(shù)據(jù)庫(kù)交互，因此MySQL 的CPU 平均占有率也可能反映出框架性能情況。表3 為統(tǒng)計(jì)的在執(zhí)行同步任務(wù)過(guò)程中MySQL 的CPU 平均占有率。由表3 可知，在同步過(guò)程中Canal 不僅相對(duì)占用資源少，且對(duì)MySQL 數(shù)據(jù)庫(kù)的負(fù)載也相對(duì)較小。

綜上所述，在使用Canal 作為數(shù)據(jù)同步技術(shù)時(shí)，不僅對(duì)系統(tǒng)資源消耗較少，而且處理效率也較高。特別是面向大數(shù)據(jù)量同步時(shí)，Canal 性能更加明顯，且在未執(zhí)行任務(wù)情況下，也有資源占有率較低的優(yōu)點(diǎn)。對(duì)于在凌晨、節(jié)假日等數(shù)據(jù)變化量不大的情況下，節(jié)約系統(tǒng)資源消耗具有重要意義，這些特性也更加適用于當(dāng)前業(yè)務(wù)場(chǎng)景。

4.3 MySQL 和ElasticSearch 的檢索能力對(duì)比

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

表4 MySQL 與ElasticSearch 的檢索能力對(duì)比

實(shí)驗(yàn)結(jié)果證明：優(yōu)化后的ElasticSearch在當(dāng)前10 000 條數(shù)據(jù)量的條件下的檢索性能是MySQL 的21 倍；而在更大的百萬(wàn)級(jí)數(shù)據(jù)量檢索速度上，ElasticSearch 則具有更顯著的優(yōu)勢(shì)。 因此，可以說(shuō)明優(yōu)化改進(jìn)后的ElasticSearch 無(wú)論在哪個(gè)數(shù)據(jù)量級(jí)上都完全能夠滿(mǎn)足MTPF 使用的搜索要求，可以提供更貼合用戶(hù)語(yǔ)義、更加高效的全文搜索能力。

5 結(jié) 語(yǔ)

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

注：本文通訊作者為魏培陽(yáng)。