9
16
13
7
专栏/.../

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

 我是人间不清醒  发表于  2024-03-13

业务背景

某省妇幼健康管理系统建设内容包括:妇幼健康信息数据库;妇幼健康信息采集系统、妇幼健康信息管理及分析系统;母子健康管理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、OceanBase 最终 选择了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 这两套架构各有优势(也可以结合使用),结合事业部需求,根据不同业务线需求去确定使用那套架构。

9
16
13
7

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论