中文
2023-07-09 11:56:55
随着医院信息管理系统(HIS)的逐步升级与信息平台、科研平台等新业务的上线，医院数据的使用分析从原来的业务辅助，转变成为信息化建设的重要应用。但无论数据库是否采用虚拟化技术承载，或者是否采用容灾、双活等高可靠技术，依然会由于各种不可控因素导致业务暂停或者数据丢失，如何杜绝这类情况？
此外，随着医院业务类型与业务系统数量的增多，集中式数据库不再是医疗数据库的唯一选择，我们也看到了大量分布式数据库在医院崭露头角，医院该如何进行选择和设计？
接下来，我们将围绕大家对于医疗数据库的演进与承载中比较关注的一些问题，进行解析分享。
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）统计并指出“消耗大户”，责任清晰，针对性解决
与传统架构对比
部分用户案例
