DynamoDB按分类查询门店场景：GSI与同表冗余存储方案对比选型咨询

核心差异梳理 #

你之前的理解基本准确，二者核心确实是索引存储的载体不同，除此之外在运维逻辑、一致性保障、成本结构上还有不少隐形差异：

成本维度对比 #

• 存储成本：二者定价水平一致（DynamoDB主表和GSI的存储单价完全相同），但同数据量下方案2的存储占用略高：方案2每条分类关联条目需要完整存储主表主键属性，而KEYS_ONLY投影的GSI会自动做存储优化，冗余字段更少。
• 写入成本：常规新增/删除门店场景下二者成本持平，都是单条门店写入对应1次额外写入（GSI自动同步/方案2手动写入分类关联条目）。但如果遇到门店更新分类的场景，方案2需要额外执行「删除旧分类关联条目+写入新分类关联条目」两次操作，WCU消耗是GSI自动同步的2倍，还需要自行处理写入失败导致的脏数据问题。
• 读取成本：二者几乎一致，第一步查询分类下的门店ID、第二步批量查询主表完整信息的RCU消耗没有区别。

收益维度对比 #

• 运维成本：GSI方案优势极大，所有数据同步逻辑由DynamoDB官方托管，门店新增、修改分类、删除时都会自动更新GSI条目，不会出现脏数据。方案2需要自行在业务代码中实现全生命周期的关联数据同步，只要有一处逻辑漏写就会出现「分类下查到已删除门店」「门店分类更新后旧分类还能查到」等问题，运维负担极高。
• 功能扩展性：GSI方案后续迭代更灵活，如果需要按门店评分、创建时间排序，直接将对应字段设为GSI的排序键即可，查询时直接返回有序结果；如果不需要二次查询主表，直接将GSI投影规则改成ALL，一次查询就能拿到完整门店信息，性能提升明显。方案2要实现同类能力需要自行维护所有冗余字段的同步，复杂度极高。
• 一致性支持：仅在你需要强一致查询分类下的门店列表时，方案2有唯一优势：GSI不支持强一致性读，而方案2查询主表的分类关联条目可以开启强一致读。

选型建议 #

绝大多数场景下方案1（GSI方案）更优，只有当你的业务有强一致的分类列表查询需求时，才需要考虑方案2。
额外优化建议：如果单个分类下的门店总数据量不超过10GB（DynamoDB单个分区键的存储上限），可以直接将GSI的投影规则设为ALL，不需要二次查询主表，查询性能和成本都会更优。

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