- 新しい順
- 投票が多い順
- コメントが多い順
In on-demand mode read throttling occurs when you exceed twice your previous peak within 30 minutes, or you exceed your partition throughput limit of 3000 RCU per second.
While it may appear you are not exceeding the 3000 RCU, that is because CloudWatch works on a per-minute granularity, as thats the period DynamoDB emits metrics to CloudWatch. This means that you see a per min value, which is the average per second consumption within those 60 seconds.
The first step to overcoming a hot partition/key is to enable CloudWatch Contributor Insights, this will give you insight into which key(s) are causing the issue. From there you can understand if you can address the issue with some changes to your access patterns/code. If not then you may look into implementing a caching solution such as DAX which can offset your reads from the table to be served by DAX.
If you are using Strongly Consistent Reads, I would also suggest changing to Eventually Consistent Reads which can half your read throughput consumption.
関連するコンテンツ
- 質問済み 6年前
- AWS公式更新しました 1年前
- AWS公式更新しました 2年前
- AWS公式更新しました 1年前
We are using eventually Consistent Reads only. Added GSI Reads and throttles graph for reference
The issue, nor the suggested fixes do not change. Enable CCI, see what keys are hot and work out a fix in your access patterns. If thats not possible, use a cache in front such as DAX which is API compatible with DynamoDB.