作者： 我是人间不清醒原文来源：https://tidb.net/blog/04f1c28f

业务背景

某省妇幼健康管理系统建设内容包括：妇幼健康信息数据库；妇幼健康信息采集系统、妇幼健康信息管理及分析系统；母子健康管理 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 集群，分别对应 报表业务、大屏业务、数据交换服务、数据查询加速。

• 痛点：

• 业务变动频繁：开始为了满足业务需求每周至少 2 次数据库结构变更，经与事业部协商后控制在每周一次变更。变更需要 DBA 对 14 个地市 mysql 、Starrocks 以及数据调度进行调整。

• 服务器资源浪费：Mysql 出于数据安全的考虑是主从架构，从库资源没有得到有效利用。

• 业务更新对业务的影响：应用层面使用微服务架构，涉及到的研发人员较多，研发人员只关注自己的业务模块，通过 sql 审计平台提交 ddl 语句，最后由 DBA 执行，DBA 对业务并不熟悉，无法检查 ddl 语句是否符合实际业务需求。造成平台发布后第二天会出现异常频发的情况（测试环境无法复现的一些问题）。

• 研发与 DBA 人员对 sql 调优技能无法得到提高：由于 mysql 数据 1:1 打到 Starrocks 中，复杂查询全部用 MPP 替代，在 sql 调优，数据表合理拆分方面不再关注（以前感觉这是个好事情，提高研发人员效率），这个问题会在 MPP 瓶颈后统一爆发，只能通过升级服务器配置解决。无法从根本上解决问题。

• DBA 感觉很吃力：这个架构有点废人，按照一周一次的频率，DBA 会在晚上 6 点后业务低峰期进行 ddl 操作，DBA 需要维护 30 套数据库，近 20000 张表。操作完之后，发布程序然后测试再跟进。已经到半夜，如果出现问题在回滚操作，对业务影响较大。

• 数据库按照地市分割对于跨市的业务服务不能很好兼容、如报表只能通过打宽表做数据库汇总后展示（宽表越来越多）以及出现重复档案、跨地市不能查询服务记录等。

• 无法应用自动化数据库审计平台，数据库分散操作复杂，自动化实现难度高。

基于以上的痛点我们在寻找一个更优的技术架构……

数据库合并

寻找一个数据库解决在数据库合并后写入和 Online-ddl 操作得到保证。

先后测试过 Polardb、tidb、OceanBase 最终 选择了 Tidb

tidb 特点

• 高度兼容 MySQL，大多数情况下无需修改代码即可从 MySQL 轻松迁移至 TiDB，即使已经分库分表的 MySQL 集群亦可通过 TiDB 提供的迁移工具进行实时迁移。

• 水平弹性扩展，通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。

• 分布式事务，TiDB 100% 支持标准的 ACID 事务。

• 真正金融级高可用，相比于传统主从（M-S）复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复（auto-failover），无需人工介入。

Tidb 数据库架构介绍

技术架构

新数据库架构

新架构层次划分去掉了 Starrocks 分析层，发挥 Tidb 的 TiFlash 组件 OLAP 功能，数据交换使用 CloudCanal，分析层和业务层进行合并，业务即宽表，统一通过 Tifalsh 进行加速，在运维成本，业务扩展上也带来了极大的提升。

引入 yearning 自动化 sql 审计平台

Yearning 拥有以下功能:

• 自动化 SQL 语句审核, 可对 SQL 进行自动检测并执行

• DDL/DML 语句执行后自动生成回滚语句

• 审核 / 查询 审计功能

• 支持 LDAP 登录 / 钉钉及邮件消息推送

• 支持自定义审核工作流

• 支持细粒度权限分配

• 
  
  

• 

  
  

  
  

“后续有专项培训讲解数据库审计平台”

关于 sql 优化

dba 对监测慢语句逐一记录跟踪反馈与持续优化

分析层改造后收益

将 Starrocks 替换为 Tifalsh 后，整体查询效率（对比按地市分库的 Starrocks）没有明显提升。通过 sql 优化后基本符合预期。

Tidb 和 Starrocks 几个常用查询效果对比（数据量和结构相同）

查询响应时间比较（受限于编辑器 sql 贴的图片）

自带监控 tidb Dashboard

QPS

SQL 语句分析

慢查询

流量可视化

删库、删表恢复

示例

• 恢复被 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 实现主库集群实时将数据写入到从集群，同时从集群担负报表业务以及研发测试库环境。

pt-kill 应用针对捕获正在运行中的 SELECT|ALTER 等 DML/DDL 消耗资源过多的查询，过滤它们，然后杀死它们（可选择不杀）且发邮件 / 微信报警给 DBA 和相关开发知悉，避免因慢 SQL 执行时间过长对数据库造成一定程度的伤害。

https://github.com/hcymysql/pt-kill

后台运行

shell> nohup php pt-kill.php -u username -p pwd -h 10.10.159.0 -P 3306 -B 10 -I 15 –match-info=‘select|alter’ –match-user=‘dbuser’ –kill –mail –weixin –daemon 1 &

杀死的慢语句会在后台日志文件中进行保留，下一步要对 sql 进行优化。

新架构效果说明

服务器资源合理利用

人力成本的释放

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

运维成本的降低

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

未来规划

目前我们有两套数据架构 mysql+starrocks 和 Tidb 这两套架构各有优势（也可以结合使用），结合事业部需求，根据不同业务线需求去确定使用那套架构。