零售业大规模场景中 ToC 系统的数据库选择和迁移实践
原文来源:https://tidb.net/blog/c53c672f
作者 | 云盛海宏 ToC 业务团队 崔文涛,邓有才
云盛海宏是一家零售业科技公司,以科技的力量为门店和线上客户打造 360 度的优秀体验,目前服务中国 6000 余家的线下门店和千万级别的线上会员。云盛海宏的 To C 系统分为私域商城和会员营销两条业务线,它为 7000 多万注册会员提供了丰富的权益和服务,是我们非常核心的系统。
选型背景
随着近几年消费模式的升级,我们和消费者的互动与服务从传统线下逐渐延展至线上,使得 To C 系统的能力和规模越来越大,其数据库压力也越来越大。
最初在建设 To C 系统时,业务库主要使用 MySQL,既有单库架构,也有分库分表架构,时至今日我们面临的问题主要如下:
- 分库分表不合理导致的数据倾斜,某个分片负载居高不下,且难以动态调整
a. 分库分表规则为品牌名称,而不同品牌之间数据规模、用户规模有较大差异
b. 需要针对大分片再次进行二次拆分才能解决该问题,但同时复杂度将大幅提升
- 个别单库架构的 MySQL,数据增长远超预期,单表数据量过大,性能问题凸显
a. 数据量千万级以上表:87 张;亿级以上表:21 张
b. 需要将单库架构改造成分库分表架构才能解决
以上两个问题均需要大幅调整数据库架构来解决,解决成本高(人力、硬件),并且未来还可能再次面临这样的问题。为彻底解决以上问题,我们计划直接切换到原生分布式数据库 TiDB:
- TiDB 兼容 MySQL 协议,并且是原生分布式,无需规划分片规则,对应用友好,能够很好的解决之前分库分表数据倾斜的问题
- TiDB 架构下提供的动态水平扩展、热点自动调度等能力,大幅简化了一系列运维成本,能够支撑应用规模持续的增长,即使数据增长超过预期也能动态增加节点解决
- 另外我们的零售系统在去年成功切换到 TiDB,也给了我们团队很大的信心
数据库测试方案
对于数据库的切换我们比较关心以下几个问题:
- 迁移数据的完整性:数据是企业的核心资产,不容许丢失
- SQL 兼容性及性能:这意味着我们迁移改造的成本
- 资源隔离能力:多个业务库合并后如何保障其服务质量
测试目的:识别关键问题,基于测试结果完善应用改造
测试一:迁移数据的完整性
数据同步
TiDB 提供 DM 数据同步工具,该工具支持 MySQL 全量、增量数据的同步,同时也支持分库分表的合并。对于分库分表的合并,我们的任务策略如下:
数据比对
为确保 DM 数据同步工具的可靠性,在切换过程中需要进行数据一致性校验。实测数据比对效率较高,能够达到 400MB/s 以上的全量比对速度,以下是数据比对映射关系:
测试二:SQL 兼容性及性能
针对生产的全量 SQL 语句进行兼容性以及性能的测试,靠人力手工完成测试是不现实的,所以我们引入了 Percona 开源的 playback 工具进行测试。
playback SQL 回放工具经验分享
playback 工具介绍
**项目地址:**https://github.com/Percona-Lab/query-playback.git
- **SQL 录制:**MySQL 数据库在开启慢查询功能时,会将慢 SQL 输出到慢查询日志
- **SQL 回放:**playback 工具解析慢查询文件中的 SQL,并连接到目标数据库进行回放
- 报告展示: 回放完成会输出报告(执行失败的 SQL 含结果不一致等、性能数据)
实际测试流程
由于我们是存在分库分表架构,而 TiDB 中存储的都是单表,所以我们步骤进行了一些调整:
- SQL 录制: 将生产 MySQL 库的 long_query_time 设置为 0,运行一个业务周期(一天),记录一天内所有 SQL(样本数越大测试结果越准确)
- SQL 处理:部分慢查询日志未记录 schema 信息,通过脚本指定 schema(还存在将 db_1 映射成 db 这样的 schema 转换)
- SQL 回放: 指定慢查询回放整个业务周期运行的 SQL 语句
回放结果分析
测试结果汇总
由于私域商城大表十分多,所以性能提升非常明显,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 秒以上 时基本上用户感知非常明显。
通过详细性能分析数据以及 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 识别出来,进行分析和优化
以上为会员运营中 SQL 性能数据桑基图,如红色箭头以及红色框的这些 SQL,需要重点分析
以上为会员运营中原本 10 秒以上 SQL 性能变化
4. 私域商城的 SQL 性能提升很明显,100ms 内 SQL 数量均高于 MySQL,同时 1s 以上的 SQL 少于 MySQL,说明用户体验提升明显。但还是需要根据桑基图来分析是否存在异常的 SQL
以上为私域商城系统 SQL 性能桑基图,红框对应的 SQL 应该重点分析
以上为私域商城原本 10 秒以上 SQL 性能变化
测试三:资源隔离能力
资源隔离能力在我们这边的用途:
- 应用监控等定时调度操作往往比较复杂,如何限制其运行时的资源消耗
- 客户端数据查询场景难以避免 SQL 条件不规范的情况,当出现这种情况时,如何避免人工查询导致的系统不可用
<!---->
- 当某个系统中出现一个大查询时,如何限制其资源消耗,避免对该应用、对整个集群造成影响
- 当某个系统中批量调度作业到白天还没跑完时,如何限制其资源消耗,避免对白天业务造成影响
<!---->
- 系统间资源隔离:多个 MySQL 库上的应用系统合并到一个 TiDB 时,如何保障各个系统在业务高峰期的可用资源
- 系统内资源隔离:
- 其他场景的资源隔离
为解决以上几种问题,需要使用 TiDB 7.1 LTS 提供的 Resource Control 功能,该功能能够实现:
- 按用户设置资源规格
- 按会话设置资源规格
- 按 SQL 设置资源规格
以下是用户级别测试效果:
为数据库压测用户指定其 RU 为 500,并使用 Jmeter 压测应用,观察 TiDB 数据库是否能够限制资源,并且在达到资源限制时,应用是否报错。
该用户在达到 500RU 时,使用值轻微超过限制值,基本符合预期。
应用改造
分页 SQL 增加排序条件
这也是几乎所有的 MySQL 系统迁移到 TiDB 会遇到的问题:
- 当 SQL 中无显示排序条件时,返回结果无顺序保障,这将导致分页结果不可靠
我们大概梳理了系统中存在的分页 SQL,大概 1600 余条,最终改造 + 测试工作量约 2 个月
性能退化的 SQL 优化
如特定的表关联方式,执行计划是全表扫描
改写成
从分库分表处理逻辑改成单库处理逻辑
业务 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,整体运行良好。
1.8 日某品牌大促,业务量是平时的一倍,数据库最大 QPS 6.5 万,P95 响应延迟 3.9-4.5ms 之间:
以下是切换 TiDB 的整体流程,可以看到切换到 TiDB 后了简化了其架构:由于 TiDB 无需设置分片规则,数据都在一个集群中,原本综合库(MySQL 单库)上的查询也直接切到 TiDB
以上为生产切换流程
总结
数据库迁移是一个复杂且高风险的工程,迁移前规划一个全面的测试方案必不可少,提前识别迁移风险,大幅降低迁移后的风险,当然像分阶段迁移、回退链路等保障措施也及其重要。
年后我们将继续把会员运营系统(20 个 MySQL 库)切换至 TiDB,实现 To C 系统从 MySQL 40 个库到 TiDB 的整体切换,支撑未来持续增长的数据规模。
上一篇: 完全免费白嫖 GPT-4 的终极程序!
下一篇: 领事,你的时间不多了。
推荐阅读
-
反传销网8月30日发布:视频区块链里的骗子,币里的韭菜,杜子建骂人了!金融大V周召说区块链!——“一小帮骗子玩一大帮小白,被割韭菜,小白还轮流被割,割的就是你!” 什么区块链,统统是骗子 作者:周召(知乎金融领域大V,毕业于上海财经大学,目前任职上海某股权投资基金合伙人) 有人问我,区块链现在这么火,到底是不是骗局? 我的回答是: 是骗局。而且我并不是说数字货币是骗局,而是说所有搞区块链的都是骗局。 -01- 区块链是一种鸡肋技术 人类社会任何技术的发明应用,本质都是为了提高社会的生产效率。而所谓区块链技术本质不过是几种早已成熟的技术的大杂烩,冗余且十分低效,除了提高了洗钱和诈骗的效率以外,对人类社会的进步毫无贡献。 真正意义上的区块链得包含三个要素:分布式系统(包括记账和存储),无法篡改的数据结构,以及共识算法,三者互为基础和因果,就像三体世界一样。看上去挺让人不明觉厉的,而经过几年的瞎折腾,稍微懂点区块链的碰了几次壁后都已经渐渐明白区块链其实并没有什么卵用,区块链技术已经名存实亡,沦为了营销工具和传销组织的画皮。 因为符合上述定义的、以比特币为代表的原教旨区块链技术,是反效率的,从经济学角度来说,不但不是一种帕累托改进,甚至还可以说是一种帕累托倒退。 原教旨区块链技术的效率十分低下,因为要遍历所有节点,只能做非常轻量级的数据应用,一旦涉及到大量的数据传输与更新,区块链就瞎了。 一方面整条链交易速度会极慢,另一方面数据库容量极速膨胀,考虑到人手一份的存储机制,区块链其实是对存储资源和能源的一种极大的浪费。 这里还没有加上为了取得所谓的共识和挖矿消耗的巨大的能源,如果说区块链技术是屎,那么这波区块链投机浪潮可谓人类历史上最大规模的搅屎运动。 区块链也验证不了任何东西。 所谓的智能合约,即不智能,也非合约。我看有人还说,如果有了智能合约,就可以跟老板签一份放区块链上,如果明年销售业绩提升30%,就加薪10%,由于区块链不能篡改,不能抵赖,所以老板必须得执行,说得有板有眼,不懂行的愣一看,好像还真是那么回事。 但仔细一想,问题就来了。首先,在区块链上如何证明你真的达到了30%业绩提升?即便真的达到老板耍赖如何执行? 也就是说,如果区块链真这么厉害,要法院和仲裁干什么。 人类社会真正的符合成本效益原则的是代理制度。之前有人说要用区块链改造注册会计师行业,我不知道他准备怎么设计,我猜想他思路大概是这样的,首先肯定搞去中心化,让所有会计师到链上来,然后一个新人要成为注册会计师就要所有会计师同意并记录在链上。 那我就请问了,我每天上班累死累活,为什么还要花时间去验证一个跟我无关的的人的专业能力?最优做法当然是组织一个委员会,让专门的人来负责,这不就是现在注册会师协会干的事儿吗?区块链的逻辑相当于什么事情都要拿出来公投,这个绝对是扯淡的。 当然这么说都有点抬举区块链了,区块链技术本身根本没有判断是非能力,如果这么高级的人工智能,靠一个无脑分布式记账就能实现的话,我们早就进入共产主义社会了。 虽然EOS等数字货币采用了超级节点,通过再中心化的方式提高效率,有点行业协会的意思,是对区块链原教旨主义的一种修正,但是依然无法突破区块链技术最本质的局限性。有人说,私有链和联盟链是区块链技术的未来,也是扯淡,因为区块链技术没有未来。如果有,说明他是包装成区块链的伪区块链技术。 区块链所涉及的所有底层技术,不管是分布式数据库技术,加密技术,还是点对点传输技术等,基本都是早已存在没什么秘密可言的技术。 比特币系统最重要的特性是封闭性和自洽性,他验证不了任何系统自身以外产生的信息的真实性。 所谓系统自身产生的信息,就是数据库数据的变动信息,有价值的基本上有且只有交易信息。所以说比特币最初不过是中本聪一种炫技的产物,来证明自己对几种技术的掌握,你看我多牛逼,设计出了一个像三体一样的系统。因此,数字货币很有可能是区块链从始至终唯一的杀手应用。 比特币和区块链概念从诞生到今天已经快10年了,很多人说区块链技术在爆发的前夜,但这个前夜好像是不是有点过长了啊朋友,跟三体里的长夜有一拼啊。都说区块链技术像是90年代初的互联网,可是90年代初的互联网在十年发展后,已经出现了一大批伟大的公司,阿里巴巴在99年都成立了,区块链怎么除了币还是币呢? 正规的数字货币未来发展的形式无外乎几种,要么就是论坛币形式,或者类似股票的权益凭证等。问题是论坛币和股票之前,本来也都电子化了,区块链来了到底改变了什么呢? 所有想把TOKEN和应用场景结合起来的人最后都很痛苦,最后他们会发现区块链技术就是脱裤子放屁,自己辛苦搞半天,干嘛不自己作为中心关心门来收钱?最后这些人都产生了价值的虚无感,最终精神崩溃,只能发币疯狂收割韭菜,一边嘴里还说着我是个好人之类的奇怪的话。 因此,之前币圈链圈还泾渭分明,互相瞧不起,但这两年链圈逐渐坐不住了,想着是不是趁着泡沫没彻底破灭之前赶快收割一波,不然可能什么都捞不着了。 前段时间和一个名校毕业的链圈朋友瞎聊天,他说他们“致力于用区块链技术解决数字版权保护问题”,我就问他一个问题,你们如何保证你链的版权所有权声明是真实的,万一盗版者抢先一步把数据放在链上怎么办。他说他们的解决方案是连入国家数字版权保护中心的数据库进行验证…… 所以说区块链技术就是个鸡肋,研究到最后都会落入效率与真实性的黑洞,很多人一头扎进链圈后才发现,真正意义上的区块链技术,其实什么都干不了。 -02- 不是蠢就是坏的区块链媒体 空气币和区块链的造富神话,让区块链自媒体也开始迎风乱扭。一群群根本不知道区块链为何物的妖魔鬼怪纷纷进驻区块链自媒体战场,开始大放厥词胡编乱造。 任何东西,但凡只要和区块,链,分,分布式,记账,加密,验证,可追溯等等这些个关键词沾到哪怕一点点,这些所谓的区块链媒体人就会像狗闻到了屎了一样疯狂地把区块链概念往上套。 这让我想起曾经一度也是热闹非凡的物联网,我曾经去看过江苏一家号称要改变世界的“物联网”企业,过去一看是生产路由器的,我黑人问号脸,对方解释说没有路由器万物怎么互联,我觉得他说得好有道理,竟无言以对。 好,下面让我们进入奇葩共赏析时间,来看看区城链媒体经常有哪些危言耸听的奇谈怪论 区块链(分布式记账)的典型应用是*?? 正如前面所说,真正意义上的区块链分布式记账,不光包括“记”这个动作,还包括分布式存储和共识机制等。而*诞生远远早于区块链这个词的出现,勉强算是“分布式编辑”吧,就被很多区块链媒体拿来强行充当区块链技术应用的典范。 其实事实恰恰相反,*恰恰是去中心化失败的典范,现在如果没有精英和专业人士的编辑和维护,*早就没法看了。 区块链会促进社会分工?? 罗振宇好像就说过类似的话,虽然罗振宇说过很多没有逻辑的话,但这句话绝对是最没逻辑思维的。很多区块链自媒体也常常用这句话来忽悠老百姓,说分工代表效率提高社会进步,而区块链“无疑”会促进分工,他们的理由仅仅是分工和分布式记账都共用一个“分”字,就强行把他们扯到一起。 实际情况恰恰相反,区块链是逆分工的,区块链精神是号召所有人积极地参与到他不擅长也不想掺合的事情里面去。 区块链不能像上帝一样许诺他的子民死后上天国,只能给他们许诺你们是六度人脉中的第一级,我可以赚后面五级人的钱,你处于金字塔的顶端。
-
零售业大规模场景中 ToC 系统的数据库选择和迁移实践