唐刘：TiDB 的 2024 - Cloud、SaaS 与 AI

本文作者：唐刘，PingCAP 研发副总裁

2024 年已经过去，在去年我也写过两篇类似的文章，TiDB in2023 - 一次简单的回顾和 TiDB Cloud in 2023 - 一次简单的回顾 ( https://zhuanlan.zhihu.com/p/679020642 )，这一次，我准备将 TiDB 和 cloud 一起写，一方面原因是我懒了，另外一个更重要的原因在于 TiDB 跟 cloud 一直是非常密切的绑定的，我们大多数的迭代和改进都是基于 cloud 的，cloud 已经成为了 TiDB 的一部分了。

在 2024 年，TiDB 也取得了非常瞩目的成绩，在全球知名的数据库排行榜 -DB-Engines Ranking 上面，我们在关系型数据库领域，在 2025 年 1 月 1 日这天，已经排在了第 38 名，这已经是一个非常了不起的成绩了，也表明 TiDB 在全球正在逐渐得到越来越多的企业和开发者的关注。

我们也非常开心的看到，TiDB 也给越来越多的客户带来了成功，譬如在这篇文章 TiDB Adoption at Pinterest (https://medium.com/pinterest-engineering/tidb-adoption-at-pinterest-1130ab787a10) 里面，Pinterest 提到从 HBase 迁移到 TiDB，他们平均节省了 50% 的成本，在有一些业务系统，甚至能节省 80% 的成本，同时业务的稳定性和性能也有非常大的提升。

要取得上面的成绩并不容易，在 2024 年我们也经历了很多，下面，我会简单的梳理回顾下，我们在 2024 主要做的一些有意思的事情。

在贵司内部，我们一直坚信，未来的数据库一定是一款 cloud -native 的数据库，而且也一定是依托于 cloud 的基础设施进行构建的。这里尤其提一下 S3 以及其他 cloud 的 blob storage，最近我愈发的看到，基于 S3 来构建数据库的趋势，甚至在 OLTP 领域，譬如 Neon，还包括 TiDB 自身等等。

在 2024 年，在 cloud 上面，一方面我们仍然在快速的迭代改进，大家可以看 TiDB Cloud Release Notes in 2024 (https://docs.pingcap.com/tidbcloud/tidb-cloud-release-notes)，另外一方面，我们在不断地修炼内功，应对客户在 TiDB Cloud 上面大规模增长的挑战。

下图是最近两年在 TiDB Cloud 上面客户的数据量，大家可以看斜率，可以发现在 2024 年，客户的数据量几乎是成倍数的增长，这个对我们在 cloud 上面的运维以及 TiDB Cloud 这个产品都提出来非常大的挑战。毕竟很多问题真的只有在规模化下才会发生的。

我们在云上面，因为规模化，遇到了非常多的问题，有些都是之前很难想象的，这里说几个有意思的：

IO 抖动。我在 2024 年的 AWS re:Invent 见到了 AWS EBS 的研发老大，问了他一个问题，你们 EBS 盘 IO 抖动的 outlier 是多少，他回答道，『如果超过 500ms，我们会认为是异常』。我表示：『我们遇到过 20s 的，甚至在你们最好的 IO2 的机型上面』，我完全能看到他眼睛里面的震惊。他也承认，不要指望 EBS 团队能解决所有问题，所以我们自己在 TiDB 也做了非常多的优化（这个有机会后面再说），来确保遇到 IO 抖动的时候，对业务影响降到最低。

除开 IO 抖动，当然另一个抖动就是网络抖动。有一次，我们某客户遇到了不规律的，非常随机的，时不时某一个请求超过数百 ms 的情况，而这个请求通常的延迟量级在几 ms 范围内。我们排查了半天，最终定位到可能跟网络有关系，后来云厂商也直接承认，那段时间在做网络改造，升级交换机的时候，影响了网络。

再就是云厂商的资源并不是无限的，并不是你想申请就能申请到，尤其是大规模的申请的时候。我们某客户，在某云厂商的新加坡 region 要买一大批机器，结果云厂商告诉我们，这客户已经把新加坡 region 相关机型的机器都买完了，再买得等一段时间了，而且这并不是单个云厂商的特例。解决办法一方面是我们自己进行资源优化，另外就是提前跟云厂商打招呼，提前备货了，不过对于一些快速增长的业务，这个挑战和压力就很大了。

当然，还有非常多的挑战，包括但不限于云厂商给我们算错账，某机房失火烧掉整个 AZ 等等，这里就不一一列举了，不过每次遇到新的问题的时候，我总会跟自己安慰一下，『数据库是用出来的，坑是踩出来的』，我们能做的，就是尽量的确保系统的稳定，提前做充分的 chaos 测试，确保 chaos 真的发生的时候，我们能很好的应对。

熟悉了解 TiDB 的同学应该知道，TiDB 一开始最关注于互联网场景，也就是俗称的数据量大，并发规模大这种，后来我们开始做传统行业之后，就开始发力去攀登一个珠穆朗玛峰，也就是银行的交易核心场景。这些都有了不错的成绩，在 2024 年，我们开始关注于 SaaS 场景。

为什么要做 SaaS？一方面的原因是来自客户，譬如 Databricks，去年我们为了支持好他们的业务，解决大小租户隔离的问题，就开始做 resource control 的功能。而今年，我们有了更多的 SaaS 客户，自然 SaaS 的需求就提上了优先级。

而另一个原因则是，我们发现，在 SaaS 场景里面，对于很多产品的需求其实在其他的场景，譬如银行核心对于稳定性的需求，都是共通的。SaaS 里面，因为涉及到资源共享，而在共享的环境下，对于大租户来说，稳定性尤其重要。所以我们认为，做好了 SaaS 场景，也能让其他我们想要打的场景收益，而事实也正是如此。

在 SaaS 场景，我们真的做了非常多的工作，其中最好玩的一个项目，我们内部代号叫做 1M Tables，也就是要在 TiDB 里面支持一百万张表。这个对于系统的挑战还是非常大的，这里提几个：

• Schema Cache 的处理，之前 TiDB 是全部将 schema 缓存到内存里面的，显然百万这个级别，是要做更多的优化处理了。而如果一个 schema 没在缓存里面，租户访问的时候就可能出现临时加载引起性能抖动。所以我们重点优化了这块，引入了新的 Schema Cache 算法。
• 统计信息的收集，百万的表，到底哪一些表要快速的做统计信息收集，哪一些不需要做，也是很有讲究的。如果统计信息收集慢了，就会导致查询计划生成不准确。所以我们引入了优先级队列，以及只收集 predicate column 等优化，确保快速的收集需要的统计信息。
• 租户很多都是相同的 query pattern，只不过是访问的不同的表，而这些表也有几乎一模一样的表结构，所以如果要给一个 query 加上 hint，我们在其他的类似 query 都要加，这个对于人来说几乎就是不可能的事情了。所以我们引入了global binding功能，能给具有相同 pattern 的 query 统一加上 hint。
• 
  

实际，我们还做了更多的东西，所以当 TiDB 8.5 发布之后，我真的相信，TiDB 已经成为了客户在 SaaS 场景首选（之一）的云原生分布式数据库了。我们也给很多客户带来了价值，譬如 Atlassian（没错，就是做 Jira 的那家公司），对我们表示：『这就是 TiDB 的价值』——这是一个非常高的评价。

都 2024 年了，不聊 AI，显然有点落伍了。不少朋友都问我，在当前 AI 这个大潮流下面，你们就不做点啥？而几乎每次，我都会先强调，『我们是一家数据库公司』。

是的，因为我们是一家数据库公司，所以我们最高的优先级，仍然是考虑的是如何给客户做一个高质量、高性能、易使用的数据库。所以在 AI 领域，我们更多的关注，仍然是让更多的 AI 客户，如何更好的通过 TiDB，来让他们的业务进行增长。

我们在 2024 年，发布了 vector search 功能。这里再做个广告，我们在明年，也会发布 full text search。我们相信，TiDB 能给 AI 客户相比于传统的 vector 或者 search 的数据库，提供更大的价值。包括但不限于：

• 可扩展的 OLTP 的能力，让客户对自己的业务增长有更多的信心，毕竟 TiDB 能搞定。
• 多数据格式的支持，无论是 graph（在 TiDB 可以用 table 来模拟），还是 vector 以及 search，TiDB 都能让客户在一个地方方便的使用。
• TiDB 特有的 HTAP 能力，能让客户进行非常复杂的混合查询，譬如能做到 vector 和 TP 数据的 join 等。

总之，TiDB 的目标就是给客户提供一站式的 AI 处理服务。而我们也看到了成功的案例，知名的 AI 厂商 Dify 已经将租户数据迁移到 TiDB Cloud 上面，进行 AI 数据的处理了。

最后再说下产品，在今年，我们发布了TiDB 8.1和8.5两个版本。在 2025 年，我们会有一个重大的改变，就是会持续的投入到 8.5 版本的质量加固，同时收敛新功能的开发，只会在 2025 年发布一个有更高质量的 LTS 版本。关于 TiDB 8 系列，我后面再写一篇文章详细的介绍一下吧。

在 2024 年，我们交付了非常不错的成果，当然，能取得这样的成绩，来自于我们不断地交付优异的产品，满足客户的需求，赢得客户的信任。我们也希望，在 2025 年，我们能做的更好，支持好更多客户的业务增长，帮助客户成功。