今天我们推出了 PlanetScale for Postgres。在过去的几个月里，我们一直专注于打造全球最佳的 Postgres 体验，包括性能在内。

为了确保我们达到对数据库性能的高标准，我们需要一种方法来以标准化、可重复且公平的方式衡量和比较其他选项。我们构建了一个内部工具 "Telescope"，作为我们创建、运行和评估基准测试的首选工具。

我们将其作为内部工具，让我们的工程师在构建和调优产品时能够快速获得关于产品性能演进的反馈。我们决定与世界分享我们的发现，并为他人提供复现这些结果的工具。

如果你想直接跳到基准测试结果，它们在这里：

• PlanetScale vs Amazon Aurora

• PlanetScale vs Google AlloyDB

• PlanetScale vs Neon/Lakebase

• PlanetScale vs Supabase

• PlanetScale vs CrunchyData

• PlanetScale vs TigerData

• PlanetScale vs Heroku Postgres

• PlanetScale vs Xata

PlanetScale 与其他 Postgres 厂商性能对比的快速概览：

在我们业务的各个方面，我们都追求卓越和持续改进。如果你发现我们的方法论或成本计算中有任何错误，欢迎通过 benchmarks@planetscale.com 联系我们。

什么是基准测试？

基准测试的使用方式往往具有欺骗性。这适用于所有技术，而不仅仅是数据库。

所以我们要明确一点，任何类型的基准测试都有其局限性。每个组织的每个 OLTP 工作负载都是独特的，没有任何单一的基准测试能够涵盖所有此类数据库的性能特征。数据大小、热冷数据比例、QPS 波动性、模式结构、索引以及其他 100 种因素决定了你的关系型数据库配置的需求。

你不能仅凭查看基准测试就确定在所有其他因素相同的情况下，你的工作负载会有相同的表现。

然而，当基准测试执行得当时，它对于回答以下问题非常有用：

• 我能以多快的速度访问我的数据库？（延迟）

• 数据库在“典型”OLTP 负载下表现如何？（TPS、QPS 等）

• 数据库在高读/写压力下表现如何？（IOPS、缓存）

• 相对于其他选项，达到某种性能标准需要多少成本？（性价比）

这些就是我们通过基准测试想要回答的问题类型。因此，我们选择了三个基准测试作为主要测量工具：

• 延迟：一个简单的查询路径延迟基准测试。它从同一区域的另一个实例反复对数据库执行 SELECT 1; 语句。非常简单，但能有效确定基本的查询路径延迟。

• TPCC：我们使用了 Percona 开发的类 TPCC 基准测试来帮助回答第 2-4 个问题。更多配置细节将在本文后面提供。

• OLTP 只读：对于表现最佳的部分产品，我们还运行了 OLTP 只读 sysbench 工作负载。这对于隔离读取性能很有用，因为大多数 OLTP 工作负载中 80% 以上是读取操作。

公平性

在此过程中，我们将我们的产品与众多其他云 Postgres 提供商进行了比较。我们希望比较尽可能公平。

我们公开发布的每个基准测试都是与运行在 i8g M-320 上的 PlanetScale 进行比较的。即 4 个 vCPU、32GB 内存和 937GB 的 NVMe SSD 存储。我们选择的实例大小和集群配置代表了具有至少中等使用量的真实生产应用程序的典型情况。例如，一个能够服务数千 QPS 同时保持低延迟和高可用性的数据库。

在 PlanetScale，我们默认为你提供一个主节点和两个副本，分布在 3 个可用区（AZ）中。多可用区配置对于拥有高可用数据库至关重要。副本也可用于处理大量的读取负载。

对于我们比较的其他产品，我们保持简单，创建了与 PlanetScale 主节点 vCPU 和内存匹配或超过的单实例数据库。为了匹配 PlanetScale 的真实容量和可用性，每个产品还需要添加副本。我们在讨论定价时会考虑这一点。

计算

对于每个竞争对手，我们在 vCPU 数量和 RAM 上都做到持平或超越。Amazon Aurora、Google AlloyDB 和 CrunchyData 支持 8:1 的内存优化 RAM:CPU 比例，因此我们能够完全匹配。

Supabase、TigerData 和 Neon 仅支持 4:1 的 RAM:CPU 比例。对于这些，我们选择匹配 RAM，使其 CPU 数量达到 PlanetScale 所用 CPU 的两倍。这对他们来说是不公平的优势，但正如你将看到的，PlanetScale 仍以更少的资源显著胜出。

存储

我们对比的所有产品都使用网络附加存储作为底层驱动器。其中一些不允许配置特定的 IOPS，例如 Aurora、Neon 和 AlloyDB。

然而有几个允许。对于 Supabase 和 TigerData，我们提升了默认 IOPS 设置。

方法论

为了完全透明，我们提供了进行基准测试的完整细节。每个基准测试都在以下条件下运行：

• 所有数据库和基准测试机器资源都在同一云区域内运行。除 Google 产品外，这意味着在 us-east-1 中运行。对于 Google，则在 us-central1 中运行。

• 除延迟基准测试外，我们不提供到可用区级别的保证。并非所有平台都允许你指定数据库节点应位于哪个 AZ（也不暴露此信息）。因此，对所有提供商做出这方面的保证是不切实际的。

• 所有基于 AWS 的基准测试都在 us-east-1 中的 c6a.xlarge（4 vCPU，8 GB 内存）上运行。所有基于 GCP 的基准测试都在 us-central1 中的 e2-standard-4（4 vCPU，16 GB 内存）上运行。

• 所有 Postgres 配置选项都保留在各平台的默认值。唯一的例外是对连接限制和超时的修改，这些可能会被修改以便于基准测试。

• 对于类似 TPCC 的基准测试，数据使用 Percona TPCC 脚本生成，参数为 TABLES=20 和 SCALE=250。这会生成一个约 500 GB 的 Postgres 数据库。我们提供了自行复现的说明。

• OLTP 基准测试使用 sysbench 内置的 oltp_read_only 基准测试。我们提供了自行复现的说明。

• 延迟基准测试非常简单：我们连续运行 SELECT 1; 200 次，并测量每次查询的往返时间。你可以轻松编写脚本来测量此类延迟。

更多细节在前文链接的每个结果页面中提供。

邀请

我们无意歪曲他人。我们的目标是向世界展示在 PlanetScale Metal 上运行 Postgres 所获得的卓越性能。在我们的测试中，PlanetScale Metal 上的 Postgres 是迄今为止性能最强的。

我们邀请其他供应商提供反馈。如果你发现我们的基准测试方法中有任何错误，请在 benchmarks@planetscale.com 告知我们。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：PlanetScale Blog

原创地址：https://planetscale.com/blog/benchmarking-postgres