为什么公共事业机构会偏爱 TiDB :TiDB 数据库在某省妇幼健康管理系统的应用
导读
本文介绍了某省妇幼健康管理系统的建设和数据库架构优化的过程。原有的数据库架构使用了 StarRocks 作为分析层,但随着业务的发展,这套架构暴露出诸多痛点,不再适应妇幼业务的需求。为解决这些问题,该系统选择了将原有架构中的 StarRocks 替换为 TiFlash 组件,并引入了 Yearning 自动化 SQL 审计平台,提高了运维效率和业务扩展能力。新架构在人力成本释放、运维成本降低等方面取得了显著的成效。
业务背景
某省妇幼健康管理系统建设内容包括:妇幼健康信息数据库;妇幼健康信息采集系统、妇幼健康信息管理及分析系统;母子健康管理 APP、妇幼健康管理与分析 APP 等 62 个功能模块。
![](https://static001.geekbang.org/infoq/96/968bd6b9dd4219118f713dbcc100d1d6.png)
原有数据库架构
![](https://static001.geekbang.org/infoq/60/60852d8caf4af65ab3ae1d59c0c0a74c.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/6d/6d64a5f999698b90f369ffc278488a8a.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
原有技术架构以及痛点
我们选择 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 张。
![](https://static001.geekbang.org/infoq/dc/dc45a13ee554ebed667d07423b334dc4.png)
我们正在寻找一种数据 库解决方案,以确保在数据库合并后,写入操作和在线 DDL 操作的稳定性和可靠性 。我们对比测试了 PolarDB、TiDB 和 OceanBase 等多个数据库解决方案,最终决定采用 TiDB,其主要特点包括:
高度兼容 MySQL,大多数情况下无需修改代码即可从 MySQL 轻松迁移至 TiDB,即使已经分库分表的 MySQL 集群亦可通过 TiDB 提供的迁移工具进行实时迁移。
水平弹性扩展,通过简单地增加新节点即可实现 TiDB 的水平扩展,按需扩展吞吐或存储,轻松应对高并发、海量数据场景。
分布式事务,TiDB 100% 支持标准的 ACID 事务。
真正金融级高可用,相比于传统主从(M-S)复制方案,基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证,且在不丢失大多数副本的前提下,可以实现故障的自动恢复(auto-failover),无需人工介入。
![](https://static001.geekbang.org/infoq/2a/2a21c101bf8cd824dbec3cbca638b3e4.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
新数据库架构
![](https://static001.geekbang.org/infoq/45/4509691582e9e0a5f8f699cc212d536a.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/b8/b888e05562154d1a98e938eea650d95f.png)
新架构中,我们移除了 StarRocks 分析层,转而利用 TiDB 的 TiFlash 组件来实现 OLAP 功能。数据交换任务现在通过 TiCDC 来执行。分析层与业务层的合并简化了架构,所有业务操作现在都直接在宽表上执行,并由 TiFlash 加速。这一变化显著降低了运维成本并提升了业务扩展性。
分析层改造后收益
在将 StarRocks 替换为 TiFlash 后, 与按地市分库的 S tarR oc ks 相比, 我们发现整体查询效率并未显著提高,经过优化,常用的查询 已能够达到预期的性能标准。引入 TiDB 后,主要带来了以下收益:
引入 Yearning 自动化 SQL 审计平台
在新架构中,我们落地了自动化 SQL 审计平台 Yearning,该平台具备以下功能:
自动化 SQL 语句审核,可对 SQL 进行自动检测并执行
DDL/DML 语句执行后自动生成回滚语句
审核/查询审计功能
支持 LDAP 登录/钉钉及邮件消息推送
支持自定义审核工作流
支持细粒度权限分配
![](https://static001.geekbang.org/infoq/ea/ea89f5461fcb82ace22c34077274444e.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
![](https://static001.geekbang.org/infoq/a7/a7608dceb3bc9fe8c36e3c6fc2619558.jpeg?x-oss-process=image%2Fresize%2Cp_80%2Fauto-orient%2C1)
分析层迁移到 TiDB 后 , 我们将原有的 14 套数据库合并为一 套 TiDB, 方便管理,让及时的优化成为了可能。
自带监控的 TiDB Dashboard
我们结合 TiDB Dashboard 的监控结果实现了自动化的监控告警机制,捕获慢 SQL,避免热点的产生。
示例:
pt-kill 应用针对捕获正在运行中的 SELECT|ALTER 等 DML/DDL 消耗资源过多的查询,过滤它们,然后杀死它们(可选择不杀)且发邮件/微信报警给 DBA 和相关开发知悉,避免因慢 SQL 执行时间过长对数据库造成一定程度的伤害。( https://github.com/hcymysql/pt-kill ) 同时 杀死的慢 语句会在后台日志文件中进行保留,等待后续的优化。
TiDB Dashboard 部分功能截图 :
![](https://static001.geekbang.org/infoq/40/40a5f8ca171737ff756f5d14a33fc456.png)
![](https://static001.geekbang.org/infoq/04/04093abb5c48afceb225e876b5710d53.png)
![](https://static001.geekbang.org/infoq/99/9919210f9a070503ef20fc051b6a5d4d.png)
![](https://static001.geekbang.org/infoq/06/062e48115c66ecfbfc05a5c294a08e0b.png)
删库、删表恢复
在过去的架构下,如果 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 实现主库集群实时将数据写入到从集群,同时从集群担负报表业务以及研发测试库环境,让我们初步实现了一地两中心的设想。
新架构效果说明
服务器资源合理利用
![](https://static001.geekbang.org/infoq/d9/d9aaa13addc15c2bf11c20b3450a12f1.png)
人力成本的释放
原架构在数据层和处理层 DBA 人员根据发布周期对数据库进行 DDL 操作以及调整和调度。新架构省去了调度的维护工作同时引入 SQL 审计平台可实现自动化 ddl。但是 DBA 同时需要更加关注 TiDB 的各项指标。
运维成本的降低
TiDB 部署不需要大数据组件的支撑,部署运维都很简单。 TiDB 兼容 MyS QL 生态,业务使用可直接使用 MySQL JDBC 进行连接,不用再担心 SQL 语法差异问题。
未来规划
目前我们有两套数据架构 MyS QL + StarRocks 和 TiDB, 这两套架构各有优势(也可以结合使用),未来我们将结合事业部需求,根据不同业务线需求去确定使用哪套架构。
评论