如何快速将AWS DynamoDB海量数据迁移至S3与RDS MySQL架构

原有PHP迁移方案性能瓶颈核心原因 #

• 单/少进程串行执行，未利用DynamoDB原生并行扫描能力，资源利用率极低
• 单条数据依次执行「读DynamoDB->写MySQL->传S3->删DynamoDB」操作，IO等待时间占比超过90%
• 无批量优化逻辑，频繁小请求大幅浪费网络与数据库事务开销

可落地的高性能迁移方案 #

1. 工具选型优化 #

直接放弃同步PHP脚本，选择适配高并发IO场景的实现方式：

• 优先选择AWS原生批量处理组件：Data Pipeline + EMR Serverless，原生支持DynamoDB全表自动分片并行扫描，无需手动处理主键分段逻辑
• 轻量自研方案可以选择Go/Python异步多协程实现，单实例就能支撑上千并发请求，性能是PHP同步脚本的10~20倍

2. 流程拆分与并行优化 #

将单条串行流程改为批量并行流水线，大幅降低无效等待：

• 第一步：对DynamoDB表做分段并行扫描，按主键范围拆分为100~200个独立分片，每个分片分配独立工作协程/进程处理，打满DynamoDB预置的读吞吐量
• 第二步：每个分片内做批量攒批处理，每凑够100~500条数据就批量执行：
  • 批量提取元数据字段，拼接为INSERT ... ON DUPLICATE KEY UPDATE语句批量写入MySQL，省略单条插入的重复事务开销
  • 批量上传邮件正文到S3，小文件可以先凑成10MB左右的批次合并传输，再按指定路径/YYYY-MM/YYYY-MM-DD/<邮件唯一ID>生成独立对象
  • 确认前两步全部执行成功后，批量删除DynamoDB对应条目，单批次删除请求最多支持25条，可按实际网络情况调整批次大小

3. 容错与一致性保障 #

• 迁移前先给DynamoDB表开启时间点恢复(PITR)，避免误操作导致数据丢失
• 每个分片的处理进度存入独立checkpoint表（可放在MySQL或Redis中），记录已处理完成的主键范围，进程异常中断后重启直接从断点继续执行，无需重扫全表
• 全量迁移完成后执行一致性校验：分别统计DynamoDB剩余条目数、MySQL新增邮件记录数、S3对应路径下的对象数，三者数值完全一致后再执行残余数据清理

4. 性能参考 #

在DynamoDB读吞吐量配置为5000 RCU、MySQL RDS规格为8C16G、S3传输带宽无瓶颈的情况下，2100万条数据预计1~3天即可完成全量迁移。

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