37

Is it averaged per second? Per minute? Per hour?

For example.. if I pay for 10 "read units" which allows for 10 highly consistent reads per second, will I be throttled if I try to do 20 reads in a single second, even if it was the only 20 reads that occurred in the last hour? The Amazon documentation and FAQ do not answer this critical question anywhere that I could find.

The only related response I could find in the FAQ completely ignores the issue of how usage is calculated and when throttling may happen:

Q: What happens if my application performs more reads or writes than my provisioned capacity?

A: If your application performs more reads/second or writes/second than your table’s provisioned throughput capacity allows, requests above your provisioned capacity will be throttled and you will receive 400 error codes. For instance, if you had asked for 1,000 write capacity units and try to do 1,500 writes/second of 1 KB items, DynamoDB will only allow 1,000 writes/second to go through and you will receive error code 400 on your extra requests. You should use CloudWatch to monitor your request rate to ensure that you always have enough provisioned throughput to achieve the request rate that you need.

Brian McKelvey
  • 853
  • 1
  • 8
  • 12

7 Answers7

47

It appears that they track writes in a five minute window and will throttle you when your average over the last five minutes exceeds your provisioned throughput.

I did some testing. I created a test table with throughput of 1 write/second. If I don't write to it for a while and then send a stream of requests, Amazon seems to accept about 300 before it starts throttling.

The caveat, of course, is that this is not stated in any official Amazon documentation and could change at any time.

abjennings
  • 2,663
  • 3
  • 22
  • 22
  • 6
    This is the only answer that actually understands the OP's question and attempts to give a sound response. – Kevin Cantwell Nov 14 '13 at 22:34
  • 2
    I think it is not true. They actually measure it per partition per second based and will start throttling the second you throughput is above provisioned. So you can acutlly see al ot of thottled errors even if your provisioned througput is way above – yura Apr 20 '15 at 20:04
  • I second what @yura said. You can get throttled even if the cloud metric stats (5 minute average) never show you going above your capacity. Bursting might save you for a bit, but eventually you will get throttled if you are spiking consistently. – Lee Jensen Jul 01 '15 at 16:04
  • It's highly likely your data size is very small. 1kb is what comprises a data read/write unit. So maybe your 300 entries totally were 4-5 kb or some such, and it took 4:5 seconds to finish processing them. – Ouroboros Aug 28 '16 at 09:08
  • I think what you encountered was the 'Burst Capacity' as it is also mentioned in the documentation - "DynamoDB currently retains up to five minutes (300 seconds) of unused read and write capacity" (http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.Bursting). – Ayush Pateria Jun 14 '17 at 12:05
12

The DynamoDB provides 'Burst Capacity' which allows for spikes in amount of data read from table. You can read more about it under: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.Bursting

Basically it's what @abjennings noticed - It uses 5min window to average number of reads from a table.

Piotrek
  • 146
  • 1
  • 5
9

If I pay for 10 "read units" which allows for 10 highly consistent reads per second, will I be throttled if I try to do 20 reads in a single second, even if it was the only 20 reads that occurred in the last hour?

Yes, this is due to the very concept of Amazon DynamoDB being fast and predictable performance with seamless scalability - the quoted FAQ is actually addressing this correctly already (i.e. you have to take operations/second literally), though the calculation is better illustrated in Provisioned Throughput in Amazon DynamoDB indeed:

A unit of Write Capacity enables you to perform one write per second for items of up to 1KB in size. Similarly, a unit of Read Capacity enables you to perform one strongly consistent read per second (or two eventually consistent reads per second) of items of up to 1KB in size. Larger items will require more capacity. You can calculate the number of units of read and write capacity you need by estimating the number of reads or writes you need to do per second and multiplying by the size of your items (rounded up to the nearest KB).

Units of Capacity required for writes = Number of item writes per second x item size (rounded up to the nearest KB)

Units of Capacity required for reads* = Number of item reads per second x item size (rounded up to the nearest KB) * If you use eventually consistent reads you’ll get twice the throughput in terms of reads per second.

[emphasis mine]

