2023年12月，国家卫健委等十部委联合印发《关于全面推进紧密型县域医疗卫生共同体建设的指导意见》（国卫基层发〔2023〕41号），要求在2025年底前全国90%以上的县基本建成布局合理、运行高效、信息共享的紧密型医共体。这不仅是医疗服务体系的结构性重塑，更是对医疗信息化底层架构的一次系统性考验。

在国家政策的顶层部署下，“市级强、乡镇活、村级稳、上下联、信息通”的建设目标被细化落地。每一条“信息通”的背后，是跨越市、乡、村三级的实时数据交互；每一次“上下联”的背后，是需要毫秒级响应的数据库读写请求。

然而现实是：绝大多数县域医共体的IT基础设施规划，都采用超融合承载——应用服务器和数据库混跑，导致数据库的算力和存储性能均不足。当业务量较小时，这种架构尚可接受；当基层HIS覆盖全市数十家乡镇卫生院和数百个村卫生室、百万量级的公共卫生人口数据需要实时汇聚清洗时，数据库运行底座的“天花板”就会从隐性矛盾变成显性瓶颈。

本文记录了某市紧密型县域医共体信息化项目中的一次架构实践：打破“首选超融合承载数据库”的常规，创新性地引入云和恩墨数据库一体机，为核心业务系统构建高性能、高可靠的数据库运行底座。这个决策背后的逻辑是什么？实际表现如何？对于有类似建设需求的架构师和决策者，这份经过测试验证的实践总结，或许能提供一个值得参考的视角。

该市现有常住居民约100万人，市级医疗机构5家、乡镇（街道）卫生院20余家、村卫生室700余个。在国家医共体政策框架下，该市卫健委于2024年正式启动区域医疗信息化互联互通一张网扩面工程建设项目，并在相关文件中明确：以信创超融合+数据库一体机为核心底座，推动县域医疗信息化的整体跨越。

建设目标用一句话概括：通过“人、财、物、业务、药品、信息”的统一管理，提升县域居民的健康获得感，让人们在“家门口”就能解决健康问题。

传统的人口健康信息化水平已无法满足多层次的就医需求，“在家门口解决”的就医格局急需先进的信息技术作为支撑。为此，该市医共体项目明确了建设一个医共体数字底座、一套一体化数据中心、六大类应用中心及N项接口服务的“1+1+6+N”总体框架。其中，一体化数据中心不仅要承载行政、运营等管理数据，更要支撑起全域居民的人口健康资源库、电子健康档案资源库、电子病历资源库和卫生资源信息库。

医共体信息化的主要价值在于：

1. 资源下沉：通过远程诊断资源共享中心，实现医学影像、心电、检验的区域化服务。

2. 医卫融合：打通基层医疗与公共卫生业务，实现数据联动。

3. 效能提升：通过全量采集异构数据，为运营监控和绩效评价提供决策支撑。

1.超融合的优势与局限

在云时代，超融合在县域医共体项目中具有真实的合理性：部署灵活、管理统一、初期成本相对可控。在本项目中，超融合同样作为重要角色存在——应用服务器层采用超融合服务器8台，承载应用服务和一般性计算负载。

但对于数据库工作负载，超融合架构存在一个结构性制约：计算、存储和网络的性能约束。

在计算层，为满足事务处理和数据分析的算力需求，数据库需要高性能的CPU；在存储层，大量数据并行读写需要低延迟、高带宽的I/O能力；在网络层，节点间大量的数据传输需要高吞吐的网络传输能力。

而超融合架构在多数情况下，主要面向用Java开发的应用软件，强调多核扩展性而非单核性能，故采用多核、主频适中的CPU来满足微服务的横向扩展需求。在存储层，因业务数据分离存储（结构化数据存于数据库，非结构化数据存于NAS），故只需满足少量配置类信息访问需求。在网络层，仅需满足用户在前端交互时产生的轻量级数据，一般用万兆网络即可胜任。

尤其对于存储性能，在超融合架构下，数据库的每一次IO请求需要经过：虚拟机 → 虚拟化层（Hypervisor）→ 分布式存储软件 → 物理存储介质。多层软件栈叠加会导致延迟增大、吞吐量下降。在轻载时，这种开销不明显；但当基层HIS进入业务高峰（如乡镇卫生院集中就诊时段），或体检系统批量采集数据时，IO竞争会导致数据库响应时间骤升，直接影响医护人员的操作体验。

总结来说，超融合架构重在虚拟化能力和方便快捷的运维能力，追求低成本与便捷性，与数据库需要的高性能、高稳定性存在结构性差异。这种架构差异决定了：超融合并非数据库负载的理想承载平台。

