nic*_*tev 7 amazon-ec2 amazon-ebs amazon-web-services
在选择合适的 EBS 卷类型时，我需要确定IOPS 还是吞吐量是更好的性能指标。
问题是我不完全理解在哪种实际情况下它们中的每一个都比另一个更好。
该文档说“具有小I/O 大小的频繁读/写操作”非常适合 IOPS。
为什么吞吐量不是“具有小 I/O 大小的频繁读/写操作”的完美衡量标准？
小智 24
让我们试着解释什么是吞吐量和 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 与 Ñaaaaaaaam
I/O 和吞吐量是否相关？当然。如果您必须从 EBS 读取一个大文件，并且您的吞吐量很小（也就是说，您的嘴很小，所以您的咬口很小），那么您需要更频繁地访问 (I/O)，直到文件被完全读取。Ñam-Ñam-Ñam-Ñam
另一方面，如果你有一张大嘴（大吞吐量），那么你需要更少的咬和更少的 I/O。Ñaaaam---Ñaaaam
所以他们可以以某种方式相互平衡，但是......有一些极端情况：
a) 想象一下，你有一个非常小的文件（或巧克力纳米棒）。--- 在这种情况下，即使是最小的嘴也足够了。无论是大嘴还是小嘴，您只需咬一口就可以吃掉整个纳米棒。
b) 想象一下，你有一桶无数细小的文件（或巧克力纳米棒）——在这种情况下，即使是最小的嘴也足以吞下每一块。大或小吞吐量不会给你更好的性能。但是，拥有 IOPS（每秒 I/O）将提高您的性能。吞吐量 EBS 卷的性能将比 IOPS 卷差得多。
c) 想象一下，你有一大堆大文件。--- 所以你需要大文件的吞吐量，你需要 IOPS 来进行多次访问。那么也许你应该转向 EBS 通用（它已经爆发了）
有了这个，你应该能够制定一个答案，但对我来说：
但是对于高 I/O 大小的频繁操作呢？--> EBS 通用。这里的“高”和“频繁”要求平衡的音量。
不频繁的高 I/O 操作？--> EBS 吞吐量。你需要最大的嘴巴。
小 I/O 大小的操作不频繁？--> 警告！什么是“小”尺寸？如果它们真的很小，那么我可能会转向 IOPS，因为大/小嘴（吞吐量）不会产生很大的不同。如果那些“不频繁”变成“频繁”（更多用户？更复杂？）将受益于 IOPS。也许您也可以使用 EBS 通用型来生存。但是，第二个警告，“不频繁操作”是什么意思是这些文件不经常访问？在这种情况下，您应该检查冷硬盘
与往常一样，建议只是建议……最好的（因为您可能会对自己的“小”感感到惊讶）是在您有疑问的情况下测试性能。
用例：
（只是为了补充 Victor 的精彩答案）根据AWS 基础核心概念文档，不同存储\xc2\xa0 服务在延迟、吞吐量和\xc2\xa0IOPS 方面的性能特征如下。
\n如果您使用的是块存储服务 (Amazon EBS)：
\n如果您使用文件系统服务（Amazon EFS 和 Amazon FSx 系列）
\n如果您使用对象存储 (Amazon S3)
\n如果您使用的是档案库
\n| 归档时间： |
|
| 查看次数： |
1626 次 |
| 最近记录： |