DynamoDB何时限制请求? [英] When does DynamoDB throttle request?

查看:115
本文介绍了DynamoDB何时限制请求?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在以下答案中:如何计算和限制Amazon DynamoDB的吞吐量?",建议您在每秒钟超出预配置吞吐量的情况下DynamoDB限制请求.但是,这与我的经验相矛盾.

In the answer to "How is Amazon DynamoDB throughput calculated and limited?" it's been suggested, that DynamoDB throttles request whenever you exceed provisioned throughput on per second basis. However, this contradicts my experience.

我在表中发布了多行,通常行数超出了预配置的写入容量.这是短暂发生的.在某个时候,我甚至比配置的容量平均多了5分钟. OTOH,平均15分钟低于容量.在那段时间内,我没有收到任何限制请求.

I've table where I post multiple rows, often the number of rows way exceeding provisioned write capacity. This happens in short bursts. At one point I've even got 5 minutes average above provisioned capacity. OTOH, 15 minutes average is below capacity. I haven't got any throttled request in that period.

5分钟的平均峰值为8.053,预配置容量为6:

5 minutes average peaks at 8.053 with provisioned capacity of 6:

15分钟的平均峰值远低于配置的容量:

15 minutes average peaks well below provisioned capacity:

那么DynamoDB何时限制请求?考虑哪种平均水平?在突发受到限制之前,突发可以超出配置的容量有多高?

So when does DynamoDB throttle requests? What kind of average does it take in account? How high above provisioned capacity can the burst be before it gets throttled?

推荐答案

DynamoDB旨在确保每秒提供您的预配置容量.如果您以每秒10次1kB读取的速度提供一个表,则DynamoDB将为您提供足够的容量来处理该吞吐率.此外,DynamoDB有时会允许您在短时间内实现超出预配置吞吐量的有限突发.旨在吸收客户工作负载中的自然变化.无法保证此突发并且它并非始终可用(并且可用突发的性质可能会随时间而改变).正如最佳实践文档中当前所描述的,为了获得最佳性能,您应该有一个平均分配的工作负载,该工作负载不得超过您的预配置容量,并在关键空间上平均分配负载.但是,如果应用程序的生产行为的实际情况偏离了均匀分布的工作负载,则DynamoDB可能会吸收某些突发事件.

DynamoDB is designed to ensure that your provisioned capacity is available on a per-second basis. If you provision a table for ten 1kB reads per second then DynamoDB will give you enough capacity to handle that throughput rate. In addition, DynamoDB will sometimes allow you to achieve limited bursting above your provisioned throughput for a short period of time. This is intended to absorb natural variations in customer workloads. This bursting is not guaranteed and it is not always available (and the nature of the available bursting may change over time). As is currently described in the best practices documentation, in order to get the best performance you should have an evenly distributed workload that does not exceed your provisioned capacity and distributes the load evenly over the key space. However, if the reality of production behavior for your application deviates from an evenly distributed workload then DynamoDB may absorb some of the bursts.

关于要配置多少表,这在很大程度上取决于您的工作量.您可以先配置约80%的峰值,然后根据接收到的节流阀数(可以在CloudWatch图表中看到)和应用程序对重试引起的延迟的容忍度来调整表容量.请记住,DynamoDB不允许超出您配置的容量的无限突发.您也许可以吸收短暂的突发事件,但是您无法将吞吐率维持在超出预置容量水平的时间较长.我们可以提供的一般指导是在您的山峰附近准备一些东西,然后在观察油门时拨下.

As for how much to provision your table, it depends a lot on your workload. You could start with provisioning to something like 80% of your peaks and then adjust your table capacity depending on how many throttles you receive (which you can see in your CloudWatch graphs) and your application’s tolerance for latency induced by retries. Keep in mind that DynamoDB does not allow unlimited bursts above your provisioned capacity. You may be able to absorb short bursts but you cannot sustain a throughput rate above your provisioned capacity level for an extended period of time. The general guidance we can give is to provision for something close to your peaks and then dial down while watching for throttles.

此答案已发布在AWS论坛上

免责声明:我为Amazon DynamoDB团队工作.

Disclaimer: I work for Amazon, DynamoDB team.

这篇关于DynamoDB何时限制请求?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