3

There's something which I cant understand about AWS DynamoDb throughput.

Lets consider strongly consistent reads.

Now, I understand that in this case, 1 unit of capacity would mean I can read up to 4KB of per second.

It's the "per second" bit that slightly confuses me. If you know exactly how quickly you want to read data then you can set the units appropriately. But what if you're not too fussy about the read time?

Say I do have only 1 read unit assigned to my table and I try to read an item which is more than 4KB. Now surely that just means that my read is going to take more than 1 second? That would be fine but the documentation talks about Requests failing. How can AWS determine that I used too many units when I didn't request that the data be read within a particular time?

Maybe I am missing something obvious. Can you someone help clear this up?

Connor Bishop
  • 921
  • 1
  • 12
  • 21

1 Answers1

4

DynamoDB can consume up to 300 seconds of unused throughput in burst capacity.

The maximum item size in DynamoDB is 400KB and 1 RCU gives you a read of up to 4KB.

Lets say you want to read an item that is 400KB in size and you have 1 RCU on your table. You could retrieve that item once every 100 seconds.

Because of burst capacity there will always be a time you can read that item, because in fact you can use up to 300 RCUs in one go, not just 1.

Imagine starting the table with that 400KB item. You need to wait 100 seconds without spending any RCUs so that you've earned enough burst capacity to get the item. After 101 seconds you make the request, spend 100 RCUs and get the item. After another 5 seconds you make the request again, but get denied with a Throttling Exception.

So no, DynamoDB will not increase request latency to meet your RCU provision. It either returns your results as fast as possible, or throws an exception.

EDIT: By the way, I should mention that all AWS DynamoDB SDKs handle Throttling Exceptions for you. If you try and read an item, but get denied because you don't have enough throughput available, the SDK backs off and try again. So unless your table really is under provisioned, you shouldn't have to worry about handling Throttling Exceptions.

F_SO_K
  • 13,640
  • 5
  • 54
  • 83
  • Thank you for your explanation. I now understand the concept. When you say that the SDKs handle the throttling exceptions, does that mean that a throttling exception won’t cause my getItem callback to be called? (Unless really under provisioned). I’m using the node sdk. – Connor Bishop Jan 16 '18 at 22:06
  • 2
    The SDK will retry up to 10 times for you, over a total of 25 seconds. If after 10 tries you still haven't performed your request due to lack of throughput provision, then a ThrottlingException is passed back to your application and you can handle it. Note that the number of retries and back-off time is configurable. Have a look at one of my other answers [here](https://stackoverflow.com/a/48025081/4985580). And up vote it if its helpful :) – F_SO_K Jan 16 '18 at 22:11