导读
本文介绍了某省妇幼健康管理系统的建设和数据库架构优化的过程。原有的数据库架构使用了 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 后，与按地市分库的 StarRocks 相比，我们发现整体查询效率并未显著提高，经过优化，常用的查询已能够达到预期的性能标准。引入 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 ）同时杀死的慢语句会在后台日志文件中进行保留，等待后续的优化。
删库、删表恢复
在过去的架构下，如果 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 兼容 MySQL 生态，业务可直接使用 MySQL JDBC 进行连接，不用再担心 SQL 语法差异问题。
未来规划
目前我们有两套数据架构 MySQL + StarRocks 和 TiDB，这两套架构各有优势（也可以结合使用），未来我们将结合事业部需求，根据不同业务线需求去确定使用哪套架构。
目录