为什么公共事业机构会偏爱 TiDB ：TiDB 数据库在某省妇幼健康管理系统的应用

导读

本文介绍了某省妇幼健康管理系统的建设和数据库架构优化的过程。原有的数据库架构使用了 StarRocks 作为分析层，但随着业务的发展，这套架构暴露出诸多痛点，不再适应妇幼业务的需求。为解决这些问题，该系统选择了将原有架构中的 StarRocks 替换为 TiFlash 组件，并引入了 Yearning 自动化 SQL 审计平台，提高了运维效率和业务扩展能力。新架构在人力成本释放、运维成本降低等方面取得了显著的成效。

业务背景

某省妇幼健康管理系统建设内容包括：妇幼健康信息数据库；妇幼健康信息采集系统、妇幼健康信息管理及分析系统；母子健康管理 APP、妇幼健康管理与分析 APP 等 62 个功能模块。

原有数据库架构

原有技术架构以及痛点

我们选择 StarRocks 作为分析层，通过 DataX + CloudCanal 的模式实现实时+离线数据同步。随着业务的迭代，这套架构不太适应妇幼业务的发展需要。

架构总体上分为四块，自底向上分别是：

• 数据层：源端数据源主要是 MySQL 为主的关系型数据库。分别搭建 5 套（10 台）主从分别承接 14 个子库和 1 个总库 MySQL 子库 700+表。
• 处理层：使用 CloudCanal+datax 进行实时和离线的数据同步。
• 离线：将报表、大屏、数据交换服务采用离线方式构建 DM 主题数据集市。使用到的就是 Datax 工具结合实现。
• 实时：使用 CloudCanal 将 MySQL 数据 1:1 同步到 Starrocks 中。
• 分析层：分析层会保存计算好的指标数据以及用于加速查询的中间结果数据。
• 业务层：使用 3 台 32C128G 搭建 SR 集群，分别对应报表业务、大屏业务、数据交换服务、数据查询加速。

痛点:

• 业务变动频繁：业务需求导致数据库结构频繁变动，最初每周需变更至少两次。经与事业部协商，现将变更频率控制在每周一次。变更需要 DBA 对 14 个地市 MySQL 、StarRocks 以及数据调度进行调整。
• 服务器资源存在浪费现象：出于数据安全考虑，MySQL 采用主从架构，但目前从库的资源尚未得到充分利用。
• 业务更新对运营的影响：在应用层面，我们采用微服务架构，涉及众多研发人员，他们通常只专注于自己的业务模块。通过 SQL 审计平台，研发人员提交 DDL 语句，然后由 DBA 执行。然而，DBA 可能对具体业务不太熟悉，难以确保所执行的 DDL 语句完全符合业务需求。
• 研发与 DBA 人员对 SQL 调优技能无法得到提高：由于 MySQL 数据 1:1 打到 StarRocks 中，复杂查询全部用 MPP 替代，在 SQL 调优、数据表合理拆分方面不再关注（以前感觉这是个好事情，提高研发人员效率），这个问题会在 MPP 瓶颈后统一爆发，只能通过升级服务器配置解决，无法从根本上解决问题。
• DBA 工作压力巨大：当前架构对 DBA 的工作强度要求较高。根据每周一次的变更频率，DBA 需在晚上 6 点后的业务低峰期执行 DDL 操作，同时负责维护 30 多套数据库和近 20,000 张表。 操作完之后，发布程序然后测试再跟进。 已经到半夜，如果出现问题在回滚操作，对业务影响较大。
• 按地市分割的数据库不利于跨市业务服务的兼容，例如，报表通常需要通过创建宽表来汇总各数据库的数据，这导致宽表数量不断增加。此外，还存在档案重复和无法跨地市查询服务记录等问题。
• 无法应用自动化数据库审计平台，数据库分散操作复杂，自动化实现难度高。

架构选型

数据库合并

在数据库合并后，表的数量分布如下：超过 10 万条数据的表数量为 792 张，超过 100 万条数据的表数量为 156 张，超过 1000 万条数据的表数量为 58 张，以及超过 1 亿条数据的表数量为 5 张。

我们正在寻找一种数据 库解决方案，以确保在数据库合并后，写入操作和在线DDL操作的稳定性和可靠性 。我们对比测试了 PolarDB、TiDB 和 OceanBase 等多个数据库解决方案，最终决定采用 TiDB，其主要特点包括：

• 高度兼容 MySQL，大多数情况下无需修改代码即可从 MySQL 轻松迁移至 TiDB，即使已经分库分表的 MySQL 集群亦可通过 TiDB 提供的迁移工具进行实时迁移。
• 水平弹性扩展，通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
• 分布式事务，TiDB 100% 支持标准的 ACID 事务。
• 真正金融级高可用，相比于传统主从（M-S）复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复（auto-failover），无需人工介入。

