中文
2023-07-09 11:56:55
隨著醫院信息管理系統(HIS)的逐步升級與信息平臺、科研平臺等新業務的上線，醫院數據的使用分析從原來的業務輔助，轉變成為信息化建設的重要應用。但無論數據庫是否采用虛擬化技術承載，或者是否采用容災、雙活等高可靠技術，依然會由于各種不可控因素導致業務暫?；蛘邤祿G失，如何杜絕這類情況？
此外，隨著醫院業務類型與業務系統數量的增多，集中式數據庫不再是醫療數據庫的唯一選擇，我們也看到了大量分布式數據庫在醫院嶄露頭角，醫院該如何進行選擇和設計？
接下來，我們將圍繞大家對于醫療數據庫的演進與承載中比較關注的一些問題，進行解析分享。
01現在醫療行業數據庫最常見的問題有哪些？
針對數據庫常見問題，深信服做了很多相關調研，醫療行業的數據庫建設一直是三甲醫院比較棘手的問題。
無專職數據庫運維專家
大部分三甲醫院沒有專門的DBA專家來負責數據庫的運維和部署，有的醫院將這部分工作外包給了集成商和軟件廠商，但數據庫的實施與維護并沒有在合同和業務范疇內進行明確，所以也導致了“被動式響應”的問題。當業務不發生宕機或者T1級別（業務不可用）的問題時，數據庫的故障是難以被發現的。
數據庫的性能發揮受限
醫療行業內有一個常見的誤區：很多IT工作者認為數據庫的性能發揮受限于硬件瓶頸，其實不然。從理論上講，單塊NVME的SSD硬盤存儲速度可以達到7GB/S，更是可以在4k+70%隨機讀30%隨機寫的場景下突破百萬IOPS。雖然實際性能發揮達不到理論值，但實際單節點數據庫實例壓測超過200萬TPMC已經是業界常態。醫院的業務效率呈現就像是一個木桶，由多塊木板組成，要重點關注數據庫性能木桶中最短的短板是什么。
醫院的核心業務尤其是HIS，隨著業務量越來越大，合表、并表、字段增加與刪除的操作越來越多，各類業務都要與HIS數據庫進行交互。無論是SQL語句，還是數據庫配置、索引配置等，隨著時間的推移各方面性能都變得越來越差。這樣的問題往往不是突然間爆發的，初期只是感覺性能下降、業務出現卡頓。在不具備數據庫專家的醫院，往往第一反應是迭代硬件或者增加硬件，帶來了大量額外的成本投入。所以大型醫院往往會有自己的數據庫專家，對全員HIS表、字段，包括不同業務如何調閱HIS的SQL語句邏輯等，開展定期的巡檢。
數據庫部署類潛在問題
（1）“人為鎖”
深信服曾經處理過這樣一個問題：某醫院集成平臺的ETL單個抽取任務運行需要40分鐘以上，由于人為撰寫的原因，每次都會涉及到對HIS數據庫的全表掃描以及比對，占用了大量的表資源，導致了大量“人為鎖”的發生，數據庫業務完全無法運行。而這樣的問題，依靠非專業人員難以及時發現，我們當時也是挨個排除了所有其他問題后，才開始排查數據庫，最終確認了問題來源。
（2）主備切換過慢或切換失敗
關系數據庫的高可用機制
在RAC、主從等技術出現之前，有一種很常見的數據庫集群技術，被稱為“冷備”或“主備”（有些廠商會包裝成“熱備”）。具體來說就是兩臺服務器共用同一個磁盤陣列的LUN，數據存放在這個LUN中（稱作“數據卷”）。數據卷同一時間只會被其中一臺服務器（主節點）占用，并且只有主節點上的數據庫實例進程是活動狀態并對外提供服務的。當主節點故障后，備節點才會將數據卷搶占過來并掛載到數據目錄后，再啟動備節點上的數據庫實例進程，替代故障的主節點，恢復對外服務。
數據庫緩存與日志落盤機制
這種技術由于僅僅保證了“塊設備”層面的數據兩邊均可見，類似于主節點異常掉電后，把數據盤拔出來插到備節點上重新啟動。然而目前絕大部分的關系型數據庫，包括Oracle、MySQL、SQL Server、PostgreSQL等，都會采用“數據庫緩存”技術去提升事務處理性能、降低IO開銷，而數據庫緩存實際上是異步落盤的，導致異常掉電后的數據庫系統，其數據文件處于“不一致”的狀態，異常掉電后重啟的數據庫系統，需要讀取日志文件和控制文件，首先修復數據文件的一致性（Recovery），然后才能恢復對外服務。
數據庫不一致，導致無法連接
數據庫啟動的Recovery過程具體需要多長時間，取決于數據緩存中未落盤的臟數據有多少，以及數據文件的“一致性”破壞程度，這個時長是不可控的。深信服處理過的案例中，出現過早上10:30左右業務高峰期主節點故障，直到16:00左右備節點才恢復服務的情況。在另外一些更為嚴重的案例中，我們甚至遇到過因為文件系統落盤機制問題導致的控制文件損壞、數據文件損壞等情況。這類情況下，備節點上的數據庫實例會啟動失敗，導致主備接管失敗。
（3）備份恢復耗時超出預期
高可用集群和異地災備，主要是應對軟硬件失效的問題，對于誤操作導致數據丟失、異常掉電或軟件bug導致數據損壞等問題，主要還是需要通過備份恢復的手段進行修復。深信服在緊急救援過程中，遇到過不少這類型案例，醫院在設計時僅考慮了高可用集群的切換速度，或災備接管的RTO，而忽視了數據丟失或損壞后備份恢復的速度，導致業務系統的恢復時間遠超預期。
在純物理環境中，因為數據庫數據文件的“異步落盤”機制，需要采用數據庫本身的物理備份手段，比如說Oracle RMAN、MySQL XtraBackup等才能100%保證在線備份的有效性。在恢復過程中，如果運行環境可用，一般需要經過備份集傳輸、備份集解包、數據文件恢復、日志文件重放等階段，數據量對恢復耗時影響極大，一般恢復1TB大小的數據庫需要2~3小時，恢復5TB大小的數據庫需要5~6小時；如果運行環境不可用，則還需要重裝操作系統、數據庫軟件、數據庫集群等，導致恢復耗時更長。另外，很多備份軟件、備份一體機之類的產品實際上只管備份不管恢復（或者只管恢復過程中的部分步驟），假如用戶信息化部門對待恢復的數據庫的中高階維護操作不是非常熟悉，無論是自行恢復失敗重試，還是等待供應商安排人員救急，都會拖慢業務恢復速度。
針對業務連續性要求較高的核心業務系統，我們不應該只考慮高可用集群或異地災備的接管時間，而應該把備份恢復的耗時也作為影響RTO目標的關鍵因素進行重點設計，畢竟集群和災備并不能覆蓋所有故障場景，備份恢復才是最終的保底手段。
02近年來醫院的數據庫架構發生了哪些變化，以及變化的原因？
其實分布式數據庫和大數據架構在醫療行業的應用逐漸增多是可以預見的，醫院在上一個十年基本完成了臨床業務系統的建設與使用。但由于分散建設的原因，大量數據是沒有打通的，也存在很多沉沒數據并未有效利用起來。隨著醫院對數據價值的越發重視，一些數據分析應用，比如患者360、患者隨訪、單病種等等，都需要對海量數據進行并聯分析和復雜查詢。以某個真實醫院的科研平臺為例，不僅需要研究傳統病歷數據，還需要研究基因庫、人口庫甚至與地理庫進行聯動。在一些長期病患隨訪中，醫院面臨的數據分析維度會超過10年的周期，所以也帶來了幾個變化：
OLAP類型需求逐漸增多
現在醫院單純數據交易型業務基本已經建設完畢了，大部分都是分析類業務，那么就會涉及到大量的ETL、數據倉庫的搭建。這種場景下會涉及大量的JOIN、多條件以及以組合鍵的方式來做不同的復雜查詢，典型就是科研場景下對多個患者特征（如年齡、性別、病種、處方等）進行聯合查詢，并且醫院對于數據進行統一的轉化與清洗，所以現在越來越多數據平臺（或者數據中臺）采用分布式數據庫來作為ODS層的數據承載。
分布式數據庫的性能與承載優化
實際來看，分布式數據庫承載與集中式的區別非常大，由于采用了分布式架構，數據節點之間要進行頻繁的數據交互、二段提交等額外動作，因此節點與節點之間的網絡時延變得更加重要。且由于OLAP業務其實都是較為復雜的SQL語句調閱，比如數據分析、患者隨訪這樣的場景，所以相較于IO性能，分布式數據庫更為關注IO帶寬的整體性能。
首先就是存儲層面與數據庫層面的算法優化，以某一個開源分布式數據庫為例，其邏輯就存在大量的全表掃描與檢索動作，這也是為什么這個數據庫的資源侵占相較其他的分布式數據庫需求更多的原因。
另外就是海量目錄的檢索與承載優化，比如在臨床數據中心、大數據中心這樣的業務場景里面，檢索條目數往往能突破10億，相較于原來的單一HIS業務上升了幾個數量級；因此在這個環境下，承載優化與小文件讀取、檢索性能就至關重要。
03對于醫院未來的數據庫承載設計上，有什么好的建議與思路？
建議醫院針對數據庫，設置專門的專家崗位來定期開展基礎巡檢與分析工作
因為HIS數據庫和其他的小型業務數據庫差異非常大，基本上每一個新的業務系統上線或者變更，HIS的數據庫任務、語句包括表和字段結構都會有變化，需要實時的監測才能及時發現一些潛在的問題。
HIS業務數據庫的承載設計建議不需要過度提升硬件性能，應重點關注數據庫高可靠性的設計
比如硬件的連續損壞，數據庫主備切換不一致導致數據的異常丟失，或是數據庫備份缺乏校驗與監控機制。深信服之前了解到有的醫院備份網絡曾經中斷了3個月，直到發生邏輯故障準備通過備份回滾時才發現問題。核心是數據庫的可靠機制并不是單一的，醫院要客觀評估遭遇不同事件的風險概率以及應對投入成本，來綜合考慮方案設計。
根據業務邏輯選擇不同類型的數據庫
不要以傳統集中式數據庫的業務邏輯來建設未來新一代HIS或者分布式數據庫，傳統HIS更多圍繞交易型業務，比較關注并發量、性能、穩定性等；而新一代HIS會更加以數據為中心，關注非結構化數據提取、全員的數據治理以及不同場景下的數據效率（例如臨床存在大量T0應用要求，而科研更偏向T+1要求），所以核心是根據業務邏輯選擇不同類別數據庫。而且從外部來看，深信服經過與大量軟件廠商的溝通調研，發現目前新一代HIS都開始逐步支持分布式數據庫，為之后的數據分析與抽取提供更好的架構底座。
04深信服醫療數據庫一體化解決方案
深信服醫療數據庫一體化解決方案是包含數據庫部署、承載、運維、監測與災備的數據庫全棧平臺，底層基于虛擬化與分布式存儲技術提升數據庫的高可靠性，硬件方面則采用了全NVMe+25Gb+RDMA的高規格硬件；搭配數據庫管理平臺實現對數據庫性能指標的360度監測，幫助用戶提前發現業務隱患，保障業務穩定。
相較硬件性能，更加關注業務性能
數據庫性能監控大屏
1. 性能調優效率提升
（1）自動提取SQL執行計劃并圖形化展現
（2）分析并展現鎖等待樹，阻塞任務一鍵終止
（3）持續監測統計關鍵性能指標并圖形化展現例如：資源使用率、IOPS、帶寬消耗、引擎工作效率（緩存命中率、內存排序率、等待事件、長事務等）
2. 輕松溯源，針對性解決
（1）自動定位“慢SQL” ，并給出執行計劃分析
（2）自動發現“異常會話”，并給出會話詳情信息
（3）統計并指出“消耗大戶”，責任清晰，針對性解決
與傳統架構對比
部分用戶案例
