李海燕，王樹慶，胡廣勇

北京市醫(yī)療器械檢驗所 （北京 101111）

我所在實驗室信息管理系統(tǒng)（laboratory information management system，LIMS）的使用中遇到了業(yè)務數(shù)據(jù)計算瓶頸，本研究就該現(xiàn)象展開了細致的問題闡述和分析，通過具體案例從業(yè)務層面和數(shù)據(jù)庫技術層面提出了一系列業(yè)務數(shù)據(jù)的優(yōu)化方法，涉及實驗室相關管理經(jīng)驗和數(shù)據(jù)庫技術領域的前沿性研究，并指出了業(yè)務數(shù)據(jù)優(yōu)化工作的難點與重點。

1 LIMS 應用單位簡介

我所是經(jīng)中國合格評定國家認可委員會（CNAS）、中國國家認證認可監(jiān)督管理委員會（CNCA）、原國家食品藥品監(jiān)督管理總局（CFDA）等部門認可授權的一所綜合性醫(yī)療器械產(chǎn)品檢測機構，同時也是原CFDA授權設置的10個國家級醫(yī)療器械質量監(jiān)督檢驗中心之一。目前，我所經(jīng)國家相關部門授權的檢驗項目達1 294項，檢驗范圍涵蓋醫(yī)用電子、醫(yī)用射線、核醫(yī)學、電聲學、體外診斷系統(tǒng)、一次性醫(yī)療產(chǎn)品、醫(yī)用防護用品、醫(yī)用橡膠制品、口腔材料、生物安全柜、電磁兼容、生物相容性和體外循環(huán)及化妝品生物學評價等專業(yè)領域，承擔著全國和北京地區(qū)醫(yī)療器械產(chǎn)品監(jiān)督抽驗檢驗、注冊檢驗、認證檢驗、進出口商品檢驗、委托檢驗、仲裁檢驗等檢測任務。我所先后獲得德國TüV、美國UL、加拿大CSA等國際權威認證機構的認可，為國內醫(yī)療器械產(chǎn)品走向國際市場提供了便捷的檢測技術服務；先后建成國內第一家10 m法醫(yī)療器械電磁兼容實驗室、第一家具備生物安全柜檢驗能力的實驗室、第一家醫(yī)用防護產(chǎn)品檢驗實驗室、第一家經(jīng)CNAS認可的血細胞參考測量實驗室等一批具有國際先進水平的實驗室；先后獲得并加入“北京市重點實驗室”“博士后科研工作站”“中關村開放實驗室”及原“食藥總局高研院現(xiàn)場教學基地”“首都科技條件平臺”。

2 LIMS 簡介

LIMS 是利用計算機網(wǎng)絡將實驗室的實驗儀器連接起來，根據(jù)實驗室管理體系、計算機技術和質量控制體系來建立的信息管理體系，其實現(xiàn)了檢驗數(shù)據(jù)共享、量化考核等功能，從而提高了工作效率，降低了運行成本，促進了實驗室的規(guī)范化管理，為提高實驗室整體管理水平提供了先進的技術支持。

我們根據(jù)多年的LIMS 使用和維護經(jīng)驗總結了單位實驗室信息化管理體系，從LIMS 用戶提出的眾多需求中提煉出新的業(yè)務需求，并進行了全面系統(tǒng)的分析，依托BPM 中間平臺開發(fā)了北京市醫(yī)療器械檢驗所LIMS（BPM_LIMS）。目前，BPM_LIMS 已經(jīng)平穩(wěn)運行了6年，為單位的實驗室管理提供了信息化支持，提高了工作人員的工作效率，在實驗室日常管理中起著重要作用。

3 BPM_LIMS 存在的數(shù)據(jù)問題

近期BPM_LIMS 部分功能經(jīng)常出現(xiàn)服務超時、無法響應、直接報運行錯誤等異常情況，如終止費用核算功能運行超時，無法正常使用，監(jiān)控Oracle 數(shù)據(jù)庫以及硬件服務器發(fā)現(xiàn)，調用該功能模塊后，進入頁面加載的期間，數(shù)據(jù)庫服務器的單個CPU 進程資源占用率為100%，分析其原因為，該功能界面加載中需要數(shù)據(jù)庫運算復雜的SQL 語句，該SQL 語句執(zhí)行的計算量太大，導致單線程計算量超出了硬件CPU 的處理能力，因此導致報送服務超時的錯誤，從而導致頁面加載失敗。

