审批流程验证有效后，如何高效向DDB表接入新数据版本？

现有方案的核心问题 #

当前方案中，主表存储所有历史版本记录，读取时需先查询活跃版本表获取所有审批过的版本，再从主表筛选对应记录，随着版本增多，读取和后续清理的扫描成本都会显著上升。以下是针对性优化方案和替代方案：

优化现有方案的方法 #

1. 简化活跃版本表，只保留当前生效版本 #

• 将活跃版本表的结构调整为使用固定主键（如PK = "ACTIVE_VERSION"），仅存储当前已审批通过的版本ID和审批时间戳。每次新版本审批通过后，直接覆盖该条记录（PutItem操作，成本极低）。
• 读取流程：先通过GetItem获取当前活跃版本ID，再在主表中用primary_key + version做精准查询，或基于(primary_key, version)创建全局二级索引（GSI），批量查询某主键下的最新版本记录。
• 额外优势：若需回滚，可新增一个version_history表存储所有审批过的版本信息，仅在回滚时查询，不影响日常读取性能。

2. 主表新增活跃状态标记，直接过滤读取 #

• 在主表中添加is_active布尔字段，默认值为false。
• 新版本审批通过后，执行两步操作：
  • 将该版本下所有记录的is_active更新为true（可通过BatchWriteItem或DDB Streams异步批量处理）；
  • 将上一个活跃版本的所有记录is_active设为false。
• 读取时直接查询is_active = true的记录，无需关联版本表，属于精准条件查询，成本远低于多版本筛选。

全新替代方案 #

1. 版本化分表策略 #

• 为每个数据版本创建独立的DDB表，表名包含版本标识（如user_scores_v20240520）。
• 维护一个active_table表，仅存储当前生效的表名。审批通过后，更新该表的记录指向新版本表。
• 读取流程：先获取当前活跃表名，直接查询对应表，完全无需处理版本过滤逻辑，读取成本与单表查询一致。
• 测试优势：对照组直接查询旧版本表，实验组查询新版本表，逻辑清晰，无需额外数据过滤。
• 生命周期管理：历史版本表可定期通过DDB导出功能归档到S3，无需全表扫描清理。

2. 利用DDB时间旅行（PITR）替代版本字段 #

• 启用DDB的点-in-time恢复（PITR），无需在主表中存储version字段。
• 每次发布新版本后，记录版本ID与对应的时间戳到一个version_timestamps表中。
• 审批通过后，将当前版本的时间戳标记为活跃时间戳。读取时，通过PITR查询该时间点的表数据即可获取当前生效版本。
• 优势：无需维护版本字段和多版本记录，清理成本为0（DDB自动管理PITR保留期）；测试时对照组可直接查询审批前的时间点数据。

3. 主表使用复合主键+版本排序 #

• 将主表的主键调整为复合结构：partition_key = primary_key，sort_key = version（版本ID按递增顺序生成）。
• 活跃版本表仍保留当前生效版本ID，读取时针对每个primary_key，执行Query操作并设置Limit=1、ScanIndexForward=false，直接获取该主键下的最新版本记录（即当前活跃版本）。
• 优势：无需批量更新，仅通过排序键即可快速定位最新版本，查询成本远低于全表扫描。

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