/古珀科技的业务与数据场景/

古珀科技专注于健康医疗数字化建设，核心能力覆盖医疗数据汇聚治理、数据知识融合和应用场景建设，并通过 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 以及其他数据库各有所长，多种技术合理协同，才能构成稳定、可扩展的医疗数据基础设施。