随着业务从单体医院走向区域级、省级医疗平台，古珀医疗所面对的数据库挑战，也从支撑业务快速上线，逐步转向海量数据存储、实时写入、复杂分析、在线扩展和跨机构数据共享。围绕这些需求，其数据库架构经历了从 MySQL、MongoDB 到 TiDB 的持续演进。目前，TiDB 已应用于区域医疗健康大脑、智慧法医、智慧商保和检验检查互认等核心场景，最大单集群数据规模达到 80TB。
近日，在 TiDB 社区活动宁波站上，古珀科技架构师黄子顺以分享了古珀科技在区域医疗健康大脑等项目中的数据库演进历程与一线实践。
古珀科技的业务与数据场景
古珀科技专注于健康医疗数字化建设，核心能力覆盖医疗数据汇聚治理、数据知识融合和应用场景建设，并通过 XTL、云梯等技术，实现区域医疗数据的实时融合与共享。目前，其业务已覆盖5个省份、15个城市，服务人口超过5500万；在海南项目中，平台已接入133家医院。
围绕医疗数据的汇聚、治理与应用，古珀科技形成了区域医疗健康大脑、数字医共体、智慧商保中心和数据要素运营平台等产品与解决方案。这些业务需要汇聚区域内多家医疗机构的数据，形成居民全周期电子健康档案，并进一步支撑医疗资源管理、公共卫生服务、商业保险和检验检查互认等应用。
相较于一般互联网业务，区域医疗数据平台面临更复杂的数据库需求：数据来自不同医院和业务系统，数据结构与标准存在较大差异；随着项目从单体医院扩展至区域级、省级平台，数据规模会迅速增长至数十TB；数据持续汇聚的同时，还需要进行复杂关联查询和实时统计分析。此外，医疗记录对一致性、安全性和可靠性要求较高，部分数据需要保存30年以上。由于项目通常部署在政务云、健康云或医院私有云中，数据库还必须满足私有化部署、数据不出域及安全合规等要求。
因此，医疗数据库需要解决的并不只是海量数据存储问题，还要同时兼顾高频写入、事务处理、实时分析、弹性扩展和跨机构数据共享。
随着业务规模和应用需求不断变化，古珀科技先后使用或探索了 MySQL、MongoDB、Doris、阿里云 ADB 等数据库方案，并逐步将 TiDB 应用于区域医疗健康大脑、智慧法医、智慧商保和检验检查互认等核心场景。目前，TiDB 已在多个省市区级项目中规模化部署，最大单集群数据规模达到80TB。
这条演进路径并非简单地以一种数据库替代另一种数据库，而是根据不同发展阶段的数据规模、业务负载和部署条件，持续寻找更加匹配的技术方案。
第一阶段：用 MySQL 支撑业务快速上线
业务发展早期，古珀科技主要使用 MySQL。
MySQL 经过了充分的市场验证，采用标准 SQL，生态成熟，团队学习和使用成本较低。对于早期的 MVP 项目，以及数据量只有数百GB的单体医院项目，MySQL 能够较好地满足需求。
随着业务扩展，MySQL 的局限逐渐显现。
一方面，数据库实例数量不断增加，带来了较高的管理和运维成本；另一方面，当表数据规模扩大后，大表 DDL 变更、高并发写入和容量扩展都变得更加困难。
很多医疗项目部署在私有云或政务云环境中，底层存储条件不一定理想。数据库进行结构变更或版本升级时，往往需要协调医院和政务云安排停机窗口，对业务连续性造成影响。
当项目开始从单体医院走向区域医疗平台，数据规模由数百GB增长到几十TB时，依靠单机扩容、主从复制或分库分表已经难以持续应对。
第二阶段：MongoDB 带来灵活性，也带来新的问题
为了支持业务快速迭代，古珀科技随后引入 MongoDB。
MongoDB 的文档模型较为灵活，业务字段发生变化时，不需要频繁进行传统关系型数据库中的表结构变更。这种特性适合需求快速变化的项目，能够降低早期开发和调整成本。
但随着数据应用不断深入，新的问题开始出现。
区域医疗平台不仅需要存储数据，还需要对居民、就诊、诊断、费用、药品和检验检查记录进行关联查询。MongoDB 在复杂关联和分析场景中的使用方式与传统 SQL 存在较大差异，对业务开发人员和数据分析人员提出了更高要求。
与此同时，多副本存储带来的空间消耗，以及复杂查询能力不足，也限制了 MongoDB 在部分核心场景中的进一步使用。
这意味着，灵活的数据模型虽然解决了业务快速变化的问题，却不能完全覆盖区域医疗平台对复杂关系查询和数据分析的需求。
第三阶段：探索分析型数据库与分离架构
随着分析需求增加，古珀科技继续评估 Doris、阿里云 ADB 等分析型数据库方案。
这些产品在分析性能方面具有优势，通过事务处理与分析处理分离，也可以分别承载不同类型的负载。但对于医疗项目而言，架构复杂度和部署环境仍然是必须考虑的问题。
医疗数据通常不能离开指定区域，许多项目要求私有化部署，因此部分云上数据库方案难以使用。与此同时，如果事务数据库和分析数据库完全分离，还需要建设额外的数据同步链路，并处理数据时效性、一致性和运维复杂度等问题。
古珀科技需要的并不只是一个分析速度更快的数据库，而是一套能够同时承载实时写入和分析查询、支持私有化部署，并且能够与现有 MySQL 应用平滑衔接的数据底座。
最终选择 TiDB
经过测试和项目验证，TiDB 逐步进入古珀科技的核心业务系统。其价值主要体现在四个方面。
水平扩展，应对数十TB医疗数据
早期单体医院项目的数据量通常只有300GB至500GB，集中式数据库基本可以满足需求。当项目扩展到区域级和省级平台后，数据量可能快速增长至50TB甚至80TB。
TiDB 采用分布式架构，可以通过增加节点进行水平扩展。业务系统不需要自行处理分库分表，也不需要因为数据增长而大规模改造应用逻辑。
目前，古珀科技最大的 TiDB 单集群数据规模达到80TB。随着医疗数据继续积累，集群仍可根据容量和负载变化进行扩展。
HTAP 同时支撑事务与分析
区域医疗平台首先要接收各医疗机构持续产生的数据，因此需要较强的事务处理和写入能力。数据完成汇聚后，还需要进行治理、统计和分析，因此也需要分析型数据库能力。
TiDB HTAP 架构允许同一份数据同时服务于事务处理和分析查询。TiDB 承载实时写入和事务查询，TiFlash 列存副本用于加速复杂统计与多维分析，从而减少事务库与分析库分离所带来的数据复制和架构复杂度。
兼容 MySQL 生态，降低迁移成本
古珀科技早期积累了大量基于 MySQL 开发的系统和数据库实例。新的分布式数据库如果与 MySQL 生态差异过大，将带来较高的应用改造和团队学习成本。
TiDB 兼容 MySQL 协议和常用 SQL 语法，开发团队可以延续原有的使用习惯，大部分业务系统无需进行大规模修改即可迁移。
滚动升级和在线扩缩容能力也减少了停机维护的需求，更适合医疗系统对业务连续性的要求。
TiCDC 支撑医疗数据实时流动
传统的数据共享通常通过业务接口或采集工具完成。例如，先将数据从一个数据库采集到另一个数据库，再由下游系统读取。这种方式需要维护较多的数据交换链路。
TiCDC 可以捕获数据库中的增量变化，并将数据实时同步至其他集群、机房或第三方系统。在区域医疗项目中，这项能力可以用于跨部门数据共享、异地灾备和数据要素流通。
对古珀科技而言，TiDB 不只是数据存储系统，也逐渐成为医疗数据实时交换体系的重要组成部分。
古珀科技 TiDB 应用四类核心应用场景
区域医疗健康大脑
区域医疗健康大脑需要汇聚区域内各级医疗机构的数据，形成居民全周期健康画像，并支撑医疗资源管理、健康地图和精准决策等应用。其主要挑战包括多源异构、数据规模大、持续高速增长，以及医疗记录不能丢失或错乱。
在海南项目中，平台接入133家医院，TiDB 单集群数据规模达到80TB。TiDB 负责承载海量数据，TiFlash 支撑多维分析，TiCDC 用于数据实时共享，多副本机制则为数据可靠性提供保障。
智慧法医
智慧法医系统连接卫健、公安和民政等部门，覆盖案件勘查、临床鉴定、检验和证据管理等流程。传统方式下，法医或交警可能需要前往医院调取相关材料。平台打通数据后，可以通过案件号远程查询和核验证据，提升跨部门协同效率。
这一场景对数据库提出了多项要求：证据链必须保持一致，案件号需要快速检索，公安与卫健数据需要进行多表关联，医疗记录还要长期可靠保存。
TiDB 的分布式事务、强一致性和关联查询能力，可以支撑案件数据和医疗记录的统一管理。
智慧商保
智慧商保平台服务于快速投保、核保核赔、风险控制和健康服务等业务。保险机构在获得合规授权后，可以结合投保人的相关信息，对其医疗数据进行核验和分析。平台需要处理大量就诊明细写入，并对人员、就诊、费用和诊断记录进行复杂关联。
TiDB 可以承载批量数据写入，结合 TiFlash 进行风险分析，为理赔审核、反欺诈和产品运营提供数据支持。
检验检查互认
检验检查互认旨在减少患者在不同医院之间重复检查。例如，患者在一家医院完成有效期内的检验后，另一家医院可以通过平台调阅并认可相关结果，不必再次进行相同检查。
这一场景需要解决不同医院检验项目名称和单位不统一、跨院历史结果快速查询、长期数据积累以及互认率实时统计等问题。
TiDB 用于保存跨机构检验检查记录，支持医生快速调阅历史数据；TiFlash 用于互认率和重复检查率统计；TiCDC 则支持检验结果在不同系统之间实时同步。
TiDB 带来的实际价值
经过多个项目的落地，TiDB 带来的价值可以概括为四个方面。
一是扩展更加简单。集群可以在线增加或减少节点，业务侧不需要处理分库分表，扩容过程对应用影响较小。
二是数据流动更加实时。TiCDC 支持跨集群、跨云和第三方系统的数据同步，也可以用于数据共享和灾备。
三是容灾备份更加体系化。多副本机制结合 BR 快照和对象存储，为医疗数据安全提供多层保障。
四是开发迁移成本相对可控。MySQL 生态兼容让开发团队不必彻底改变原有使用习惯，分布式事务也能够满足核心业务的一致性要求。
黄子顺表示，没有绝对完美的数据库，只有与当前业务场景更加匹配的组合。MySQL、MongoDB、TiDB 以及其他数据库各有所长，多种技术合理协同，才能构成稳定、可扩展的医疗数据基础设施。