amazon-web-services - IOPS 与吞吐量。选择 AWS EBS 时使用哪个

Question

在选择合适的 EBS 卷类型时，我需要决定 if IOPS or throughput is a better performance measure.
问题是我不完全理解在哪种实际情况下它们中的每一个都比另一个更好。
该文档说“ 频繁 读/写操作 小 I/O 大小”非常适合IOPS。

但是呢？频繁 与 的操作高输入/输出大小？

不频繁 与 的操作高输入/输出大小？

不频繁 与 的操作小输入/输出大小？

为什么吞吐量不是“具有小 I/O 大小的频繁读/写操作”的完美衡量标准？

我在 this 中找不到答案和 this问题。

Answer 1

让我们试着解释什么是吞吐量和 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 中读取的信息量。举个例子，你可以用两种不同的方式吃整个巧克力棒，小口(小吞吐)或大口(大吞吐)，这取决于你的嘴巴大小。
吞吐量 EBS 卷专门用于执行大咬人:Ñam vs Ñaaaaaaaam

I/O 和吞吐量是否相关？当然。如果您必须从 EBS 读取一个大文件，并且您的吞吐量很小(也就是说，您的嘴很小，所以您的咬口很小)，那么您需要更频繁地访问 (I/O)，直到文件被完全读取。
Ñam-Ñam-Ñam-Ñam

另一方面，如果你有一张大嘴(大吞吐量)，那么你将需要更少的咬合和更少的 I/O。
Ñaaa​​am---Ñaaaam

所以他们可以以某种方式相互平衡，但是......有一些极端情况:

a) 想象一下，你有一个非常小的文件(或巧克力纳米棒)。
--- 在这种情况下，即使是最小的嘴也足够了。无论是大嘴还是小嘴，您只需咬一口就可以吃掉整个纳米棒。

b) 想象一下你有一桶无数的小文件(或巧克力纳米棒)
--- 在这种情况下，即使是最小的嘴也足以吞下每个酒吧。大或小吞吐量不会给你更好的性能。但是，拥有 IOPS(每秒 I/O)将提高您的性能。吞吐量 EBS 卷的性能将比 IOPS 卷差得多。

c) 想象一下，你有一大堆大文件。
--- 所以你需要大文件的吞吐量，你需要 IOPS 来进行多次访问。那么也许你应该转向 EBS 通用(它已经爆发了)

有了这个，你应该能够制定一个答案，但对我来说:

但是对于高 I/O 大小的频繁操作呢？ --> EBS 通用。这里的“高”和“频繁”要求平衡的音量。

不频繁的高 I/O 操作？ --> EBS 吞吐量。
你需要最大的嘴巴。

小 I/O 大小的操作不频繁？--> 警告!
什么是“小”尺寸？如果它们真的很小，那么我可能会选择 IOPS，因为大/小口(吞吐量)不会产生很大的不同。如果那些“不频繁”变成“频繁”(更多用户？更复杂？)将受益于 IOPS。也许您也可以使用 EBS 通用型来生存。
但是，第二个警告，“不频繁操作”是什么意思是这些文件不经常访问？在这种情况下，您应该检查冷硬盘

与往常一样，建议只是建议……最好的(因为您可能会对自己的“小”感感到惊讶)是在您有疑问的情况下测试性能。

用例:

工作负载 -> 通常通用卷

数据库 -> 通常 IOPS(小数据但经常检索)

大数据/数据仓库 -> 通常吞吐量(大数据文件)

冷硬盘 -> 冷文件服务器(移动到磁性之前的最低 IOPS)