随着 PlanetScale 客户群的不断扩大，我们的技术解决方案团队经常与一些公司合作，这些公司试图评估 PlanetScale 是否适合他们现有的开发技术栈的需求。理解数据库性能的影响以及它如何与应用程序的整体性能特征相关联可能是一项复杂的工作，因此能够参考标准化的基准工作负载有助于更深入地了解可能的结果。
上周，我们发表了关于此领域研究的一个初步成果：简要介绍了如何使用 PlanetScale 和 Vitess 来线性扩展像 TPC-C 这样的工作负载达到每秒一百万次查询（1 million queries per second）。单纯关注这样的数值没有意义：理论上，只要有需求和资源，上限是无限的，且许多 Vitess 用户的工作负载规模远超这一范围。此次研究的真正价值是展示了工作负载（例如 TPC-C）如何在线性和可预测扩展的同时，仍然满足关系型和事务性需求。
TPC-C 基准测试有着非常悠久的历史，并且直到今天仍然非常有参考价值。但它不能涵盖所有场景。例如，来自加州大学伯克利分校的 Audrey Cheng 和她的团队发现，在针对一种更现代且高度普遍的工作负载类型（社交媒体网络）的可供使用的虚拟基准测试方面存在缺口。与 Meta 的工程师合作后，她发布了两篇白皮书：第一篇分析了 Meta 工作负载组成的总体挑战；第二篇（本周发布）总结了他们提出的名为 TAOBench 的开源基准测试，展示了这些原则应用于当前许多现代数据库的方式。
由于 Vitess 支持着当今互联网中一些最大的关系型工作负载，他们的研究提供了一个与我们合作的绝佳机会，深入探索这种特定的工作负载类型。本周，Cheng 和她的团队正在大型数据库会议（Very Large Data Bases，简称 VLDB）上发布第二篇白皮书，同时 PlanetScale 也将 TAOBench 添加到我们的标准化基准测试工具库中，并将在未来几周内发布更深入的文章以分享我们的测试结果。
现在，让我们总结一下基准测试本身以及 PlanetScale 已发布的结果。

工作负载和数据集组成

TAOBench 团队花了大量时间分析了 Meta 的一个具有代表性的工作负载片段，并将其关键特征总结为两种主要场景：

  • 工作负载 A（Application 的缩写）专注于查询的事务性子集。
  • 工作负载 O（Overall 的缩写）涵盖了 TAO 工作负载的更通用的特征集。

在实际操作中，这些工作负载的行为可能显得有些虚拟化和简化，但仔细阅读白皮书后会发现，这两种公式最终非常接近 Meta 所观察到的真实行为。

对象与关联

TAOBench 的数据库结构非常简单：它由两个表组成，一个叫做 objects 表，另一个叫做 edges 表。这两个概念可以粗略地映射到社交图上的实体（比如“用户”、“帖子”、“图片”等），以及它们之间的各种类型的关系（比如“点赞”、“分享”、“好友关系”等）。
在简单的关系型数据库术语中，edges 表可以视为一种“多对多”的关系表，它将 objects 表中的某些行链接到其他行。

数据组成的重要性

两个表中的数据统计分布取决于所选的工作负载类型（A 或 O），因此在切换工作负载类型时需要重新加载数据。围绕这两个简化概念构建工作负载，能够有效模拟典型的“热点行”场景，这些情况对关系型数据库来说通常特别具有挑战性。例如，当某个内容“病毒式传播”时，会有大量的用户涌入来与某个特定的内容交互。在数据库层面，这不仅会导致突发的连接激增，还可能转化为围绕该内容相关数据行的各种锁定。这种情况会产生连锁效应，最终导致平台用户访问内容的时间变慢。

TAOBench 测试时间线

TAOBench 工作负载分为三个不同的阶段进行：

  1. 加载阶段在此阶段进行批量插入操作，根据选择的工作负载场景填充 objects 和 edges 表。
  2. 批量读取阶段此阶段是任何实际基准测试运行的起始部分，它在整个数据集中执行非常激进的范围扫描，以作为对现有缓存机制的通用“预热”措施，同时还收集必要的统计信息，以供后续实验使用。这个阶段不会被计入测试结果，但对底层基础设施可能非常苛刻。
  3. 实验阶段此阶段接受一组预定义的并发级别和运行时操作目标，帮助将选择的工作负载扩展到不同规模的基础设施。

PlanetScale 的结果和初步结论

Cheng 的白皮书中发布的结果由 TAOBench 团队独立在 PlanetScale 的基础设施上测量得出。由于基准测试代码已经公开发布，PlanetScale 能够在内部自行验证这些结果。回顾我们之前有关 “使用 MySQL 达到每秒一百万次查询” 的博客文章，这些数值绝不是我们基础设施能力的上限。它们反而代表团队对集群强制施加的显式资源限制下所能达成的成果。
为了测试，Cheng 的团队为其测试设置了一个 48 个 CPU 核心的限制。测试在 PlanetScale 的多租户无服务器数据库服务上进行，其中某些基础设施资源会在多个租户之间共享。我们为集群的“查询路径”（query path）最多分配了 44 个 CPU 核心，而其余的 4 个核心则用于多租户相关的基础设施功能，如边缘负载均衡。我们会在后续博客中深入探讨资源如何分配给各种 Vitess 组件，以及操作系统级别的指标表现如何。
从初步结果中，最重要的结论是 PlanetScale 集群在极端资源压力下保持了持续的稳定性。正如在一个人工约束环境中所预期的，TAOBench 的“实验”阶段随着并发压力的逐步增加，将目标数据库推到极限。当 44 核心全部运行在 100% 的情况下，吞吐量（以每秒请求量衡量）预计会达到上限，同时平均响应时间也会增加。
几乎所有的系统在运行在看似 100% CPU 利用率时通常仍有一定的弹性。然而，随着工作负载压力的不断增加，所有软件最终都会开始出现故障，例如性能恶化、阻塞崩溃等。

为什么企业组织选择 PlanetScale

分布式数据库系统并非能神奇地免于这些故障场景。实际上，增加的基础设施复杂性和不同资源类型之间的潜在竞争通常会导致系统失败以更多、更复杂的方式出现。在观察软件在这些故障场景中的行为时，可以揭示出在一些不可预测的情况下可能发生的结果。找到资源效率和高效故障处理之间的平衡，需要软件成熟度和持续的基础设施工程技术的双重支持。


TAOBench: 在 PlanetScale 上运行社交媒体工作负载插图

关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台

除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接

本文链接：http://www.choupangxia.com/2025/09/07/taobench-planetscale/