存储标准化消费收据的可靠DynamoDB访问模式设计咨询

你设计的这种单表多实体建模思路完全符合DynamoDB的核心设计最佳实践，搭配合理的GSI可以100%覆盖你当前提出的所有查询需求，具体分析如下：

现有设计可直接支撑的需求实现方案 #

• 商品价格历史追踪：直接查询主表即可，将分区键（pk）设为对应商品名称，排序键（sk）加时间范围过滤条件，就能拉取该商品所有时间点的售价记录，完全满足需求。
• 单商品指定时间范围消费汇总：同样用主表查询，分区键固定为目标商品名，排序键限定你需要的时间区间，将返回结果中的total $字段累加即可。如果数据量很大，还可以开启DynamoDB Streams做预聚合，把日/周/月维度的商品消费汇总结果存为单独的实体，查询延迟会更低。
• 指定时间范围总体消费汇总：针对你存储的receipt实体新增一个GSI即可，把该GSI的分区键设为固定值比如"ALL_RECEIPTS"，排序键复用原表的时间戳，查询时直接筛选该GSI的排序键时间范围，累加返回结果的receipt total字段就能得到对应周期的总消费额。
• 按总金额排序收据：还是复用上面的receipt GSI，把GSI的排序键改为receipt total字段即可；如果需要同时支持按时间筛选+按金额排序，也可以把GSI的排序键设为"时间戳#总金额"的复合字段，两个需求可以同时满足。

优化建议（方便后续扩展新需求） #

1. 你当前的排序键只用了收据生成时间，同一时间点如果有多条收据会出现主键冲突，建议把排序键改为"时间戳#收据唯一ID"的格式，既保留了按时间排序/过滤的能力，也能避免主键冲突。
2. 商品实体可以冗余存储对应收据的唯一ID，后续如果需要查某个商品关联的所有收据，直接就能定位到对应收据实体，不需要扫描receipt实体的items数组，查询效率更高。
3. 后续如果需要按消费品类、支付方式这类新维度查询，直接新增对应GSI即可，不需要修改主表结构，灵活性足够。

只要你后续的新查询需求都能明确固定的分区键筛选条件，这个设计基本都能覆盖。如果后续需要非常灵活的多维度自由分析，建议把DynamoDB的数据流同步到数仓处理即可，刚好可以补足DynamoDB在OLAP场景的能力短板。

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