Getting these calculations right for real world use cases is potentially complex though, please make sure to check further details like e.g. the Provisioned Throughput Guidelines in Amazon DynamoDB as well accordingly.

Steffen Opel
  • 63,899
  • 11
  • 192
  • 211
  • 10
    I read the information you quote above on the AWS site before asking the question, and I still find the text to be ambiguous. It also seems illogical to me that it would be literally calculated each second, since that would mean that you would always have to substantially over-provision to accomodate any possible short burst or suffer the consequences of getting HTTP 400 error responses for the extra reads/writes. – Brian McKelvey Feb 24 '12 at 11:25
  • 2
    IMO, the only way this service makes any sense would be for it to be at least a little bit "burstable." The pricing for this really ought to work similarly to the way data centers charge for bandwidth... i.e. 95th percentile billing. – Brian McKelvey Feb 24 '12 at 11:27
  • Have you actually tested it and know for certain that it is strictly limited, second by second, or is that just the way you interpret their posted information? – Brian McKelvey Feb 24 '12 at 11:28
  • 1
    @Brian: Both, though I only experienced the throttling as such and haven't enough data to verify, whether their might be some wiggle room still above these limits. However, the design is quite reasonable for the targeted use cases (incremental scalability, predictable high performance), and asking clients to back off and adjust their throughput requirements (potentially on the fly, but beware of [respective constraints](http://stackoverflow.com/a/8941274/45773)) accordingly. [continued ...] – Steffen Opel Feb 24 '12 at 12:03
  • [... continued] Please bear in mind, that promising _single digit latency at a selected throughput level with zero customer effort required_ is an entirely different ballgame, likely requiring some compromises somewhere; you might want to read the entire section _Throughput Reservation_ within the excellent [Amazon DynamoDB: First Look](http://redmonk.com/sogrady/2012/01/19/dynamodb/) for more details on the implied pricing model characteristics, where Amazon might benefit from the required over-provisioning indeed. – Steffen Opel Feb 24 '12 at 12:08
1

From AWS :

DynamoDB currently retains up five minutes (300 seconds) of unused read and write capacity

DynamoDB provides some flexibility in the per-partition throughput provisioning. When you are not fully utilizing a partition's throughput, DynamoDB retains a portion of your unused capacity for later bursts of throughput usage. DynamoDB currently retains up five minutes (300 seconds) of unused read and write capacity. During an occasional burst of read or write activity, these extra capacity units can be consumed very quickly—even faster than the per-second provisioned throughput capacity that you've defined for your table. However, do not design your application so that it depends on burst capacity being available at all times: DynamoDB can and does use burst capacity for background maintenance and other tasks without prior notice.

Steven Muhr
  • 3,339
  • 28
  • 46
1

My guess would be that they don't state it explicitly on purpose. It's probably liable to change/have regional differences/depend on the position of the moon and stars, or releasing the information would encourage abuse. I would do my calculations on a worst-scenario basis.

Jonatan Hedborg
  • 4,382
  • 21
  • 30
0

We set our 'write-limit' to 10 units/sec for one of the tables. Cloudwatch graph (see image) shows we exceeded this by one unit (11 writes/sec). I'm assuming there's a small wiggle room (<= 10%). Again , i'm just assuming ...

Smita
  • 4,634
  • 2
  • 25
  • 32
Venkat
  • 11
  • In my experience, "ConsumedWriteCapacityUnits" is not on the same scale as provisioned capacity. Because each data point represents 5 minutes, you have to divide the sum of consumed units by 300s in those 5 minutes to get a number that is comparable to provisioned throughput. – Jeff Walker Code Ranger Nov 04 '14 at 12:26
-2

https://aws.amazon.com/blogs/developer/rate-limited-scans-in-amazon-dynamodb/

Using google guava library to use rateLimiter class to limit the consumed capacity is possible.

prashant
  • 1
  • 1
    Try and add an example or summary of what is at the link you supplied. Supporting resources are good on SO, but not as our entire answer. – Wolfie Mar 20 '17 at 11:29