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

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

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

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

Cloud First

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

在 2024 年，在 cloud 上面，一方面我们仍然在快速的迭代改进，大家可以看 TiDB Cloud Release Notes in 2024，另外一方面，我们在不断地修炼内功，应对客户在 TiDB Cloud 上面大规模增长的挑战。

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

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

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

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

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

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

关注 SaaS

熟悉了解 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 的价值』——这是一个非常高的评价。

AI 是未来

都 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 年，我们能做的更好，支持好更多客户的业务增长，帮助客户成功。