为何DynamoDB中非唯一GSI会引发延迟与吞吐量错误？

一、键过载引发延迟的核心原因 #

• DynamoDB的GSI会根据分区键值将数据分散到不同物理分区，若某个非唯一GSI键对应的数据量异常庞大（也就是“键过载”），所有针对该键的读写请求都会集中到同一个物理分区。
• 每个物理分区的处理能力有固定上限（比如IOPS、吞吐量阈值），大量请求挤在同一分区会造成请求排队等待，直接拉高响应延迟。
• 此外，超大容量的分区会增加DynamoDB后台维护的资源开销（比如分区拆分、跨节点数据同步），这部分额外消耗也会进一步加剧服务延迟。

二、“超级用户”导致吞吐量容量错误的成因 #

• 这里的“超级用户”指某个GSI分区键关联了极多的数据条目（比如某用户ID作为GSI键，对应上百万条记录）。
• DynamoDB的读写容量单位（RCU/WCU）是按GSI的物理分区分配的，当大量请求集中在这个“超级用户”的分区键上时，会快速耗尽该分区的可用容量配额。
• 哪怕整个GSI的总容量还有剩余，单个分区的容量耗尽后，后续请求就会被限流，触发ProvisionedThroughputExceededException这类吞吐量容量错误。
• 非唯一GSI的写入操作会同步到索引分区，若“超级用户”的条目频繁进行写入/更新，会持续占用该分区的WCU，更容易触发容量不足的问题。

内容的提问来源于stack exchange，提问作者Shade