TIDB数据库在某省妇幼业务系统应用的实践

Tiit 475 2024-03-18

业务背景

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

图片1.png

原有数据库架构

image.png

image.png

原有技术架构以及痛点

我们选择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张表。操作完之后，发布程序然后测试再跟进。已经到半夜，如果出现问题在回滚操作，对业务影响较大。

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

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

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

数据库合并

表合计

过10万的表数量

过100万的表数量

过1000万的表数量

792

156

58

5

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

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

tidb特点

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

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

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

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

Tidb数据库架构介绍

image.png

技术架构

image.png

新数据库架构

image.png

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

引入 yearning 自动化sql审计平台

Yearning 拥有以下功能:

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

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

  • 审核/查询 审计功能

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

  • 支持自定义审核工作流

  • 支持细粒度权限分配

  • image.png

  • image.png

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

关于sql优化

image.png

image.png

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

分析层改造后收益

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

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

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

image.png

自带监控 tidb Dashboard

QPS

image.png

SQL 语句分析

image.png

慢查询

image.png

流量可视化

image.png

删库、删表恢复

示例

  • 恢复被 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进行优化。

新架构效果说明

服务器资源合理利用

对比

数据层

处理层

分析层

原架构

10台

2台

3台

新架构

11台

1台

0台

人力成本的释放

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

运维成本的降低

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

未来规划

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


版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。

标签：数据库 数据安全 数据同步 分布式事务 高并发
上一篇:Haproxy 探活 TiDB in Action的设置
下一篇:使用信通院混沌测试工具databench-c对TiDB数据库进行混沌测试的操作
相关文章