I've been reading FAQs and other posts here, trying to understand DynamoDB's behavior with respect to read and write capacity units. Say I scan a table and this exceeds my read capacity units. Am I correct in assuming DynamoDB will throttle the request first, still returning all the results, just in slower fashion? At what point will the request simply fail, instead of being throttled?
1
votes
1 Answers
4
votes
If your request exceeds the provisioned capacity, you will receive a ProvisionedThroughputExceededException error.
The Error Handling documentation says:
Your request rate is too high. The AWS SDKs for DynamoDB automatically retry requests that receive this exception. Your request is eventually successful, unless your retry queue is too large to finish. Reduce the frequency of requests, using exponential backoff.
Also, please note that DynamoDB provides Burst Capacity. From the Guidelines for Working with Tables documentation:
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 to 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.
Thus, the combination of automatic retries plus burst capacity means that it is less-likely you will receive throughput exceptions. If you do, then exponentially back-off and retry.
Some DynamoDB users maintain an Amazon SQS queue for temporary storage of transactions. If throughput is exceeded, they store the transaction in the SQS queue. Then, a background process retrieves the transactions from the queue and retries them later, when hopefully more throughput is available.
