零售业海量场景下 ToC 系统的数据库选型和迁移实践

原创
01/31 00:00
阅读数 11

原文来源:https://tidb.net/blog/c53c672f

作者 | 云盛海宏 ToC 业务团队  崔文涛,邓有才

云盛海宏是一家零售业科技公司,以科技的力量为门店和线上客户打造 360 度的优秀体验,目前服务中国 6000 余家的线下门店和千万级别的线上会员。云盛海宏的 To C 系统分为私域商城和会员营销两条业务线,它为 7000 多万注册会员提供了丰富的权益和服务,是我们非常核心的系统。

选型背景

随着近几年消费模式的升级,我们和消费者的互动与服务从传统线下逐渐延展至线上,使得 To C 系统的能力和规模越来越大,其数据库压力也越来越大。

最初在建设 To C 系统时,业务库主要使用 MySQL,既有单库架构,也有分库分表架构,时至今日我们面临的问题主要如下:

  1. 分库分表不合理导致的数据倾斜,某个分片负载居高不下,且难以动态调整

a. 分库分表规则为品牌名称,而不同品牌之间数据规模、用户规模有较大差异

b. 需要针对大分片再次进行二次拆分才能解决该问题,但同时复杂度将大幅提升

  1. 个别单库架构的 MySQL,数据增长远超预期,单表数据量过大,性能问题凸显

a. 数据量千万级以上表:87 张;亿级以上表:21 张

b. 需要将单库架构改造成分库分表架构才能解决

以上两个问题均需要大幅调整数据库架构来解决,解决成本高(人力、硬件),并且未来还可能再次面临这样的问题。为彻底解决以上问题,我们计划直接切换到原生分布式数据库 TiDB:

  1. TiDB 兼容 MySQL 协议,并且是原生分布式,无需规划分片规则,对应用友好,能够很好的解决之前分库分表数据倾斜的问题
  2. TiDB 架构下提供的动态水平扩展、热点自动调度等能力,大幅简化了一系列运维成本,能够支撑应用规模持续的增长,即使数据增长超过预期也能动态增加节点解决
  3. 另外我们的零售系统在去年成功切换到 TiDB,也给了我们团队很大的信心

数据库测试方案

对于数据库的切换我们比较关心以下几个问题:

  1. 迁移数据的完整性:数据是企业的核心资产,不容许丢失
  2. SQL 兼容性及性能:这意味着我们迁移改造的成本
  3. 资源隔离能力:多个业务库合并后如何保障其服务质量

测试目的:识别关键问题,基于测试结果完善应用改造

测试一:迁移数据的完整性

数据同步

TiDB 提供 DM 数据同步工具,该工具支持 MySQL 全量、增量数据的同步,同时也支持分库分表的合并。对于分库分表的合并,我们的任务策略如下:

image.png

数据比对

为确保 DM 数据同步工具的可靠性,在切换过程中需要进行数据一致性校验。实测数据比对效率较高,能够达到 400MB/s 以上的全量比对速度,以下是数据比对映射关系:

image.png

测试二:SQL 兼容性及性能

针对生产的全量 SQL 语句进行兼容性以及性能的测试,靠人力手工完成测试是不现实的,所以我们引入了 Percona 开源的 playback 工具进行测试。

playback SQL 回放工具经验分享

playback 工具介绍

**项目地址:**https://github.com/Percona-Lab/query-playback.git

image.png

  • **SQL 录制:**MySQL 数据库在开启慢查询功能时,会将慢 SQL 输出到慢查询日志
  • **SQL 回放:**playback 工具解析慢查询文件中的 SQL,并连接到目标数据库进行回放
  • 报告展示: 回放完成会输出报告(执行失败的 SQL 含结果不一致等、性能数据)

实际测试流程

由于我们是存在分库分表架构,而 TiDB 中存储的都是单表,所以我们步骤进行了一些调整:

  • SQL 录制: 将生产 MySQL 库的 long_query_time 设置为 0,运行一个业务周期(一天),记录一天内所有 SQL(样本数越大测试结果越准确)
  • SQL 处理:部分慢查询日志未记录 schema 信息,通过脚本指定 schema(还存在将 db_1 映射成 db 这样的 schema 转换)
  • SQL 回放: 指定慢查询回放整个业务周期运行的 SQL 语句

回放结果分析

测试结果汇总

image.png

由于私域商城大表十分多,所以性能提升非常明显,2524 万条 SQL 的总执行时间约之前的 1/6;而会员运营之前进行过拆分,737 万条 SQL 的执行总时间约之前的 1/2。

错误详情分析:

  • 无业务 SQL 错误,业务 SQL 均兼容
  • 所有错误均为非业务 SQL:如 MySQL 中"show binary logs/status/events"、set 特有变量、系统表查询,或慢查询格式调整时出现的一些格式错误等

<!---->

  • 1 处业务 SQL 错误:“during query: Data too long for column”,原因字段精度不够,调大后解决,其余业务 SQL 均兼容
  • 剩余 1220855 次均为非业务 SQL 的报错:如 MySQL 中"show binary logs/status/events"、set 特有变量、系统表查询,或慢查询格式调整时出现的一些格式错误等

<!---->

  • 会员运营:
  • 私域商城:

兼容性基本没有问题

性能详情分析:

虽然总体执行时间缩短了,但我们还是需要排查下性能退化的 SQL 是哪些,需要保证原本正常的 SQL 还是要处于在一个基本对用户无感知的响应时间范围。

理论上来说,小于 100ms 的 SQL 基本都不影响前端用户的体验,所以分析时可以忽略这一部分的 SQL;而对于 100ms-1s 的 SQL,可能会影响用户体验,需要关注;1 秒以上 时基本上用户感知非常明显。

image.png

