共计 2012 个字符，预计需要花费 6 分钟才能阅读完成。
导读
作业帮是一家成立于 2015 年的在线教育品牌，致力于用科技伎俩助力教育普惠。通过近十年的积攒，作业帮使用人工智能、大数据等技术，为学生、老师、家长提供学习、教育解决方案，智能硬件产品等。随着公司产品和业务场景越来越丰盛，数据量越来越大，业务方对数据库的应用需要也越来越多元化。本文介绍了作业帮对 TiDB 的摸索历程，以及逐步落地多个业务场景的应用实际。
TiDB 在作业帮的摸索和推广
作业帮外部最开始接触的版本是 TiDB v4.0.9。相较于 TiDB v3.x，v4.0.9 在性能、治理、易用性等方面都有了质的晋升，同时 TiDB 的生态组件以及社区也都达到了十分欠缺的水平，能够说是一个标志性的版本。2020 年，咱们正式开始调研测试 TiDB v4.0.9, 以实现团队在分布式数据库的技术储备，从而更好地服务公司的业务需要。
1. 探索期: 应用 TiDB 隔离对在线 MySQL 集群有性能影响的查问申请
研发人员须要不定时查问线上实时数据，以此来确定业务数据的状况或者对局部业务数据做汇总剖析。
● 引入 TiDB 之前：业务人员是直连到 MySQL 从库查问数据，如果扫描的数据量太大常常会引起线上 MySQL 节点性能抖动甚至机器的 io/cpu 资源瓶颈。
● 引入 TiDB 之后：通过数据同步工具 DM 将 MySQL 的数据以全量 + 实时增量的形式同步到 TiDB 中，实现在线、离线申请的隔离性。
在这个摸索阶段，一方面满足了离线查问的隔离性的要求，另一方面也相熟了 TiDB 及其生态组件的个性以及应用办法。
2、推广期：外部分享 + 主动出击
通过半年左右工夫的应用，在对 TiDB 有肯定理解的根底上，咱们开始在公司外部进行 TiDB 相干的技术分享，向研发人员介绍 TiDB 的一些个性和在大数据量场景下的劣势，并被动接触各个业务线去寻找适合的应用场景。研发人员也陆续将一些业务 外部应用的报表服务 接入到离线 TiDB 集群中。
在线业务落地从 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，能够主动进行降级解决，防止将集群资源耗尽，集群雪崩。