我們分析相關功能模塊，發(fā)現(xiàn)該模塊的功能設計和檢驗過程管理、異常流程管理、費用設置管理、費用樹目錄等模塊耦合度非常高。該功能運行時，需要同時調用、判斷以上4個模塊的各種任務狀態(tài)、費用狀態(tài)以及費用目錄設置界面，在做最后確認動作時，還需要進行批量操作、合作檢驗狀態(tài)、主檢科室終止、輔檢科室任務狀態(tài)、輔檢科室是否終止、調用費用設置、費用設置邏輯判斷、發(fā)送通知等眾多條件判斷才能完成整個數(shù)據(jù)狀態(tài)更新錄入的操作。

我們通過功能梳理和邏輯條件分解，將頁面從原來的集成頁面拆分出來，縮短頁面加載時間，簡化判斷條件，優(yōu)化SQL 語句，解決頁面崩潰問題；通過和業(yè)務部門溝通，做頁面拆分、邏輯簡化處理，緩解了當前的問題，但是并未徹底解決數(shù)據(jù)庫訪問壓力大的問題。

BPM_LIMS 數(shù)據(jù)庫的設計采用了傳統(tǒng)的關系型數(shù)據(jù)庫Oracle RAC 集群模式，可以實現(xiàn)負載均衡和熱備功能。RAC 集群最大的優(yōu)勢在于高可用性，通過使用RAC 可以在一定程度上避免因故障引起的數(shù)據(jù)丟失和非計劃停機，并縮短或排除計劃停機時間，但RAC 并不是高性能的解決方案。Oracle 數(shù)據(jù)庫集群對ERP 類的管理系統(tǒng)存在負載受限的設計缺陷，即集群默認主節(jié)點響應數(shù)據(jù)服務請求，不會將服務請求按照實際業(yè)務量進行負載均衡分散到各節(jié)點。BPM_LIMS 系統(tǒng)屬于ERP 系統(tǒng)類型，且我們的單個SQL 請求數(shù)據(jù)運算量巨大。Oracle 數(shù)據(jù)庫對業(yè)務請求的最小顆粒劃分是以單個SQL 作為最小線程，無法再進行任務拆分。綜合以上兩個方面的原因，我們目前的數(shù)據(jù)運算量大的業(yè)務模塊存在數(shù)據(jù)計算量超出服務器CPU 單核處理能力的問題。

4 業(yè)務數(shù)據(jù)問題分析與解決思路

我們業(yè)務數(shù)據(jù)的特性是數(shù)據(jù)量每年呈增量上漲，每個頁面的查詢、操作都建立在大量數(shù)據(jù)檢索和條件判斷之上，其中，數(shù)據(jù)查詢、統(tǒng)計報表更需要在所有原始數(shù)據(jù)中進行大量復雜計算。目前，我們的原始數(shù)據(jù)還沒有可以拆分的標準。由于不同維度對數(shù)據(jù)的篩選條件千差萬別，沒有一個可以統(tǒng)一分類或分解的指標，導致數(shù)據(jù)量越大，執(zhí)行速度越慢，這一直是LIMS 的數(shù)據(jù)設計痛點，也是系統(tǒng)很多頁面反應速度慢、執(zhí)行效率低的問題根源。我們需要做的是梳理業(yè)務，分析業(yè)務數(shù)據(jù)類型，整理數(shù)據(jù)結構模型，然后提出新的業(yè)務流程和數(shù)據(jù)結構設計模型，重構業(yè)務模型和數(shù)據(jù)模型，才能從根本上解決問題。

首先，我們需要認真分析業(yè)務邏輯復雜、數(shù)據(jù)交叉的功能模塊，從業(yè)務本身的流程規(guī)范和可操作性上進行業(yè)務梳理，然后分析能否簡化業(yè)務流程，分離交叉數(shù)據(jù)，從而避免復雜的邏輯判斷和數(shù)據(jù)計算。如合作任務的異常處理流程，其產(chǎn)生的業(yè)務背景是我們業(yè)務中經(jīng)常出現(xiàn)檢驗樣品需要不同的檢驗科室進行檢驗，并出具相應的檢測結果，形成一份合成的檢驗報告。

在這種合作檢驗的業(yè)務場景下，檢驗任務受理、合同評審、任務分配、檢驗、結果錄入、報告審核、報告簽發(fā)等業(yè)務流程主線的各個節(jié)點都需要與多科室進行合作協(xié)調；此外，樣品入庫、領取、回庫、退庫管理，多科室檢驗費用核算，異常流程處理的暫停、終止等細小的分支管理亦涉及合作協(xié)調；然后就是以上各種業(yè)務場景的所有情況的排列組合；如此映射到BPM_LIMS 的業(yè)務流程中，就會是復雜的業(yè)務邏輯和數(shù)據(jù)交叉計算。如果我們的實際業(yè)務不能進行管理層面的業(yè)務拆分，系統(tǒng)的業(yè)務流程就不可能出現(xiàn)邏輯簡化。

