Postgres不慢，慢的是存储：NVMe与EBS性能对比

解释差距

通过查看EBS事务延迟的37毫秒去了哪里，吞吐量差距就更容易理解了。

在这个基准测试中，EBS上的页面读取约占19毫秒，而NVMe上为0.3毫秒。WAL fsync 在提交时又在EBS上增加了11毫秒，而NVMe上为1.5毫秒，同时锁和调度器开销贡献了约5毫秒，而NVMe上为0.2毫秒。CPU工作本身大致相同——两种情况下都约为2毫秒。

换句话说，额外的EBS延迟大部分来自等待存储，而不是PostgreSQL做了更多的CPU工作。

运行中的pg_stat_activity快照从另一个角度显示了相同的模式。在64个后端进程中，EBS上有29个在等待IO:DataFileRead，而NVMe上只有9个——大约45%对比14%。这是一个时间点快照，而非整个运行的平均值，但它说明了当时有多少EBS会话因读取而停滞。

CPU剖析随后提供了一个违反直觉的观察。在约240秒的剖析窗口中，NVMe主机累积了2,253 CPU秒——大约9.4个核心忙碌——而EBS主机仅累积了251 CPU秒，即约一个核心忙碌。一些PostgreSQL函数在EBS上显得比例更高，但绝对CPU时间显示EBS进程花费了更多时间在CPU之外等待存储。

NVMe主机将其更多CPU容量用于执行有用的工作。这有助于解释更高的吞吐量：缓存未命中、WAL刷新和维护I/O仍然发生，但它们完成得更快，使PostgreSQL减少了对存储的阻塞时间。

持久性问题

在性能结果之后，演讲转向了明显的反对意见：实例存储NVMe与机器的生命周期绑定，因此本地数据会随着节点消失。操作问题是PostgreSQL能否将NVMe延迟与生产级可用性和恢复结合起来。

简短的回答是肯定的，前提是持久性由集群级别提供，而不是由任何单个Postgres节点提供。

在生产环境中运行NVMe支持的Postgres

在生产环境中在本地NVMe上运行PostgreSQL意味着要围绕快速但绑定到机器生命周期的存储进行设计。失去节点意味着丢失其本地数据副本；实例存储卷不能通过EBS API进行快照；可用容量取决于所选的实例类型。

演讲中介绍的生产架构通过三个主要需求解决了这个问题：复制数据库以便服务在节点丢失时存活，将备份和恢复数据存放在个体机器之外，并围绕每个实例类型上可用的NVMe规划容量。总之，这些模式使得在生产环境中自信地运行NVMe支持的PostgreSQL成为可能。

具有两个备用节点的高可用性

第一种模式是使用两个备用候选的基于仲裁的同步复制。通过这样的配置ANY 1 (备用1, 备用2)，事务可以在任一备用持久确认其WAL后提交，而不是等待较慢的那个。将节点分布在不同可用区可以防止AZ故障。

持续备份到对象存储以实现持久性

为了在数据库节点之外实现持久性，开源工具如WAL-G可以提供物理基础备份和持续WAL归档。通过低延迟的WAL传输，该架构可以将RPO目标设为秒级，并支持在保留窗口内进行时间点恢复。

备份和WAL还应保存在独立的故障域中，如果恢复计划需要应对整个区域的故障，则再保留一个区域副本。

备份作为恢复基础

基础备份和归档WAL不仅仅是紧急机制：相同的恢复历史可以支持时间点恢复、隔离分支、部署调整、只读副本播种和灾难恢复。

备份和复制解决不同的问题。在演讲描述的架构中，备用提供快速故障转移，而备份保护免受损坏、操作员错误和集群级故障的影响；两条恢复路径都需要定期测试。

生产中的示例

这种模式不仅是理论上的，演讲引用了Instacart的公开示例，它描述了在NVMe上的PostgreSQL用于对延迟敏感的工作负载，以及Datadog，它讨论了本地NVMe PostgreSQL实例用于需要它们的工作负载。反复出现的模式是本地存储用于性能，同步复制用于可用性，以及独立存储的基础备份和WAL归档用于恢复。

主要结论

演讲以一个诊断建议结束：当PostgreSQL似乎停止扩展时，同时检查数据库和存储。慢摄入、不可预测的读取延迟、膨胀压力、破坏性的检查点和复制滞后可能是存储层达到极限的信号。

底线刻意比标题更窄：本地NVMe可以显著减少存储密集型工作负载的I/O惩罚，但它带来了不同的操作模型。演讲中概述的架构使用基于仲裁的复制来实现可用性，并独立存储基础备份和归档WAL以实现恢复。