本文字数4748估计阅读时间12 分钟作者Lionel Palacin, Sai Srirampur and Andrey Chudnovskiy编者按本文译自 ClickHouse 原博客。 原文围绕「相关技术主题」展开。几个月前我们发布了 PostgresBench这是一个开源基准测试它通过透明、可复现的方法比较了不同厂商托管 Postgres 的性能。该测试受到了Postgres 社区的广泛好评我们收到最常见的反馈是为什么我们没有对高可用性HA配置进行基准测试。今天我们解决了这个问题并分享了这些厂商 HA 配置的测试结果。需要明确一点这并非对所有厂商高可用性的完整比较。它只衡量了在不同的 Postgres 托管服务中为达到相似的可用性和数据持久性水平所付出的性能代价。不同 Postgres 服务的 HA 配置托管式 Postgres 服务通常采用两种不同的架构来实现高可用性。无共享服务ClickHouse Managed Postgres、AWS RDS 和 Crunchy Bridge为每个客户实例部署独立的计算资源和单租户存储并依赖 PostgreSQL 原生复制功能通过一个或多个物理流式备用节点在主节点不可用时自动进行故障转移。共享存储服务AWS Aurora 和 Neon均为 Postgres 的分支将计算与存储分离通过在提交路径上将 WALWrite-Ahead Log预写日志的多个副本写入复制存储层从而实现数据持久性并且无需依赖传统的流式副本来替换故障的计算节点。在此次比较中我们将高可用性定义为系统在主节点发生故障后声称能够在 2 分钟内恢复并保证零数据丢失。我们选择了每个托管服务所提供的、最接近可比标准的 HA 配置同时力求确保比较的公平性。以下部分将详细介绍我们为各厂商进行基准测试的配置。为确保公平比较我们尽可能匹配了所有供应商的主要计算资源CPU和RAM。但对于共享存储服务情况并非如此简单存储后端的硬件配置和冗余设置未公开披露而这些配置会影响系统性能和可靠性。ClickHouse Managed PostgresClickHouse Managed Postgres 是一项基于本地 NVMe 的 Postgres 服务专为高性能 OLTP (联机事务处理) 工作负载优化。由于在计算发生故障时本地 NVMe 存储的数据是短暂的该服务提供了多种高可用性 (HA) 配置以提供不同级别的持久性。单备用配置采用异步复制适用于能接受较小恢复点目标 (RPO) 的工作负载即允许几毫秒的事务丢失。双备用配置则使用同步仲裁复制可实现零数据丢失 (RPO 0)。由于所有持久性和高可用性均来自 PostgreSQL 复制和 WAL 上传而非依赖复制磁盘因此目前跨可用区实现零数据丢失需要由 3 个实例组成的仲裁组我们正在努力在不增加第三个实例的情况下实现类似的持久性保证。这是我们有意为之的设计旨在让客户能够灵活控制并根据其工作负载的关键程度选择他们偏好的 HA 配置0、1 或 2 个备用。这两种配置均设计用于快速故障转移通过热备用机制当主实例不可用时能最大限度地缩短恢复时间 (RTO)。Crunchy BridgeCrunchy Bridge (Snowflake Postgres) 通过单个物理流式备用副本实现高可用性。默认情况下复制模式为异步。我们未能成功配置同步复制即使调整了synchronous_commit参数也未找到能保证零 RPO 的配置选项。如果我们在支持的配置或设置上有所疏漏请告知我们我们将很乐意相应地更新本文。AWS RDS PostgresAWS RDS以及Crunchy Bridge通过复制的托管磁盘实现可用区AZ内的持久性并通过热备用PostgreSQL实例实现高可用性和跨AZ持久性。RDS支持单备用或双备用实例且这两种配置都始终采用同步复制确保在故障转移时不会丢失数据。我们测试了以下两种配置Multi-AZ DB instance单备用 和 Multi-AZ DB cluster双备用quorum。AWS Aurora PostgresAurora Postgres是AWS维护的Postgres分支版本它通过共享存储架构而非Postgres原生的流式复制来提供高可用性。数据会在多个可用区中的多个存储节点之间同步复制读取实例与写入实例共享同一个存储卷。共享存储系统中的热备用实例对于持久性而言并非必需但仍有利于更快的故障转移或读取流量的横向扩展AWS建议部署至少一个Aurora Replica读副本以实现高可用性。在主实例不可用时该副本可实现自动故障转移和快速恢复。我们对一个包含一个写入器实例和一个Aurora Replica的集群进行了基准测试。NeonNeon也是Postgres的一个分支采用存储与计算分离的架构。其读取吞吐量通过结合计算实例上的本地缓存以及来自通常称为“页面服务器”page servers的独立分布式系统的远程读取来实现。Neon更进一步在平台中引入了多租户功能包括无服务器计算集群和连接网关这些组件在提升灵活性和潜在成本节约的同时也为业务关键型工作负载带来了额外的权衡取舍参考。Neon 的 高可用性 (HA) 方案旨在通过在故障转移时快速启动新计算节点并连接到现有存储从而无需备用节点。该公司将此视为一项成本优势。然而鉴于 Neon 曾多次出现影响众多客户的 可用性和可靠性问题其声称无需备用节点的说法值得商榷。在本次基准测试中我们根据 Neon 官方文档的架构和定位来评估其 HA。基准测试结果我们对不同数据库实例和数据集大小下的每种配置进行了基准测试所有结果均可在 PostgresBench 上查阅。下文展示了最大实例16 vCPU64 GB RAM和最大数据集500 GB的测试结果每次测试运行 10 分钟。我们报告了平均每秒事务数 (TPS) 和 p99 事务延迟。下表还包含每个供应商的“单节点”行其数据来自 PostgresBench 第一轮中已发布的单节点基线。表中 Aurora 和 Neon 的结果基本代表了它们的单节点部署性能。VendorConfigurationAvg TPSTPS vs own Single nodeAvg latencyAvg latency vs own Single nodep99 latencyp99 vs own Single nodeClickHouse Managed PostgresSingle node26,328100%9.70 ms100%13.20 ms100%ClickHouse Managed Postgres1 standby, async24,66794%10.37 ms107%24.17 ms183%ClickHouse Managed Postgres2 standbys, sync (quorum)20,72079%12.34 ms127%33.49 ms254%Crunchy BridgeSingle node11,113100%23.00 ms100%41.68 ms100%Crunchy BridgeHA (1 standby, async)11,135100%23.00 ms100%41.89 ms101%RDS by AWSSingle node4,399100%58.14 ms100%130.15 ms100%RDS by AWSMulti-AZ instance (1 sync)4,461101%57.35 ms99%221.69 ms170%RDS by AWSMulti-AZ cluster (2 sync, quorum)4,659106%54.92 ms94%816.63 ms627%AWS AuroraSingle node9,238100%27.69 ms100%39.81 ms100%AWS AuroraHA (1 standby, async)9,520103%26.87 ms97%39.92 ms100%NeonSingle node7,802100%32.80 ms100%56.30 ms100%无共享架构对于依赖备用副本的供应商在计算资源匹配和持久性水平相当的情况下对比结果如下1. RDS Postgres 在 RPO 为零且具有快速故障转移RTO 为数秒到数分钟的设置中配置了 2 个同步备用节点法定人数的 ClickHouse Managed Postgres其 TPS 比亚马逊 RDS Multi-AZ 的单副本和双副本高出约 4 倍p50 延迟低约 3 倍p99 延迟低约 7 倍。2. Crunchy Bridge 对比 Crunchy Bridge 最接近的可比高可用HA配置1 个异步备用节点支持快速故障转移但 RPO 略大于零ClickHouse Managed Postgres1 个异步备用节点的 TPS 高出约 2.2 倍p50 延迟低约 3.5 倍p99 延迟低约 1.75 倍同时提供更强的持久性保障。共享存储架构对于共享存储服务在主计算资源规模匹配的情况下对比结果如下1. Aurora Postgres ClickHouse Postgres 在配置相似、带 1 个备用节点的 PostgreSQL 主计算资源规模下展现出吞吐量高出 2 倍以上并且延迟更低的优势。2. Neon ClickHouse Postgres 在配置相似的 PostgreSQL 主计算资源规模下展现出吞吐量高出 3 倍以上并且延迟更低的优势。结论我们很高兴已增加对高可用性HA的支持。这能更好地反映生产就绪的托管Postgres部署并帮助用户理解不同数据持久性实现对性能的影响。我们的工作仍在继续对PostgresBench的未来发展充满诸多设想。我们计划在以下几个方面投入精力增加更多托管Postgres提供商使基准测试运行时长可配置引入TPC-C和TPROC-C等额外工作负载以及公开更多配置选项包括PostgreSQL的配置参数。我们还计划分析不同托管Postgres提供商之间的成本与性能权衡这与我们为ClickHouse开展CostBench项目类似。您的反馈将有助于我们确定后续方向共同努力将PostgresBench打造成托管Postgres服务的默认、完全可重现的基准测试工具。PostgresBench已在GitHub上开源https://github.com/ClickHouse/PostgresBench/。欢迎大家审阅其方法、重现基准测试并协助增加对其他供应商的支持。关于我们ClickHouse 是面向 AI 时代打造的高性能实时分析数据库能够以极致性能处理海量数据分析任务。凭借高并发、低延迟和云原生架构ClickHouse 广泛应用于可观测性、数据仓库、实时分析及 AI 数据基础设施等场景。我们致力于帮助企业在公有云平台上构建安全、弹性且高性价比的实时分析与 AI 数据平台加速释放数据价值推动智能化创新与数字化转型。目前Trip.com、DiDi、Meta、Sony、Netflix、Deutsche Bank、Sierra、Cloudflare 等全球领先企业均在使用 ClickHouse 支撑其关键业务和数据分析平台。