在线业务落地从 0-1
在各个团队使用和熟悉 TiDB 一段时间后，我们开始针对已有业务的痛点或者未来新业务的规划，逐渐将视野转移到 TiDB。通过配合业务一起测试验证，开始正式将在线业务迁移到 TiDB 中。
1、报表平台使用 TiDB 突破存储&性能瓶颈
作业帮的报表服务每天要导入大量来自各个业务线的文件数据，来实现最终的数据大盘展示。随着业务线越来越多以及 MySQL 单实例主机的磁盘限制，报表服务平台逐渐显现出存储受限以及数据展示响应慢，甚至无法响应等问题。
我们通过 DM 将数据同步到 TiDB 中，经过业务验证，TiDB 对 SQL 达到了高度兼容性。同时，对比使用 MySQL 的耗时，TiDB 减少 80% 的时间，效果远超预期。随着 DM 同步稳定性的提高，报表平台也将一些直连线上 MySQL 的报表服务改成使用 TiDB 作为数据源。
经过改造，报表服务最终架构如下:
2、业务流水数据
业务流水数据业务的主要特点是每日写入数据量特别大，而且需要保存时间比较长。在公司的多个业务线中，只要是发展到一定阶段，使用 MySQL 存储的数据最终都会遇到存储瓶颈。此时 TiDB 便是非常好的一种解决方案。
在线业务落地从1-N
得益于 DM 同步数据的可靠性以及后面 TiDB-5.x 版本的兼容性、稳定性，作业帮有些业务逐渐将性能采集数据、用户访问记录、业务日志等业务也迁移到 TiDB。同时，在人工智能爆发的背景下，越来越多的探索性业务天然需要存储海量的数据，TiDB 自然成为首选方案。当然，线上还有很多核心业务不会轻易更换数据存储方案，那么对历史数据的归档使用 TiDB 也是目前的标准方案。
从 TiDB 4.0 版本开始，TiDB 加入了 TiFlash 列存引擎，并且在之后的版本中不断增强。如果业务有任何复杂查询需求，直接就可以在 TiDB 集群里通过增加 TiFlash 节点解决一些比较复杂的查询。
总结以及未来展望
现在，TiDB 在作业帮内部使用中已经可以独当一面了。目前，作业帮已经部署了几十套 TiDB 集群，总体数据量规模超过百 TB。在这些集群中，大部分采用的是 TiDB 5.4 版本，有一半已经升级到 6.5 版本。如果大家还在用 v3.x 版本的话，建议可以采用一些比较保险的方法测试升级到新的版本。作业帮从 v4.0.9 版本一路不断升级上来，整体感受是越来越稳定，让人比较安心，升级过程也非常丝滑，业务几乎没有任何感知。
最近有看到消息说杭州银行已经在核心账务系统上线 TiDB 6.5.6 版本，到 2024 年我们应该也会全部升级到这个版本。
最后，也说一下对 TiDB 的希望：返回搜狐，查看更多
希望 TiDB 能有不依赖于 CDC 的主备集群方案，一方面可以做异地机房的灾备，另一方面可以作为升级回滚的方案，避免升级之后出现业务不兼容的情况；
探索使用资源管控方案 (Resource Control)。对于 MySQL 分库分表的业务，无法将多个分集群同步到同一个 TiDB 集群，会出现库名冲突的情况；
SQL 限流或者拦截功能：对于资源消耗异常高的 SQL，可以自动进行降级处理，避免将集群资源耗尽，集群雪崩。