我了解IOPS和吞吐量。 吞吐量度量数据stream量，MB / s和IOPS表示每秒发生多less次I / O操作。
我不明白的是为什么许多存储服务只显示它们提供的IOPS。 我真的不能看到任何我更想知道IOPS而不是吞吐量的场景。
为什么IOPS很重要？ 为什么AWS主要在IOPS中显示其存储规定？ IOPS在哪里比吞吐量（MB / s）更重要？
编辑：
有些人正在研究这个问题，就好像我问过什么样的随机存取以及它是如何影响性能或HDD和SSD如何工作的……尽pipe我认为这些信息对于新手来说是非常有用的，但是很多关注点正在被应用对于这个问题，这不是问题的目标，问题是“当我看到一个IOPS编号时，会得到什么样的新信息，以致于我看不到吞吐量（MB / s）数？
吞吐量
吞吐量对于复制文件等事情非常有用。 当你做任何事情时，它是随机读取和写入磁盘，将限制你。
IOPS
IOPS通常指定每个数据包的大小。 例如，AWS gp2可以以16 KiB有效负载大小执行10,000 IOPS。 这倍增到160MiB /秒。 但是，您可能不会始终使用完整的有效负载大小，因此实际吞吐量可能会更低。 NB KiB是1024字节，KB是1000字节。
由于IOPS指定的数据包大小也确实可以提供总吞吐量。 高吞吐量并不意味着您拥有较高的IOPS。
scheme
考虑这些情况：
LTO磁带
考虑一下磁带备份系统。 LTO6可以做到400MB /秒，但是（我在这里猜测）可能甚至不能做一个随机IOP，它可能是每个IOP秒低。 另一方面，如果将IOPS定义为读取或写入磁带的数据，则可能会执行大量顺序IOPS。
如果你试图从磁带上启动一个操作系统，它将需要很长时间，如果它工作的话。 这就是为什么IOPS通常比吞吐量更有帮助的原因。
要了解存储设备，您可能想知道它是随机还是顺序IOPS，以及IO大小。 从这个你可以得到吞吐量。
AWS
请注意，AWS 在本页面上发布了所有存储types的IOPS和吞吐量数据。 通用SSD（gp2）可以做10,000个16KiB IOPS，最高可达160MB /秒。 预置IOPS（io1）为20,000个16KiB IOPS，最高可达320MB /秒。
请注意，使用gp2卷时，每GB预置30IOPS，因此要获得10,000 IOPS，则需要333.33GB的卷。 我不记得io1卷是否有类似的限制（从那个testingtypes的相关考试开始，我已经有一段时间了），但是我怀疑他们是否这样做了，如果是这样的话，大概是每GB有60IOPS。
结论
高顺序吞吐量是有用的，在某些情况下是性能的限制因素，但在大多数情况下，高IOPS可能更为重要。 无论IOPS如何，您仍然需要合理的吞吐量。
这是因为顺序吞吐量不是大多数I / O活动发生的原因。
随机读取/写入操作更能代表正常的系统活动，并且通常受到IOPS的约束。
将色情服务从我的一台服务器stream向我们的客户（或上传到我们的CDN）本质上是更连续的，您将看到吞吐量的影响。
但是维护数据库的目录色情和跟踪通过网站的用户活动本质上是随机的，并受底层存储所能支持的小I / O操作次数的限制。
我可能需要2000 IOPS才能在高峰使用时运行数据库，但由于活动types的缘故，磁盘级别的吞吐量可能只有30MB / s。 磁盘能力为1200MB / s，但是IOPS是环境的限制。
这是描述存储系统容量潜力的一种方式。 SSD可能具有80,000 IOPS和600MB / s吞吐量的能力。 您可以使用6个普通10k SAS磁盘来获得吞吐量，但只能产生大约2,000 IOPS。
虽然ewwhite的答案是完全正确的，但我想提供一些更具体的数字来帮助解释为什么差异很重要。
正如ewwhite已经正确说明的那样，大多数非stream式应用程序主要执行非顺序磁盘操作，这就是除了理论峰值吞吐量之外IOPS的重要性。
当我和同事首先在我们的开发系统中安装固态硬盘来replace我们以前使用的硬盘时，我们对它们进行了一些性能测量，这真的强调了为什么这很重要：
顺序读取吞吐量：〜100 MB / s
非顺序读取吞吐量（2k块，IIRC）：〜1 MB / s
顺序读取吞吐量：〜700 MB / s
非顺序读取吞吐量（2k块，IIRC）：〜125 MB / s
从示例中可以清楚地看到，仅列出每个设备的最大吞吐量将会给出一个极其不准确的图像。 在读取大文件时，SSD的速度只有硬盘的6-7倍，但是从磁盘的不同部分读取小块数据时，SSD的速度要快100倍。 当然，对于硬盘驱动器来说，这个限制主要是由于硬盘驱动器必须物理地将读写头移动到所需的磁道上，然后等待所需的数据在磁头下旋转，而固态硬盘没有物理部分移动。
我们的编译时间比最大吞吐量的简单比较提高得多。 以前花了30多分钟的构build现在已经完成了大约一分钟，因为大型构build中的磁盘I / O包括读取和写入大量单独的源文件，这些源文件不是单独很大，并且可能遍布整个磁盘。
通过提供吞吐量和IOPS数量，您可以更好地了解特定工作负载在给定存储设备上的执行情况。 如果您只是传输大量没有分散的数据，那么您将接近最大吞吐量。 但是，如果您正在进行大量的小型读取和/或写入，而这些读取和/或写入不是按顺序存储在磁盘上的，则会受到IOPS的限制。
要执行IO操作，驱动器必须经过一系列操作。 对于他们需要的机械硬盘驱动器。
3所花费的时间取决于数据块的大小，但1和2所用的时间与请求的大小无关。
标题吞吐量和IOP数字代表极端情况。 标题input数字代表每个操作涉及大块数据的情况，所以驱动器花费大部分时间来实际移动数据。
标题IOP数字表示数据块非常小的情况，因此大部分时间花费在寻找磁头并等待盘片旋转。
对于许多工作负载来说，这些块足够小以至于要传输的块的数量比块的大小要重要得多。
IO卷有两种types的瓶颈（实际上一般是IO）。
实际性能实际上被测量为包括基于移动的数据量的组件，由可用带宽或类似单位成本*尺寸缩放，但是也存在与请求相关联的开销，即不变的是磁盘，networking或许多其他的事情。
单位成本*大小+开销。 线的方程。
如果单位成本很大，或者规模很大，那么基于这些数据的收费是有意义的，例如移动电话networking，另一方面，有时候这些成本更为重要。
你可以自己做一个简单的实验，创build一个带有几个1GB文件的目录（或者任何实际的东西，足够大的东西需要几秒钟来读/写），然后创build一个包含一百万个100字节文件的文件夹（注意，这是0.1GB的数据），然后看看当你开始尝试在不同的分区/磁盘之间移动所有的东西时，你的吞吐量会发生什么变化 – 你将得到吞吐量为大文件所限制的性能，更小的东西的文件数量。
我会假设亚马逊意识到这两种收费模式，并简单地发现一个更好地代表了他们的基础设施的能力。
IOP的大小与商店可以在“周期”中传输的数量有很大的关系，因此，大量的请求最终还是要花费您的多个IOPS。
亚马逊本身有一个很好的关于IOPS和成本的东西，他们通过优化传递“节约”
I / O特性和监控
如果你对这个领域感兴趣的话，看起来不是很有趣，但看起来很有意思。
一般来说，IOPS比吞吐量更难获得。 如果您拥有大量IOPS，则大多数情况下您将拥有足够的吞吐量。
使用经典的硬盘驱动器时，轴的数量是您的限制因素，因为磁头必须在每个驱动器上进行物理移动：速度非常慢。 SSD具有更好的IOPS容量。
如果你只有一个用户，将一个大文件复制到networking上，那么你可能只有十几个用户来获取数据，剩下的只能从磁盘上stream式传输。
但是，如果您正在访问数据库或者拥有大量并发用户，那么您将不得不同时访问存储的不同部分，从而导致IOPS暴增。
在一个关系数据库上只更新10行可能会导致产生数百个IO：读取索引，读取数据，附加日志文件，更新索引和数据。 大多数操作系统和数据库都会尽可能地通过caching和延迟/分组来限制IO的数量。
我也会回答我自己的问题，因为我认为大部分答案都是非常重要的，答案可能会简单得多：
如果您仅查看存储设备吞吐量，则可能会错过正在进行的操作。如果吞吐量较低（低MB / s），则可能是设备速度较慢，或者在HDD或某些其他设备中有大量随机访问这并不能很好地处理随机访问。
通过查看IOPS并了解每个I / O操作的块大小，您可以知道存储设备能够处理多less存取以及这些IOPS（块大小* IOPS）的吞吐量。
所以看着高IOPS，你可以得出结论，你的存储设备正在处理大量的随机存取，即使这是伴随着低吞吐量….或者你正在考虑低吞吐量，低吞吐量，这意味着你的设备只是闲。
所以通过查看IOPS我们可以了解吞吐量实际上意味着什么，它们都是相辅相成的。
回答你的问题
“当我看到一个IOPS号码时，我得到了什么新的信息，我不会看到吞吐量（MB / s）的数字？
直接指定的队列深度和文件大小可以每秒存储多less个IO操作 。 您可以使用以下公式计算给定条件下的吞吐量：
IOPS *文件大小=吞吐量
存储testing可能会生成不同数量的IOPS，具体取决于文件大小和队列深度。 在队列深度= 1或2时，控制器不会利用caching，而在队列深度32,256,512的数字上升几次，并没有太大的变化。 在文件大小为128KB的情况下，IOPS数可能会低于4KB文件，但是通过输出 – 更高。
评估存储性能的最佳方法是在几个不同的块大小和队列深度下寻求IOPS和吞吐量testing。