新数据库架构

新架构中，我们移除了 StarRocks 分析层，转而利用 TiDB 的 TiFlash 组件来实现 OLAP 功能。数据交换任务现在通过 TiCDC 来执行。分析层与业务层的合并简化了架构，所有业务操作现在都直接在宽表上执行，并由 TiFlash 加速。这一变化显著降低了运维成本并提升了业务扩展性。

分析层改造后收益

在将 StarRocks 替换为 TiFlash 后， 与按地市分库的 S tarR oc ks 相比， 我们发现整体查询效率并未显著提高，经过优化，常用的查询 已能够达到预期的性能标准。引入 TiDB 后，主要带来了以下收益：

引入 Yearning 自动化 SQL 审计平台

在新架构中，我们落地了自动化 SQL 审计平台 Yearning，该平台具备以下功能：

• 自动化 SQL 语句审核，可对 SQL 进行自动检测并执行
• DDL/DML 语句执行后自动生成回滚语句
• 审核/查询审计功能
• 支持 LDAP 登录/钉钉及邮件消息推送
• 支持自定义审核工作流
• 支持细粒度权限分配

分析层迁移到 TiDB 后 ， 我们将原有的 14 套数据库合并为一 套 TiDB， 方便管理，让及时的优化成为了可能。

自带监控的 TiDB Dashboard

我们结合 TiDB Dashboard 的监控结果实现了自动化的监控告警机制，捕获慢 SQL，避免热点的产生。

示例：

• pt-kill 应用针对捕获正在运行中的 SELECT|ALTER 等 DML/DDL 消耗资源过多的查询，过滤它们，然后杀死它们（可选择不杀）且发邮件/微信报警给 DBA 和相关开发知悉，避免因慢 SQL 执行时间过长对数据库造成一定程度的伤害。（ https://github.com/hcymysql/pt-kill ） 同时 杀死的慢 语句会在后台日志文件中进行保留，等待后续的优化。

TiDB Dashboard 部分功能截图 ：

删库、删表恢复

在过去的架构下，如果 DBA 或业务人员不小心进行了危险操作，恢复起来非常困难，只能依托于备份恢复来实现。引入 TiDB 后能够快速 flashback，实现删库删表的恢复。

恢复删除库示例

• 恢复被 DROP 删除的 test 数据库：DROP DATABASE test;FLASHBACK DATABASE test;
• 恢复被 DROP 删除的 test 数据库并重命名为 test1：DROP DATABASE test;FLASHBACK DATABASE test TO test1;

恢复删除表示例

• 恢复被 DROP 删除的表数据：DROP TABLE t;FLASHBACK TABLE t;
• 恢复被 TRUNCATE 的表数据，由于被 TRUNCATE 的表还存在，所以需要重命名被恢复的表，否则会报错表 t 已存在。TRUNCATE TABLE t;FLASHBACK TABLE t TO t1;

备份/还原应用超乎预期

TiDB 提供了 BR 集群快照备份功能，直接将日志备份到 MinIO 中。目前某省妇幼一天两次快照 0 时、12 时，由于备份受限于存储，目前只能保留一天内的快照也未做日志备份。（全量快照+实时日志备份）可保证数据不丢失。BR 还原数据超乎预期，300G 数据还原用时 20 分钟（v7.1.3），官方最新版本 v7.6 最新版本 BR 还原能力提升 10 倍。

一地两中心的尝鲜

考虑到妇幼数据的重要性，在政务云实施搭建一地两中心，通过 TiCDC 实现主库集群实时将数据写入到从集群，同时从集群担负报表业务以及研发测试库环境，让我们初步实现了一地两中心的设想。

新架构效果说明

服务器资源合理利用

人力成本的释放

原架构在数据层和处理层 DBA 人员根据发布周期对数据库进行 DDL 操作以及调整和调度。新架构省去了调度的维护工作同时引入 SQL 审计平台可实现自动化 ddl。但是 DBA 同时需要更加关注 TiDB 的各项指标。

运维成本的降低

TiDB 部署不需要大数据组件的支撑，部署运维都很简单。 TiDB 兼容 MyS QL 生态，业务使用可直接使用 MySQL JDBC 进行连接，不用再担心 SQL 语法差异问题。

未来规划

目前我们有两套数据架构 MyS QL + StarRocks 和 TiDB， 这两套架构各有优势（也可以结合使用），未来我们将结合事业部需求，根据不同业务线需求去确定使用哪套架构。