PostgresBench：为托管 Postgres 服务建立可复现的性能基准

背景

多年来，ClickHouse 团队始终专注于构建高性能系统。性能并非后期添加的功能，而是从设计之初就确立的核心目标。ClickHouse 正是这一理念的产物。

在构建托管 Postgres 服务时，团队采用了类似的方法论。结果证明，他们为客户提供了目前市场上最快的托管 Postgres 服务之一。Postgres 擅长处理事务性工作负载（OLTP），而 ClickHouse 擅长处理分析性工作负载（OLAP）。两者结合，构成了一个统一的数据栈，为 SaaS 和 AI 应用提供了“最佳组合”的基础设施。

基于这一背景，团队认为有必要像评估 ClickHouse 一样评估其托管 Postgres 服务：即通过公开、可复现的基准测试（Benchmark）。因此，PostgresBench 应运而生，这是一个专门用于比较托管 Postgres 服务的基准测试工具。

核心内容

PostgresBench 借鉴了广受引用的 OLAP 基准测试 ClickBench 的方法论，将其应用于事务性 Postgres 工作负载。其核心原则简单明了：使用理解透彻的标准工作负载、保持所有被测服务的基础设施一致、公开所有配置以确保结果可复现，并允许任何人提交结果或指出问题。如果数据有误或配置不公，均可被检查和修正。

工作负载设计

PostgresBench 基于 pgbench（Postgres 的标准基准测试工具）构建。团队使用了其内置的类 TPC-B 工作负载，模拟具有频繁写入和更新的短并发事务。这很好地代理了常见的交易模式，如支付、订单处理、库存更新等，这些场景通常涉及大量小型、高频的写入操作。

选择 pgbench 是刻意为之：

• 原生适配：sysbench 和 Percona TPCC 等工具最初是为 MySQL 设计的，而 pgbench 是 Postgres 自带的，无需额外工具即可复现结果。
• 自然契合：对于 Postgres 基准测试，pgbench 更为自然且易于使用。

运行参数

每次基准测试运行均使用以下参数：

pgbench -c 256 -j 16 -T 600 -M prepared -P 30 \
-s $SCALE_FACTOR \
-h $PGHOST -p $PGPORT -U $PGUSER -d $PGDATABASE

• 并发设置：256 个客户端，16 个线程，反映了生产环境中事务性工作负载的真实并发水平。
• 持续时间：每次运行持续 10 分钟（600秒），足以度过预热阶段并捕获稳定的吞吐量。
• 数据规模：测试了两个规模因子（Scale Factor）：
  • 6849（约 100 GB）：对应应用起步阶段，工作集合理地位于缓存中。
  • 34247（约 500 GB）：对应已具备一定规模、工作集开始溢出到磁盘的场景。
  • 这两个规模之间的结果差异，能揭示服务在数据增长时如何处理存储压力。

指标捕获

团队报告了每种配置下三次运行的平均 TPS（每秒事务数）、平均延迟、P95 延迟和 P99 延迟。排行榜展示了最佳和最差运行的结果，详细数据可在仓库中查阅。

公平性考量

没有任何基准测试是绝对中立的，从实例类型到 Postgres 配置的选择都可能偏向某一系统。为了透明和公平，团队详细记录了决策依据：

1. 客户端机器设置：

   • 在 us-east-2 区域配置了一台 16 vCPU、64 GB 的实例作为客户端，确保客户端不会成为瓶颈。
   • 所有服务均在同一区域测试，以排除跨区网络延迟的影响。
   • 客户端与数据库未 colocate（同可用区部署），因为并非所有服务都支持此功能，但团队未来可能考虑增加此维度以惠及支持该功能的服务。

2. 实例选择：

   • 大多数服务采用 1:4 的 CPU 到 RAM 比率，测试了两种规格：4 vCPU/16GB RAM 和 16 vCPU/64GB RAM。
   • Aurora 未提供符合该比率的实例类，因此采用 1:8 比率：4 vCPU/32GB RAM 和 16 vCPU/128GB RAM。
   • 对于支持的服务（包括 AWS RDS 和 Aurora），均使用带有 NVMe 缓存的 Graviton 实例，确保竞争对手享有相同的硬件优势（尽管在这些情况下 NVMe 主要用于缓存而非主存储）。

3. 单节点测试：

   • 尽管所有服务都提供高可用性（HA），但底层架构不同（如备用复制、共享存储等）。为了隔离计算和存储性能，测试在禁用 HA 的情况下进行。未来可能会将 HA 配置作为单独维度加入。

4. 默认 Postgres 配置：

   • 未修改任何服务的默认 PostgreSQL 配置，使用开箱即用的设置进行测试。这反映了大多数用户期望无需调优即可获得性能的现实情况。未来可能会将 Postgres 配置作为额外维度。

5. 关于定价：

   • 本次测试未比较定价。ClickHouse 管理的 Postgres 服务在测试时尚未发布。预计其定价将与类似硬件配置的服务具有竞争力，届时用户可根据结果推算性价比。

首批测试系统

PostgresBench 的首个版本涵盖了 5 家托管 Postgres 服务，每家服务均在两种实例配置下进行了测试（较小规格 4 vCPU/16 GB 和较大规格 16 vCPU/64 GB 或等效配置）。这有助于观察各服务随资源增加时的扩展能力，而不仅仅是单一性能点。

• 所有服务均在 us-east-2 区域测试，禁用 HA。
• 使用 Postgres 17 或 18（取决于各提供商支持情况）。
• Aurora 是首批中唯一仍运行 Postgres 17 的服务。

测试脚本在所有系统上相同，每次运行均在隔离环境中进行，无其他并发进程干扰。

关键要点

• 方法论一致性：PostgresBench 沿用了 ClickBench 的透明、可复现原则，旨在消除黑盒测试带来的偏见。
• 工作负载代表性：使用 pgbench 模拟高频短事务，贴合支付、订单等典型 OLTP 场景，比通用工具更贴合 Postgres 特性。
• 规模差异揭示瓶颈：通过 100GB 和 500GB 两种数据规模测试，重点考察数据库在数据增长、缓存命中率下降及磁盘 I/O 增加时的性能表现。
• 硬件与配置标准化：
  • 客户端与数据库同区域部署以消除网络变量。
  • 优先使用 Graviton + NVMe 缓存硬件，确保硬件层面的公平性。
  • 禁用 HA 以隔离单节点计算/存储性能，使用默认配置以反映用户真实使用场景。
• 透明度高：所有配置、脚本、原始结果均在仓库公开，允许社区验证、提交改进或指出不公。
• 首批覆盖主流服务：包括 AWS Aurora、RDS 等主流托管服务，测试了不同规格下的扩展性。

意义与影响

1. 填补 OLTP 基准测试空白：目前市场上缺乏像 ClickBench 那样广泛认可、透明且可复现的 OLTP（特别是 Postgres）基准测试。PostgresBench 的建立填补了这一重要空白，为开发者提供了客观比较托管 Postgres 服务性能的依据。

2. 推动行业透明度：通过公开所有配置和结果，PostgresBench 迫使云服务商和数据库提供商更加透明。任何声称的性能优势都必须经得起公开验证，有助于遏制营销夸大，促进良性竞争。

3. 指导架构决策：对于需要处理高并发事务的 SaaS 和 AI 应用，PostgresBench