在选择合适的 EBS 卷类型时，我需要确定 if IOPS or throughput is a better performance measure.
问题是我不完全理解在哪种实际情况下他们每个人都比另一个更好。
该文档说“频繁 读/写操作 small I/O 大小”非常适合 IOPS。
为什么吞吐量不是“以小 I/O 大小进行频繁读/写操作”的完美衡量标准？
【问题讨论】：
标签： amazon-web-services amazon-ec2 amazon-ebs
让我们试着解释一下什么是吞吐量和 I/O。
I/O 是对磁盘的访问次数。每次需要读取文件时，都需要“至少”访问一次文件。然而，内容是以“块”读取的，每次读取“块”时都会请求一个新的 I/O。 想象一下咬巧克力棒，您至少需要访问巧克力棒一次，然后您开始咬 (I/O) 直到结束它。每一口都是一个 I/O。您需要几个 I/O 才能吞下整个酒吧。
IOPS 是每秒 I/O。速度。因此，基本上我们可以在巧克力棒中执行每种咬合的速度。 IOPS EBS 是专门用于执行快速咬合的卷：Ñam-Ñam-Ñam vs Ñam-----Ñam-----Ñam
吞吐量是您在每个I/O中阅读的信息的数量。按照这个例子，你可以用两种不同的方式吃整个巧克力棒，小口（小吞吐量）或大口（大吞吐量），这取决于你的嘴巴大小。 Througput EBS 卷专门用于执行大咬：Ñam vs Ñaaaaaaaaam
I/O 和吞吐量是否相关？当然。如果您必须从 EBS 读取一个大文件，并且您的吞吐量很小（也就是说，您的嘴巴很小，所以您的咬痕很小），那么您需要更频繁地访问（I/O），直到文件被完全读取。 Ñam-Ñam-Ñam-Ñam
另一方面，如果你有一个大嘴（大吞吐量），那么你将需要更少的咬和更少的 I/O。 Ñaaaam---Ñaaaam
所以他们可以以某种方式相互平衡，但是....有一些极端情况：
a) 想象一下，你有一个非常小的非常小的小文件（或巧克力纳米棒）。 --- 在这种情况下，即使是最小的嘴也足够了。无论是大嘴巴还是小嘴巴，您只需 1 口就可以吃掉整个纳米棒。
b) 想象一下，您有一桶无数的微小文件（或巧克力纳米棒） --- 在这种情况下，即使是最小的嘴也足以吞下每一根。大小的吞吐量不会给您更好的性能。但是，拥有IOPS（每秒I/O）会提高您的性能。吞吐量 EBS 卷的性能将比 IOPS 卷差得多。
c）想象一下您有一桶数十亿个大文件。 --- 所以你需要吞吐量来处理大文件，你需要 IOPS 来进行多路访问。那么也许你应该去一个 EBS 通用（它已经爆发了）
您应该能够做出答案，但对我来说：
但是，高I/O大小的频繁操作呢？ --> EBS 通用。在这里，“高”和“频繁”要求平衡卷。
高 I/O 大小的操作不频繁？ --> EBS 吞吐量。 你需要尽可能大的嘴。
不经常使用小的I/O大小？ - >警告！ 对你来说什么是“小”尺寸？如果它们真的很小，那么我可能会选择 IOPS，因为大/小嘴（吞吐量）不会有很大的不同。如果那些“不频繁”变成“频繁”（更多用户？更复杂？）将受益于 IOPS。然后，您可能还可以使用EBS通用目的生存。 但是，第二个警告，“不频繁操作”是什么意思那些文件不经常访问？在这种情况下，你应该检查冷硬盘
与往常一样，建议只是建议……最好（因为您会对自己的“小”感感到惊讶）是在您有疑问的情况下测试性能。
用例：
【讨论】：
（只是为了补充 Victor 的精彩回答）来自AWS Fundamentals Core Concepts 文档，不同存储服务在延迟、吞吐量和 IOPS 方面的性能特征如下。
如果您使用的是块存储服务 (Amazon EBS)：
如果您使用的是文件系统服务（Amazon EFS 和 Amazon FSx 系列）
如果您使用的是对象存储 (Amazon S3)
如果您使用的是档案店
【讨论】：