logo标签列表

亚马逊DynamoDB的吞吐量是如何计算和限制的？

amazon-web-servicesamazon-dynamodb
38

这是按秒平均吗？每分钟？每小时？

例如，如果我购买了10个“读取单位”，允许每秒进行10次高度一致的读取，即使是在过去的一小时中仅有20次读取，如果我尝试在单个秒钟内执行20次读取，我会被限制吗？亚马逊的文档和常见问题解答没有回答我能找到的这个关键问题。

我在常见问题解答中唯一找到的相关回应完全忽略了如何计算使用量和何时发生限流的问题:

问： 如果我的应用程序执行的读写操作超过了我的预配容量会怎样？

答：如果您的应用程序执行的读/秒或写/秒操作超过了表的预配吞吐量容量，那么超出您的预配容量的请求将被限制，并且您将收到400错误代码。例如，如果您要求1,000个写入容量单位，并尝试以每秒1,500个1 KB项的速度进行写入，则DynamoDB只会允许1,000个写入/秒通过，并且您会收到400错误代码。您应该使用CloudWatch监视您的请求速率，以确保您始终具有足够的预配吞吐量来实现所需的请求速率。

7个回答
48

看起来他们跟踪五分钟内的写入并在过去五分钟的平均吞吐量超过您的预留吞吐量时对您进行限制。

我进行了一些测试。我创建了一个吞吐量为每秒1次写入的测试表。如果我不写入一段时间，然后发送一系列请求，亚马逊似乎会接受大约300个请求，然后开始限制。

当然，一个注意点是这没有在任何官方的亚马逊文档中说明，并且可能随时更改。

7
这是唯一一个真正理解提问者问题并试图给出合理回答的答案。 - Kevin Cantwell
2
我认为这不是真的。实际上，他们是按每个分区每秒进行测量，并且一旦吞吐量超过预配值，就会开始限制。因此，即使您的预配吞吐量远高于要求，您仍然可以看到很多被限制的错误。 - yura
我同意 @yura 的说法。即使云度量统计数据（5分钟平均）从未显示您超出容量，您仍可能会被限制。爆发可能会暂时帮助您，但如果您持续不断地出现峰值，最终您将被限制。 - Lee Jensen
你的数据大小很可能非常小。1kb 是一个数据读/写单元的组成部分。因此，也许你的 300 条目总共只有 4-5 kb 左右，处理它们需要 4:5 秒钟左右的时间。 - Ouroboros
我认为你遇到的是“突发容量”，因为文档中也提到了：“DynamoDB目前保留最多五分钟（300秒）未使用的读写容量”（http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.Bursting）。 - Ayush Pateria
13
9
如果我购买了10个“读取单位”，允许每秒进行10次高度一致的读取，即使这是过去一小时中唯一发生的20次读取，如果我尝试在一秒钟内进行20次读取，是否会被限制速率？
是的，这是由于Amazon DynamoDB的概念非常强调“快速和可预测的性能与无缝扩展” - 引用的常见问题解答已经正确地回答了这个问题（即你必须按照每秒操作数来计算），但Amazon DynamoDB中的预置吞吐量确实更好地说明了计算方法。 写入容量单位使您可以每秒执行一次1KB大小的项目的写入操作。同样，读取容量单位使您可以每秒执行一个强一致性读取（或两个最终一致性读取）1KB大小的项目。更大的项目将需要更多的容量。您可以通过估计每秒需要执行的读取或写入次数，并将其乘以项目大小（四舍五入到最近的KB）来计算所需的读取和写入容量单位的数量。
写入所需的容量单位=每秒项目写入次数x项目大小（四舍五入到最近的KB）
读取所需的容量单位*=每秒项目读取次数x项目大小（四舍五入到最近的KB）*如果使用最终一致性读取，则每秒读取吞吐量会增加两倍。
获取这些计算的正确结果以适用于实际情况可能会变得复杂，请务必仔细检查进一步的细节，例如 Amazon DynamoDB Provisioned Throughput Guidelines。
10
在我提问之前，我阅读了你引用的AWS网站上的信息，但我仍然觉得文字含义模糊。对我来说，它似乎也不合逻辑，因为这意味着每秒钟都会被计算，这将导致你必须始终进行大量超额配置以适应任何可能的短暂突发或遭受HTTP 400错误响应的后果。 - Brian McKelvey
2
在我看来，这项服务有意义的唯一方式是它至少应该有一点“可突发性”。对于这个定价，真正应该采用数据中心计费带宽的方式……即95分位计费。 - Brian McKelvey
你是否真的测试过并确定它是严格限制每秒的，还是只是你对他们发布的信息的理解方式？ - Brian McKelvey
1
@Brian：两者都有，尽管我只经历了这种限制，没有足够的数据来验证是否仍然存在这些限制之上的余地。然而，该设计对于目标用例（增量可扩展性、可预测的高性能）非常合理，并要求客户端调整其吞吐量要求（可能是即时的，但要注意相应的约束条件）以适应。[续...] - Steffen Opel
请记住，承诺在所选吞吐量水平下具有单位数字延迟且无需客户努力是完全不同的事情，可能需要在某些地方做出一些妥协；您可能需要阅读优秀的Amazon DynamoDB: First Look中的整个“吞吐量预留”部分，以获取有关隐含的定价模型特征的更多详细信息，在这里，亚马逊确实可以从所需的超额配置中获益。 - Steffen Opel
2

来自AWS：

DynamoDB目前保留了五分钟（300秒）的未使用读写容量。

DynamoDB在每个分区的吞吐量预配方面提供了一定的灵活性。当您没有充分利用分区的吞吐量时，DynamoDB会保留一部分未使用的容量以备后续的吞吐量使用突发。DynamoDB目前保留了五分钟（300秒）的未使用读写容量。在偶尔的读写活动突发期间，这些额外的容量单位可以被非常快速地消耗 - 甚至比您为表定义的每秒预配吞吐量容量更快。但是，请不要设计应用程序以依赖于随时可用的突发容量：DynamoDB可能会在没有事先通知的情况下将突发容量用于后台维护和其他任务。

为什么不在 @abjennings 的回复下面添加这些信息，因为它证实了他的假设？ - Henrique Gontijo
1

我猜他们故意没有明确说明。这可能会随时更改/有地区差异/取决于月亮和星星的位置，或者发布信息会鼓励滥用。我会按最坏情况进行计算。

0
我们为其中一个表设置了每秒“10 units/sec” 的'write-limit'。Cloudwatch图表（请参见图像）显示我们超过了一单位（每秒11 writes/sec）。我认为还有一点余地（<= 10%）。再次强调，这只是我的猜测...
根据我的经验，“ConsumedWriteCapacityUnits”与预配容量不在同一比例尺上。因为每个数据点代表5分钟，所以您必须将消耗的单位总和除以那些5分钟内的300秒，以获得可与预配吞吐量相比较的数字。 - Jeff Walker Code Ranger
-2
1
尝试添加一个示例或摘要，说明您提供的链接内容。支持资源在SO上很好，但不能作为我们的完整答案。 - Wolfie
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接