实际上，在项目前期调研中就发现，超融合架构在大表查询时极易出现“卡顿”现象。这是推动该市做出架构调整的直接原因之一。

2.数据库一体机的核心逻辑

在本案例中，数据库一体机上当前需要承载四个核心业务系统：

上述系统呈现两类典型工作负载：高并发事务型（基层HIS的诊疗操作）和大批量分析型（公共卫生数据汇总、体检数据采集）。数据库引擎涵盖Oracle 与MySQL等多种数据库，在同一套基础设施上需要同时稳定运行。

选用数据库一体机的原因也很简单——专用设备做专业的事，通过数据库一体机构建现代化的数据库云平台：

• IO路径最短：存储与计算通过高速互联网络直连，消除虚拟化层开销；

• 计算资源优化与独占：为数据库配置更高能力的CPU，数据库独占计算、内存和存储资源，无需与其他工作负载竞争；

• 协议层优化：针对数据库读写协议进行专项优化，传统超融合无法实现；

• 数据库云平台：通过数据库一体机构建数据库云平台，可以实现从数据库到操作系统再到硬件的全栈统一管理，实现数据库平台现代化。

对于医共体这类高并发、数据类型复杂、业务连续性要求高的场景，数据库一体机在性能密度和可靠性上的优势，相较于超融合就显得尤为重要了。

3.信创合规：短期稳定与长期演进的平衡

该项目另一个重要考量是信创合规。在当前“安全可控过渡期”，决策层需要同时满足两个目标：

• 短期：保障项目稳定、顺利上线，现有Oracle / MySQL系统不做大规模改造；

• 长期：最小化改造投入，为后续国产数据库替换预留空间。

这就要求所选方案具备多库兼容能力，既能承载Oracle RAC和MySQL集群，又能为达梦、人大金仓等国产数据库提供同等级别的一体化承载。单独采购两套异构基础设施显然不划算，而具备这种全栈支持能力的数据库一体机，成为平衡当下与未来的最优解。

基于上述分析和考量，该市最终决定从实际需求与目标出发，选择数据库一体机作为核心数据库的运行平台。这种选型思路也使得云和恩墨的zData X走入了用户的视线。

1.硬件拓扑

本项目选用云和恩墨zData X数据库一体机的“2+3”典型配置，由以下节点紧密耦合构成：

计算节点（2台），配置高核心数CPU与大内存，满足数据库集群的强计算需求。

存储节点（3台），配置大容量全闪存硬盘，满足医共体系统稳健支撑、敏捷响应、良好体验的总体目标。

网络节点（2台），配置32端口100GbE交换机，支持RoCE协议，双电源冗余，消除计算与存储之间的通信瓶颈。

关于存储容量：3台存储节点，每台8块3.84TB NVMe SSD，采用两副本策略，实际可用存储空间不低于35TB，满足四大业务系统的当前容量需求及近期扩容预留。

2.软件平台

硬件之上，zData X通过分布式存储软件将上述节点池化为统一的高性能资源池，并提供三层软件能力：

1) 分布式存储池化：通过多副本机制保障数据可靠性，支持热插拔（单节点故障不影响业务）、横向扩展（性能随节点增加近似线性提升）。

2) 数据库SQL优化：基于云和恩墨多年数据库服务经验沉淀的产品化能力，结合Oracle和MySQL的典型负载特征，对SQL执行路径、索引使用及查询策略等进行系统性优化，显著提升整体性能效率，这是纯硬件堆叠无法实现的差异化价值。

3) 一站式管理平台：覆盖操作系统、集群、分布式存储、数据库的全栈统一管理：

- 实时监控与告警：从不同维度对数据库运行指标进行监控和性能分析，支持多种通知方式；

- 智能巡检：可配置巡检周期，直观展示健康评分、问题统计和处理建议，相当于为数据库建立“每日体检”；

- 性能容量分析：快速定位数据库可能存在的问题，给出专业处理意见；

- 高可用管理：支持手动/定时快照及存储克隆，快速支持开发测试、容灾测试等场景。

对于缺乏专职DBA的县域机构，这套管理平台的价值在于：将数据库运维从依赖个人经验，转变为可规范化、可自动化的管理体系。

zData X数据库一体机产品架构图

3.多库兼容与信创适配及未来扩展

zData X在本项目中实际承载了Oracle RAC集群和MySQL集群，同时通过增加计算节点，在未来还可以承载更多业务系统的国产数据库，如达梦、人大金仓、MogDB、openGauss、OceanBase、GaussDB等。

