本文分享了三家企业通过将数据库从 MySQL 迁移至 TiDB，实现了显著的性能提升和扩展性增强的经验。云盛海宏解决了数据倾斜和负载问题，骏伯网络优化了资源利用率，企查查提升了数据流转效率。让我们一起来看下 TiDB 是如何展现其在处理大规模数据和高并发场景的优势吧！
01
MySQL 到 TiDB 迁移实践：
云盛海宏零售业海量场景下 ToC 系统的
选型思考与经验分享
选型背景
随着近几年消费模式的升级，我们和消费者的互动与服务从传统线下逐渐延展至线上，使得 To C 系统的能力和规模越来越大，其数据库压力也越来越大。
最初在建设 To C 系统时，业务库主要使用 MySQL，既有单库架构，也有分库分表架构，时至今日我们面临的问题主要如下：
1.分库分表不合理导致的数据倾斜，某个分片负载居高不下，且难以动态调整
2.个别单库架构的 MySQL，数据增长远超预期，单表数据量过大，性能问题凸显
以上两个问题均需要大幅调整数据库架构来解决，解决成本高（人力、硬件），并且未来还可能再次面临这样的问题。为彻底解决以上问题，我们计划直接切换到原生分布式数据库 TiDB：
1. TiDB 兼容 MySQL 协议，并且是原生分布式，无需规划分片规则，对应用友好，能够很好的解决之前分库分表数据倾斜的问题
2. TiDB 架构下提供的动态水平扩展、热点自动调度等能力，大幅简化了一系列运维成本，能够支撑应用规模持续的增长，即使数据增长超过预期也能动态增加节点解决
3. 另外我们的零售系统在去年成功切换到 TiDB，也给了我们团队很大的信心
数据库测试方案
对于数据库的切换我们比较关心以下几个问题：
1. 迁移数据的完整性：数据是企业的核心资产，不容许丢失
2. SQL 兼容性及性能：这意味着我们迁移改造的成本
3. 资源隔离能力：多个业务库合并后如何保障其服务质量
测试目的：识别关键问题，基于测试结果完善应用改造
1 测试一：迁移数据的完整性
2 测试二：SQL 兼容性及性能
3 测试三：资源隔离能力
应用改造
1 分页 SQL 增加排序条件
2 性能退化的 SQL 优化
3 从分库分表处理逻辑改成单库处理逻辑
4 数据回写改造
5 下游订阅改造
生产切换效果
我们于双十一之前的两周完成消息中心等系统（4 个 MySQL 库）的切换，切换到 TiDB 后经受住了双十一大批量消息推送的验证，也增强了我们的信心。
在元旦后第一个工作日进行了私域商城系统（16 个 MySQL 库）的切换，切换过程比较顺利。以下是切换后第一个工作日的业务高峰，最大 QPS 4.4 万，P95 响应延迟 3.9ms，整体运行良好。
1.8 日某品牌大促，业务量是平时的一倍，数据库最大 QPS 6.5 万，P95 响应延迟 3.9-4.5ms 之间：
点击此处丨查看原文
02
从 20 多套 MySQL 到 1 套 TiDB:
骏伯网络综合运营管理平台应用实践
业务痛点与数据库技术选型
1 业务简介、现状和痛点
综合运营管理平台是骏伯最核心的业务系统，主要覆盖营销、渠道、媒介、创意等业务部门，底层数据库包含 OLTP、OLAP 两种，业务系统主要包含营销、订单和信息展现三部分。订单数据均会回流到订单服务模块，订单成功后会推送到下单流程，同时可以在平台中及时查看订单信息。
综合运营管理平台应用架构图
整套应用由 40 多个微服务组成，底层数据库采用 20 多套 MySQL 主备高可用架构，部署在 4 台物理服务器上，主备交叉部署的模式。大数据分析平台采用 Hadoop 生态，数据分析模式为 T+1 的离线模式。
综合运营管理平台是一套面向互联网用户的实时交易系统，对可靠性和性能要求较高。物理服务器的硬件故障会对生产运维和业务连续性造成较大的挑战和影响，各套数据库相对相互独立，需要实现跨库的数据实时共享。
2 技术选型要求
为了配合系统改造，解决业务连续性、数据扩展能力、资源利用率和性能等生产环境面对的痛点，骏伯启动了对国内多家头部原生分布式数据库的测试选型，具体的要求包括：
● 业务连续性
● 数据扩展能力
● 应用透明迁移能力
● 数据实时压缩能力
● 数据可恢复性
经过多轮对比测试和业务场景的验证，TiDB 满足了本次技术选型的所有指标。骏伯网络选择将 TiDB 作为综合运营管理平台的底层数据库。
TiDB 在骏伯网络综合运营管理平台的应用
从整体数据规模、业务访问请求、资源高可用等维度考虑，我们制定了详细的部署方案。结合现有应用和数据库情况，我们设计了分批业务迁移计划，历时 3 个月成功完成了所有应用的平滑迁移和部署。在主中心部署一套包含 4 台物理服务器的 TiDB 集群，用于支撑综合运营管理平台。主中心集群通过 BR 完成数据库备份任务。MySQL 数据的迁移工作由 DM 组件完成，以确保数据迁移的顺利进行。未来，我们计划在异地构建一套单副本的集群，通过 TiCDC 组件搭建数据容灾的演练环境，从而实现异地灾备。
系统架构图
目前所有应用模块已成功迁移到 TiDB 集群上，第一批迁移的业务已经稳定运行超过半年。系统在业务高峰期经历了验证，并成功应对了单服务器硬件异常故障对业务连续性保障的实际考验，完全实现了项目最初规划的目标。业务峰值流量 QPS 大于 10K，活跃连接数 400 左右，且平均响应延时低于 200ms。
应用价值
结合系统的实际运行效果，总结 TiDB 为骏伯网络带来的收益如下：
● 保障业务连续性
● 降低资源和运维投入
● 数据的实时汇聚和查询能力提升
● 应用迁移透明，业务无侵入
点击此处丨查看原文
03
数据价值在线化:
TiDB 在企查查数据中台的应用及 v7.1
版本升级体验
从 MySQL 到 TiDB 的升级之路
数据是企查查业务的核心，需要对海量数据进行清洗、分析、挖掘，才能充分释放数据价值。在引入 TiDB 之前，企查查使用 MySQL 数据库。MySQL 是一款受欢迎的开源关系型数据库，但存在单机性能瓶颈。当数据量达到一定规模后，垂直扩容只能有限提升性能，在高并发写入和复杂 SQL 查询等场景下，性能会受到单机性能的限制。
由于 MySQL 是单机数据库，在业务不中断的情况下，只能采用热备。但是，随着数据量的增长，MySQL 的热备操作会变得越来越慢，对数据库的性能产生较大影响。此外，热备数据的恢复速度也较慢。在企查查的数据流向中，爬虫采集到的数据需要先存储到数据库中，然后再由 Flink 进行清洗。由于 MySQL 不支持将数据直接投递到 Flink，因此需要通过 Flink 来读写数据库，这对 MySQL 库产生了较大的压力。
2019 年底，我们通过 TiDB 社区接触到 TiDB，并对其产生了浓厚的兴趣。经过对比选型测试，我们选择了 TiDB 数据库，结合 Flink 场景的需求，构建了 Flink+TiDB 的实时数仓框架，应用于企查查数据中台。我们选择 TiDB 的主要原因有：
● 切换到 TiDB 几乎无任何学习成本
● 原生分布式架构带来明显优势
● 周边工具完善
● 开源社区活跃
● 大数据生态友好
TiDB 在数据中台系统的应用
TiDB 应用于企查查数据中台系统，覆盖了从数据采集到数据清洗整个流程，提供数据的存储和查询。我们将原来的 20 多套 MySQL 数据库，替换成现在的 2 套 TiDB 集群。在数据清洗流程中，我们使用 TiDB 自带的数据同步工具 TiCDC 将数据同步到下游其他的数据库和 kafka 中。目前，同步的表累计近千张。数据采集到数据清洗的数据流转，则是通过 TiCDC 捕捉变更数据同步到 Kafka 中实现的。此外，我们使用了 TiCDC 中的 CommitTs 特性，通过数据在下游更新前的乐观锁控制，保证数据的一致性。
企查查数据中台系统逻辑示意图
TiDB 数据入湖使用了自研的 Flink Hybird Source。全量分片数据通过查询 TiDB 获取，增量数据通过消费 TiCDC 推送到 Kafka 的 Changelog 获取，准实时（分钟级）写入到 数据湖 Iceberg 中。Flink Hybird Source 支持全量、增量、和全增量一体三种数据同步模式。
我们将 TiDB 的部分数据同步到 ES 系统中，为 ES 系统提供数据来源，供一些检索场景的应用使用。对于离线数据，我们使用 Chunjun/Seatunnel 同步工具将其同步到 Hive 离线数据平台中，供下游的离线数据平台跑批。目前，我们正在调研 TiFlash 的功能，计划今年将部分复杂的离线查询从 Hive 迁移到 TiDB 中，直接从 TiDB 中查询，以减少数据在多个数据栈中流转，进一步提升数据的实时性。
应用价值
● 数据价值在线化
● 数据流转效率提升
点击此处丨查看原文
欢迎来到金融专区！
与 PingCAP 一同打造创新的金融数据基础平台，
加速数字化和智能化转型！