總之，要想簡化BPM_LIMS 的業(yè)務邏輯，就要從管理層面解決問題的源頭——業(yè)務管理模式，管理者和被管理者可能會對此種管理思維模式的轉變產(chǎn)生抵觸，此時需要高層管理者強有力的工作支持。

其次，業(yè)務管理模式改革確立后，根據(jù)新的業(yè)務流程，梳理業(yè)務需求，分析數(shù)據(jù)結構，構建新的數(shù)據(jù)模型。數(shù)據(jù)結構是計算機存儲、組織數(shù)據(jù)的方式，是指相互之間存在一種或多種特定關系的數(shù)據(jù)元素的集合。通常，精心選擇的數(shù)據(jù)結構可以帶來更高的運行或存儲效率[1]。

我們的業(yè)務場景最合適的數(shù)據(jù)庫類型是關系型數(shù)據(jù)庫。在設計開發(fā)過程中，開發(fā)人員通常要同時面對一個或多個數(shù)據(jù)實體進行操作，一般單個數(shù)據(jù)實體首先要分割成多個部分，然后按照結構化的方法再對分割的部分進行規(guī)范化；規(guī)范化以后，每個數(shù)據(jù)表都必須定義好各個字段，再分別存入到多張數(shù)據(jù)表中。此過程較復雜，其優(yōu)點是整個數(shù)據(jù)表的可靠性和穩(wěn)定性都比較高，但一旦存入數(shù)據(jù)后，如果需要修改表結構將會十分困難。

關系型數(shù)據(jù)庫有4個特性（ACID 規(guī)則）：原子性（atomicity）、一致性（consistency）、隔離性（isolation）、持久性（durability），其中十分強調強一致性原則。數(shù)據(jù)按照最小關系表進行存儲，數(shù)據(jù)管理一目了然，這是針對一張數(shù)據(jù)表的情況；如果是多張數(shù)據(jù)表，由于數(shù)據(jù)涉及多張數(shù)據(jù)表，數(shù)據(jù)表之間存在著復雜的關系，隨著數(shù)據(jù)表數(shù)量的增加，數(shù)據(jù)管理會越來越復雜。

數(shù)據(jù)操作的瓶頸出現(xiàn)在多張數(shù)據(jù)表的操作中，而且數(shù)據(jù)表越多此問題越嚴重。一旦面對海量數(shù)據(jù)的處理，效率將會變得很差，特別是遇到高并發(fā)的情況，性能將會下降的非常明顯[2]。想要緩解該問題，只能選擇CPU 處理速度更快、性能更好的計算機，如此雖然可以拓展一些空間，但非常有限，即關系型數(shù)據(jù)庫只具備縱向擴展能力。

最后，選擇合適的關系型數(shù)據(jù)庫以及數(shù)據(jù)庫集群的搭建模式，這也是我們今后引進新平臺、重新開發(fā)BPM_LIMS 需要慎重考慮的難點。關系型數(shù)據(jù)庫常見的有Oracle、SQLServer、DB2、Mysql，除了Mysql，其余的關系型數(shù)據(jù)庫都需要支付費用，個別數(shù)據(jù)庫價格高昂，我們無法承受。即使Mysql 是免費的，但由于其開源的特性，其性能也受到了諸多的限制，并且缺乏強有力的技術支撐。目前，國產(chǎn)數(shù)據(jù)庫的性能以及穩(wěn)定性還有待提高。因此，關系型數(shù)據(jù)中我們可選擇的范圍很窄。

綜上所述，要想解決BPM_LIMS 的數(shù)據(jù)問題，我們的主要精力還需要集中在改善數(shù)據(jù)庫的SQL 性能、優(yōu)化系統(tǒng)的業(yè)務流程兩個方面。往往數(shù)據(jù)的優(yōu)化同高效的檢索算法和索引技術有關，因此，高效的SQL 和算法同樣能給用戶帶來良好的數(shù)據(jù)庫體驗。LIMS 的數(shù)據(jù)分析與優(yōu)化需要我們慢慢探索，通過更多的實際業(yè)務應用場景來檢驗每次優(yōu)化的成果是否最切合實際及最實用。