合规需求下DynamoDB大表按邮箱过滤的最优可扩展方案问询

现有方案的局限性 #

全表导出到S3处理 #

• 问题：每次操作都要导出百万级数据，随着表规模增长，存储、导出时间和处理成本会线性上升；实时性差，无法快速得到结果；重复操作的冗余成本极高，完全不符合定期执行的需求。

逐个调用DynamoDB Query #

• 问题：当前1300个邮箱就要发起1300次独立请求，未来邮箱数量增长后，请求数成比例增加，容易触发DynamoDB的并发限流；串行处理耗时久，并行处理若不控制并发，会导致Provisioned Throughput耗尽或On-Demand成本飙升。

推荐方案：批量异步查询+流程编排 #

核心思路 #

利用DynamoDB GSI的Query高效性，结合Step Functions或Lambda做并发批量查询，控制请求频率和并发数，同时自动化整个流程以降低重复操作成本。

具体步骤 #

1. 预处理邮箱列表

   • 先对输入的邮箱列表去重，避免无效查询，减少请求数。

2. 批量并行查询

   • 将邮箱列表分成若干批次（比如每批次30-50个，具体根据DynamoDB表的读写容量调整）。
   • 用Step Functions创建并行分支，每个分支调用一个Lambda函数，执行单个邮箱的DynamoDB Query（基于邮箱GSI，KeyConditionExpression: "email = :val"）。
   • 或者用Lambda的异步调用+SQS做任务队列，控制并发数：将每个邮箱查询任务放入SQS队列，设置Lambda的并发执行数，实现平稳的批量查询。

3. 结果聚合与输出

   • 每个查询任务完成后，将结果写入S3的指定前缀（比如按日期/批次命名文件）。
   • 所有查询完成后，触发一个汇总Lambda，将S3中的所有结果文件合并成合规部门需要的格式（比如CSV、JSON数组），或者直接同步到指定系统。

4. 自动化调度

   • 用CloudWatch Events设置定时规则（比如每周一凌晨），自动触发Step Functions或Lambda任务，实现零手动干预的定期执行。

扩展优化点 #

• 反向索引表（长期高频场景）：如果未来邮箱查询频率极高且数量持续增长，可以创建一个反向DynamoDB表，以邮箱为分区键，存储原表的主键ID。每次原表数据变更时，用Lambda同步更新反向表。查询时先批量查询反向表得到主键列表，再用BatchGetItem从原表批量获取数据，进一步降低请求数和延迟。
• 成本控制：使用DynamoDB On-Demand模式自动应对突发请求，或者在查询时段临时调整Provisioned Throughput，事后恢复，平衡成本和性能。

方案对比 #

内容的提问来源于stack exchange，提问作者Farhad-Taran