问IOPS对吞吐量。选择AWS EBS时使用哪一个？

EN

让我们试着解释什么是吞吐量和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 aaaaaaaam

I/O和吞吐量有关系吗？好的。如果您必须从EBS读取一个大文件，并且您的管道很小(也就是您的嘴很小，所以您的咬伤很小)，那么您需要更频繁地访问(I/O)，直到文件被完全读取为止。阿姆

另一方面，如果你有一个大嘴巴(大吞吐量)，那么你将需要更少的咬伤和更少的I/O. aaaam-aaaam。

因此，他们可以在某种程度上平衡彼此，but....there是一些角落的案例：

想象一下你有一个非常小的文件(或者巧克力纳米棒)。-在这种情况下，哪怕是最小的嘴巴也足够了.用一个大或小的嘴，你就能吃下整个纳米棒，只要一口。

假设你有一桶小小的小文件(或巧克力纳米棒)--在这种情况下，即使是最小的嘴也足以吞下每一根。无论是大吞吐量还是小吞吐量，都不会给您带来更好的性能。但是，拥有IOPS (每秒I/O)将提高您的性能。一个吞吐量EBS体积将表现远比IOPS伏鲁门。

想象一下，你有一桶成百亿的大文件。--所以你需要处理大文件，需要IOPS进行多次访问。那么也许你应该去做EBS的一般用途(它已经爆炸了)。

有了这个答案，你应该能想出答案，但对我来说：

但是，高I/O大小的频繁操作怎么办？-> EBS一般用途。在这里，“高”和“频繁”要求一个平衡的音量。

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

不频繁操作小I/O大小？->警告！你的“小”尺码是什么？如果他们是真正的小，那么我可能会去IOPS，因为一个大/小的嘴(吞吐量)不会有很大的区别。如果那些“不频繁”变成“频繁”(更多的用户?更复杂？)将从IOPS中受益。也许你也可以通过EBS的一般目的生存下来。但是，第二个警告，“不频繁操作”是什么意思?在这种情况下，您应该检查是否有一个冷HDD。

和往常一样，推荐只是recomendations...and最好的(因为你会对自己的“小”感感到惊讶)是在你有疑问的情况下测试性能。

用例：

• 工作负荷->通常是通用容量
• 数据库->通常是IOPS (小数据，但经常被检索)
• 大数据/数据仓库->通常是吞吐量(大数据文件)
• 冷硬盘->冷文件服务器(移动到磁性之前最低的IOPS )

(只是为了补充Victor的伟大答案)来自AWS基础核心概念文档的，不同存储服务在延迟、吞吐量和IOPS方面的性能特征如下。

如果您正在使用块存储服务(Amazon )：

• 延迟受卷类型的选择(例如固态驱动器与硬盘驱动器)的影响。
• 对于大多数卷类型，吞吐量和IOPS容量与体积大小成正比。

如果您使用的是文件系统服务(Amazon和Amazon家族)

• 延迟和IOPS受您选择的性能模式的影响。
• 吞吐量受您选择使用提供的吞吐量的影响。

如果您使用的是对象存储(Amazon )

• 延迟受到桶端点的地理距离的影响。
• 吞吐量受使用吞吐量优化的APIs (如多部分上载)的影响。
• IOPS是不可配置的

如果您使用的是存档存储

• 延迟受到桶端点的地理距离和检索方法的选择的影响。
• 吞吐量受使用吞吐量优化的APIs (如多部分上载)的影响。
• IOPS是不可配置的