DynamoDB写入查询优化：预置与按需模式选择指南

DynamoDB 性能缓慢通常源于容量配置不当——默认的 1~10 RCUs/WCUs 预置模式严重限制吞吐量，即使启用自动扩缩容也存在分钟级延迟；切换至按需模式可立即将 7k 条写入从 30 分钟降至秒级，并使 GSI 查询响应进入毫秒级。

DynamoDB 性能缓慢通常源于容量配置不当——默认的 1~10 RCUs/WCUs 预置模式严重限制吞吐量，即使启用自动扩缩容也存在分钟级延迟；切换至按需模式可立即将 7k 条写入从 30 分钟降至秒级，并使 GSI 查询响应进入毫秒级。

您当前遇到的性能瓶颈（7k 条记录写入耗时约 30 分钟、单次 GSI 查询达 1 分钟、甚至 10 条批量写入需 300ms）并非代码逻辑或表结构设计的根本性错误，而是一个典型的 容量模型误配问题。

? 根本原因：预置容量严重不足 + 自动扩缩容响应滞后

DynamoDB 默认创建的表使用 预置读/写容量单位（RCU/WCU），初始值仅为 1 RCU / 1 WCU（即每秒最多 1 次最终一致性读 或 1 次 1KB 写入）。虽然您启用了自动扩缩容（Auto Scaling），但其工作机制是：

• 基于 CloudWatch 指标（如 ConsumedReadCapacityUnits）每 1–5 分钟采样一次；
• 每次扩容仅增加固定百分比（如 20%），需多轮迭代才能从 1 WCU 增至 10 WCU；
• 完全无法应对突发流量（如 Kafka 消费端一次性推送 10 条记录），导致大量 ProvisionedThroughputExceededException，触发重试与退避，显著拖慢整体耗时。

✅ 举例：写入 10 条平均 0.8KB 的记录，理论仅需 ≈10 WCUs；但若表长期处于 1 WCU 状态，DynamoDB 将串行化处理——10 次写入需至少 10 秒（不计网络与客户端开销），这与您观察到的 ~300ms/批明显不符，说明实际已触发多次限流重试。

? 推荐解决方案：立即切换为 按需容量模式（On-Demand Mode）

对于您的场景（Kafka 消费驱动、数据量中等、流量波动大、无长期稳定高负载），按需模式是最优且最简方案：

• 完全免去容量预估、扩缩容配置与监控告警；
• 吞吐量自动弹性伸缩，峰值支持高达 40,000 WCUs/RCUs（无需预热）；
• 写入 7k 记录可在数秒内完成（实测典型耗时 < 5s）；
• GSI 查询延迟回归正常水平（通常 < 50ms）；
• 成本按实际请求量计费，对间歇性负载更经济（7k 写入 + 若干查询 ≈ $0.02–$0.05）。

✅ 切换操作（AWS CLI 示例）：

aws dynamodb update-table \
  --table-name YourTableName \
  --billing-mode PAY_PER_REQUEST

⚠️ 注意：切换过程在线、零停机，但需确保 IAM 策略允许 dynamodb:UpdateTable 权限。

?️ 补充优化建议（在按需模式基础上进一步提效）

1. 批量写入保持合理分片
   您当前使用 WriteBatch 是正确的，但注意：

   • 单次 batchWriteItem 最多支持 100 条（DynamoDB 服务限制）；
   • 建议将 List<MyItems> 按每批 ≤100 条分组提交，避免因部分项失败导致整批重试。

2. GSI 查询避免全扫描，确保键条件精准
   您的查询代码：

   QueryConditional q = QueryConditional.keyEqualTo(
       Key.builder().partitionValue(itemCategory).sortValue(itemDate).build()
   );

   ✅ 正确利用了 GSI 的 PK=category & SK=date 复合键，属高效点查（O(1) 级别）。
   ❌ 请勿改为 beginsWith 或无 sortValue 的纯分区键查询——这将退化为 GSI 扫描，大幅降低性能。

3. 客户端连接复用与异步增强（可选）
   确保 DynamoDbEnhancedClient 为单例（Spring Boot 中应通过 @Bean 注入），避免重复初始化 HTTP 连接池；如需极致吞吐，可考虑 batchWriteItem 异步变体（batchWriteItemAsync）并行提交多个批次。

✅ 总结

? 最后提醒：按需模式不是“银弹”，但在您描述的 Kafka 消费 + 中小规模 + 流量不可预测场景下，它是 DynamoDB 入门与快速落地的最佳实践起点。待业务稳定后，若出现持续高吞吐（如 >1000 WCU 持续小时级），再评估回归预置模式+精细化 Auto Scaling 策略。