如何实现DynamoDB批量更新以避免删表重建导致的API访问中断？

针对你的场景（每日从Redshift同步数据到DynamoDB，需保证API访问可用性），以下是几个替代删表重建的可行方案：

一、双表蓝绿切换（核心解决可用性问题） #

这是最稳妥的全量同步方案，彻底避免表不可用的风险：

• 维护两张结构完全一致的DynamoDB表，比如prod_data（对外服务的主表）和prod_data_staging（同步用临时表）
• 每日ETL流程：
  1. 清空prod_data_staging（数据量大时，直接创建新临时表比清空更高效）
  2. 将Redshift全量数据通过BatchWriteItem批量写入prod_data_staging——主键ID+version会自动覆盖旧条目，新增条目直接插入
  3. 待prod_data_staging同步完成且状态为ACTIVE后，原子切换API的表指向：
     • 若API基于Lambda/应用服务，修改环境变量或配置中心的表名参数即可切换
     • 若用API Gateway，可在集成请求中动态指定表名，通过配置完成切换
  4. 等待1~2小时（确保所有旧请求处理完成），删除原prod_data表，将prod_data_staging重命名为prod_data（或下次ETL复用另一张临时表）

二、增量同步+批量写入（减少资源消耗，提升效率） #

如果Redshift的数据可区分增量（比如基于timestamp字段筛选当日更新/新增数据），无需全量同步：

• 每日从Redshift提取仅变更的数据（新增的ID+version、或score/timestamp更新的条目）
• 用BatchWriteItem批量执行PutItem操作：
  • 由于主键是ID+version，DynamoDB中已存在的相同主键条目会被直接覆盖为最新数据
  • 新条目则直接插入
• 该方案无需操作主表，完全不影响API可用性，同步耗时、资源消耗远低于全量同步

三、批量写入的关键注意事项 #

无论采用哪种方案，使用BatchWriteItem时需遵守以下规则：

• 单次请求最多包含25个PutItem/DeleteItem操作
• 单次请求总数据大小不超过16MB
• 需处理返回的UnprocessedItems：当请求超出DynamoDB吞吐量限制时，部分操作会返回未处理项，需采用指数退避策略重试
• 若表开启自动扩容，可提前调整读写吞吐量，避免同步时出现限流

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