How does throttling on my global secondary index affect my Amazon DynamoDB table?
My global secondary index (GSI) is throttled.
Short description
Throttling on a GSI affects the base table in different ways. The effect depends on whether the throttling is for read activity or for write activity:
- When a GSI has insufficient read capacity, throttling doesn't affect the base table.
- When a GSI has insufficient write capacity, throttling results in write operations that fail on the base table or any of its GSIs.
For more information, see Using global secondary indexes in DynamoDB.
Resolution
To prevent throttling, follow these steps:
- Be sure that the provisioned write capacity for each GSI is equal to or greater than the provisioned write capacity of the base table. To modify the provisioned throughput of a GSI, use the UpdateTable operation. If you turned on automatic scaling for the base table, then it's a best practice to apply the same settings to the GSI. To do this, choose Copy from base table in the DynamoDB console. For best performance, turn on Use the same read/write capacity settings for all global secondary indexes. This allows DynamoDB auto scaling to uniformly scale all the global secondary indexes on the base table. For more information, see Activating DynamoDB auto scaling on existing tables.
- Be sure that the GSI's partition key distributes read and write operations as evenly as possible across partitions. This helps prevent hot partitions and therefore throttling. For more information, see Designing partition keys to distribute your workload.
- To identify the most frequently throttled keys, use Amazon CloudWatch Contributor Insights for DynamoDB.
This (the throttling of writes that can occur due to a hot GSI key) is a real shame. As it defeats one of the main reasons you would use a GSI in the first place - i.e. to enable querying by commonly occuring attributes. As GSIs do not support consistent read operations anyway surely there is a way of removing or mitigating this limitation?
Thank you for your comment. We'll review and update the Knowledge Center article as needed.
This (the throttling of writes that can occur due to a hot GSI key) is a real shame. As it defeats one of the main reasons you would use a GSI in the first place - i.e. to enable querying by commonly occuring attributes.
This is not a simple issue.
DynamoDB's GSi allows duplicated values even with the same primary key of GSI. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html
ALL – The secondary index includes all of the attributes from the source table. Because all of the table data is duplicated in the index, an ALL projection results in the largest possible secondary index.
In addition, DynamoDB supports isolate frequently accessed items. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/burst-adaptive-capacity.html
If your application drives disproportionately high traffic to one or more items, adaptive capacity rebalances your partitions such that frequently accessed items don't reside on the same partition.
Therefore, DynamoDB may avoid/mitigate throttling of writes that can occur due to a hot GSI key.
Thank you for your comment. We'll review and update the Knowledge Center article as needed.
Relevant content
- asked 2 years ago
- asked 7 years ago
- asked 3 years ago
- AWS OFFICIALUpdated 23 days ago
- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated 4 months ago