在操作系统和处理器适配上，支持麒麟、统信、欧拉等国产OS，兼容海光、鲲鹏等国产处理器架构。当未来信创改造推进时，这套基础设施无需更换硬件，仅需在软件层面完成数据库迁移，真正实现“最小化改造”的长期目标。

为了验证数据库一体机的实际效能，项目组开展了详尽的硬件及系统测试。以下精炼的部分数据验证了该方案为项目带来的显著价值。

1.存储性能表现（FIO基准测试）

测试环境：2台计算节点，通过RoCE 100GbE交换机与3台存储节点互连，测试工具FIO，测试数据为两台计算节点并行测试的结果之和。

从以上数据库可以看出：4K随机读IOPS为436.6万，延迟约0.13ms。8K随机读带宽达到31.8GB/s，1M顺序读带宽突破34.7GB/s。在医共体业务场景中，基层HIS的事务负载以8K随机读写为主；体检数据批量采集以大块顺序写为主。上述测试结果表明，在这两类典型工作负载下，系统均具备充裕的性能储备。

注：FIO测试在专用测试环境下进行，实际生产环境的可用性能受数据库配置、业务负载特征、网络状态等因素影响。 

2.Oracle数据库性能测试

大表空间创建测试：

并行查询性能测试：对177GB大表在单个计算节点上开展不同并行度的全表扫描测试

公共卫生系统中的人口健康数据汇总、体检历史数据清洗等操作，涉及大量全表扫描。从以上数据可以看到，原来需要数分钟的数据汇总任务，现在均可压缩至秒级完成，直接提升数据时效性。

对于医共体业务而言，体检日集中采样等业务高峰时段的并发压力远低于此测试条件，系统具备充足的吞吐量储备。 

3.坚如磐石的高可用性

在医共体业务中，连续性要求极高——系统中断意味着基层医疗服务的停摆。测试团队对各类单点故障场景进行了逐一验证。

存储层故障测试：

网络层故障测试：

计算层故障测试：

测试结果显示：在所有单点故障场景下，数据库服务均未中断。IO挂起时间在大多数场景下控制在10秒以内，应用侧无可感知的业务中断，数据无丢失，服务自动恢复。

目前，基层HIS、公共卫生、双向转诊、体检四个核心系统已全部在zData X上线运行。以下是真实的业务反馈：

• HIS响应提速：在超融合架构下，大表查询时曾出现的卡顿现象消失。zData X上线后实测平均读带宽可达18GB/s以上，医护人员在高峰时段的操作等待时间明显缩短。

• 体检数据同步加速：177GB大表数据，在48并行读模式下不到10秒完成查询，解决了以往体检结果数据汇总"跑不动"的问题，数据时效性大幅提升。

• 运维负担降低：zData X提供自动化巡检、健康评分、告警通知等功能，县域医疗机构有限的IT运维人员可以掌握数据库运行状态，无需依赖厂商进行日常巡检。

• 信创路径清晰：当前Oracle / MySQL稳定运行，同时保留了向国产数据库平滑迁移的路径，满足"分两步走"的信创合规要求。

这个项目有一个细节值得记录。

在项目招标前的讨论会上，当有人提出“超融合能不能先凑合跑一段时间”时，信息科负责人的回答是：“我们这次是要用这套系统撑10年的，现在打的基础，决定10年内这张网能不能用起来。”

这个回答揭示了县域医共体IT建设的深层逻辑：一次正确的架构决策，节省的不只是钱，而是未来多年持续“打补丁”的时间和精力成本。

本案例的成功实践也向我们证明：在医共体这种高并发、大数据量的场景下，数据库运行底座的创新是决定项目成效的关键。

对于IT决策者和架构师而言，虽然超融合是通用之选，但在核心业务系统的底层，引入zData X数据库一体机具有显著的战略意义：

• 性能跨越：解决传统架构在IO瓶颈上的“顽疾”，为基层医护人员提供流畅体验。

• 风险受控：通过专用架构实现极致的高可用，降低因系统故障导致的民生舆情风险。

• 信创合规：支持数十种数据库的一体化承载，并兼容主流国产操作系统和处理器，为未来的全栈信创改造打下坚实基础。

该市医共体项目的经验表明，在数据库这个“发动机”层面的投入，是整个医共体信息化体系运转是否顺畅的基础。只有立足于实际的数据库承载需求，敢于打破常规，才能在医疗数字化的浪潮中，打造出真正稳健、高效、面向未来的县域医疗信息平台，从而让上层的业务协同、数据流通、智慧应用真正发挥出价值。