通过详细性能分析数据以及 SQL 回放执行总耗时,我们不难发现:

1. 由于 TiDB 是存储计算分离的分布式架构,1000us 内的 SQL 数很少,基础操作(如 show variables/start transaction/set ... 等)执行时间均高于 MySQL;同时另一个极端,大于 10 秒以上的 SQL 数,两个系统在 TiDB 中下降了一个数量级。

2. 通过一些采样分析,我们发现在 TiDB 中一些 commit/rollback 操作的时间也普遍高于 MySQL,个别操作从几百微秒变成几十 / 几百毫秒。查阅了 TiDB 中的事务机制,发现 TiDB 提交成本高于 MySQL,首先是 2PC 跨节点事务,另外就是事务中的脏数据直到 commit 时才开始刷到存储(计算节点 ->存储节点),对于这种类型的 SQL 在性能分析时也可以忽略掉。

3. 我们将样本数据整理成桑基图,将这部分性能退化、并且影响用户体验的 SQL 识别出来,进行分析和优化

image.png

以上为会员运营中 SQL 性能数据桑基图,如红色箭头以及红色框的这些 SQL,需要重点分析

image.png

以上为会员运营中原本 10 秒以上 SQL 性能变化

4. 私域商城的 SQL 性能提升很明显,100ms 内 SQL 数量均高于 MySQL,同时 1s 以上的 SQL 少于 MySQL,说明用户体验提升明显。但还是需要根据桑基图来分析是否存在异常的 SQL

image.png

以上为私域商城系统 SQL 性能桑基图,红框对应的 SQL 应该重点分析

image.png

以上为私域商城原本 10 秒以上 SQL 性能变化

测试三:资源隔离能力

资源隔离能力在我们这边的用途:

  1. 应用监控等定时调度操作往往比较复杂,如何限制其运行时的资源消耗
  2. 客户端数据查询场景难以避免 SQL 条件不规范的情况,当出现这种情况时,如何避免人工查询导致的系统不可用

<!---->

  1. 当某个系统中出现一个大查询时,如何限制其资源消耗,避免对该应用、对整个集群造成影响
  2. 当某个系统中批量调度作业到白天还没跑完时,如何限制其资源消耗,避免对白天业务造成影响

<!---->

  1. 系统间资源隔离:多个 MySQL 库上的应用系统合并到一个 TiDB 时,如何保障各个系统在业务高峰期的可用资源
  2. 系统内资源隔离:
  3. 其他场景的资源隔离

为解决以上几种问题,需要使用 TiDB 7.1 LTS 提供的 Resource Control 功能,该功能能够实现:

  • 按用户设置资源规格
  • 按会话设置资源规格
  • 按 SQL 设置资源规格

以下是用户级别测试效果:

为数据库压测用户指定其 RU 为 500,并使用 Jmeter 压测应用,观察 TiDB 数据库是否能够限制资源,并且在达到资源限制时,应用是否报错。

image.png

该用户在达到 500RU 时,使用值轻微超过限制值,基本符合预期。

image.png

应用改造

分页 SQL 增加排序条件

这也是几乎所有的 MySQL 系统迁移到 TiDB 会遇到的问题:

  • SQL 中无显示排序条件时,返回结果无顺序保障,这将导致分页结果不可靠

我们大概梳理了系统中存在的分页 SQL,大概 1600 余条,最终改造 + 测试工作量约 2 个月

性能退化的 SQL 优化

如特定的表关联方式,执行计划是全表扫描

no-alt

改写成

no-alt

从分库分表处理逻辑改成单库处理逻辑

业务 sql 中存在批量查询、批量更新的场景,调整成按照用户链接维度设置 batchquery

数据回写改造

应用切换到 TiDB 前,需要将 TiDB 的增量数据写回到 MySQL,保障紧急情况下的可回退:

  • 之前是单库的场景,可以直接使用 TiCDC 提供的 mysql sink 完成回写。
  • 分库分表的场景下,TiCDC 并不能直接写 MyCAT 组件;所以我们先将增量数据通过 TiCDC 发送给 Kafka,再消费写入到 MyCAT 下的分片中。

下游订阅改造

TiDB 不兼容 MySQL Binlog,原本的消息订阅链路(Binlog/canal/kafka)需要换成 TiCDC->Kafka 这条链路,TiCDC 提供 canal-json 格式的兼容,消费程序上要基于 TiCDC 的消息格式进行一定的调整。

生产切换效果

我们于双十一之前的两周完成消息中心等系统(4 个 MySQL 库)的切换,切换到 TiDB 后经受住了双十一大批量消息推送的验证,也增强了我们的信心。

在元旦后第一个工作日进行了私域商城系统(16 个 MySQL 库)的切换,切换过程比较顺利。以下是切换后第一个工作日的业务高峰,最大 QPS 4.4 万,P95 响应延迟 3.9ms,整体运行良好。

image.png

1.8 日某品牌大促,业务量是平时的一倍,数据库最大 QPS 6.5 万,P95 响应延迟 3.9-4.5ms 之间:

image.png

以下是切换 TiDB 的整体流程,可以看到切换到 TiDB 后了简化了其架构:由于 TiDB 无需设置分片规则,数据都在一个集群中,原本综合库(MySQL 单库)上的查询也直接切到 TiDB

image.png

以上为生产切换流程

总结

数据库迁移是一个复杂且高风险的工程,迁移前规划一个全面的测试方案必不可少,提前识别迁移风险,大幅降低迁移后的风险,当然像分阶段迁移、回退链路等保障措施也及其重要。

年后我们将继续把会员运营系统(20 个 MySQL 库)切换至 TiDB,实现 To C 系统从 MySQL 40 个库到 TiDB 的整体切换,支撑未来持续增长的数据规模。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部