DynamoDB临时存储变更追踪数据：两种方案选优咨询

方案一：单记录嵌套变更数组 #

• 优势：写入操作成本低，每次变更仅需更新单条记录的changes数组与lastTimestamp字段，节省写入吞吐量（WCU）；对于变更频率低的实体，单条记录存储更紧凑。
• 劣势：无法高效按变更时间戳筛选——changes是嵌套JSON数组，DynamoDB无法为数组内的timestamp字段建立索引，查询特定时间范围的变更时，必须先拉取整条记录再在客户端解析过滤，数据量大时性能极差；此外，单条记录最大限制为400KB，若实体变更频繁，数组会很快触及上限，导致无法继续追加。

方案二：单变更单记录 #

• 优势：完美解决时间戳筛选需求——可将recordId设为分区键，timestamp设为排序键，或创建以timestamp为排序键的全局二级索引（GSI），实现毫秒级的时间范围查询；每条记录独立设置TTL，到期自动清理，无需额外维护；记录结构简单，查询后无需复杂解析，直接即可使用数据。
• 劣势：每次变更需写入一条新记录，WCU消耗高于方案一，但由于数据仅存储3个月，数据量不会无限累积，WCU的增加是可预期且可控的；单条记录存储会增加总存储空间，但TTL自动清理机制会定期释放空间，长期存储压力极低。

结论 #

结合你「需要高效按变更时间戳筛选+临时存储3个月」的核心需求，优先选择单变更单记录的方案：

1. 方案一的核心痛点（时间戳筛选低效）是业务查询的关键障碍，方案二直接从底层设计上解决了这个问题。
2. 写入量增加的成本在临时存储的场景下完全可控，且DynamoDB支持按需调整WCU，无需担心资源瓶颈。
3. 该方案更符合DynamoDB的「单条记录存储单一实体事件」的设计范式，后续扩展（比如新增查询维度）也更灵活。

如果你的业务中存在极少数变更频率极低的实体，可考虑混合方案，但会增加代码复杂度，若无明确的成本或性能压力，不建议采用。

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