正文
IOPS 的爆发和限制——滑坡效应
如前所述，类似的查询很快会耗尽
IO 信用。面对需要更多 IOPS 的情况，一个直接的解决方案是增加存储容量，以便将基线 IOPS 从3000提高到 10000。然而，这会导致备份成本增加，因为你需要为整个卷支付费用，而不仅仅是已使用的部分。这样一来，成本增加了，但性能提升却有限，从而引发了成本和性能的雪球效应。
此外，我们还尝试增加实例大小，以便获得更多的缓存内存。如果能将所有数据都载入内存，理论上可以让数据库运行得更快。虽然 PostgreSQL v10 带来的更大并行化功能充满诱惑，但遗憾的是，由于 IO 的限制，我们实际收益不大。
关于测量吞吐量问题的更多细节，可以参见下面的链接：
https://www.datadoghq.c
om/blog/aws-ebs-latency-and-iops-the-surprising-truth/
Aurora 迁移
因此，我们决定迁移到 Aur
ora，它相比于传统 PostgreSQL，承诺提供 5 至 7 倍的性能提升，这一点对我们有非常强的吸引力。这些性能提升指标基于 pgbench 测试结果，在测试 PostgreSQL 性能时确实有效。如果你运营一个 OLTP 系统，并期望在有大量并行客户端的情况下测量事务速度（或延迟），pgbench 是一个很好的工具。但对于那些处理大数据集和进行数据挖掘操作的场景，pgbench 并不是一个理想的性能评估指标。这会带来是成本的上升。
关于 IOPS 和计费 IOPS 的讨论详见：
https://forums.aws.amazon.com/message.jspa?messageID=835303#835303
