为什么公共事业机构会偏爱 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 实现主库集群实时将数据写入到从集群，同时从集群担负报表业务以及研发测试库环境，让我们初步实现了一地两中心的设想。