DynamoDB低基数分区键使用方案及二级索引问题咨询

核心场景拆解 #

你需要构建包含status、user_id、attribute_1至attribute_n的DynamoDB表，核心需求是大量仅按status过滤的查询，且status仅存在enabled和disabled两个值，基数极低。

方案对比与最优选择 #

方案1：直接将status设为分区键 #

• 优势：无需额外索引，直接支持按status的高效查询，成本最低。
• 隐患：数据会集中在两个分区，一旦某一状态（比如enabled）的数据量极大、查询请求密集，会触发热点分区问题——该分区的吞吐量会被打满，出现限流、响应延迟飙升的情况。

方案2：user_id作分区键 + 以status为分区键的全局二级索引（GSI） #

• 优势：user_id基数高，主表数据能均匀分散，避免主表热点；通过GSI仍可实现按status查询。
• 隐患：GSI本身会继承低基数分区键的问题，同样可能出现热点；同时写入主表时需要同步写入GSI，会产生写入放大，增加成本和延迟；GSI还会额外占用存储资源。

最优折中方案：status+随机后缀作为复合分区键 #

如果核心查询场景就是按status过滤，且数据量/请求量较大，推荐用复合分区键：把status和一个随机生成的后缀（比如status#1、status#2…status#10）组合作为分区键。

• 逻辑：把原本集中在两个分区的数据分散到多个分区（比如10个），彻底规避热点；查询时，用Query操作配合begins_with条件，遍历所有带对应status前缀的分区键，就能获取该状态下的全部数据。
• 优势：既保留了直接按status查询的便捷性，又分散了数据和请求压力，平衡了性能与成本。

低基数二级索引的影响 #

• 热点风险：和低基数分区键的主表一样，GSI的数据会集中在少数分区，当查询/写入请求集中时，这些分区容易达到吞吐量上限，触发限流。
• 额外成本：写入主表时必须同步写入GSI，增加了写入开销；GSI会复制主表中被投影的属性，额外占用存储资源。
• 查询效率波动：如果某一status对应的数据量极大，查询GSI时仍可能因为单分区压力过高，导致响应变慢。

已考虑方案的补充说明 #

• Scan操作：完全不推荐，它会遍历全表，数据量越大效率越低，且消耗的吞吐量极高，根本无法满足大量查询的需求。
• 低基数分区键：如果数据量极小（比如几万条以内）、请求量很低，短期可以用，但数据量或请求量上来后必然会遇到热点问题，不适合长期场景。

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