如何基于country_grouping查询指定日期范围的DynamoDB销售数据？

针对业务场景的核心需求，结合现有方案的痛点，推荐以下更平衡的实现方式：

核心思路 #

利用低更新频率的国家-分组映射特性，结合DynamoDB的批量查询能力，既避免写入阶段的额外资源消耗，又减少查询阶段的请求次数。

1. 优化国家-分组映射的查询效率 #

因为国家与分组的映射更新频率低，你可以：

• 在参考实体表上创建一个GSI，分区键设为country_grouping，排序键设为country
• 或者单独创建一个小型表专门存储分组-国家映射，结构为PK: country_grouping, SK: country
  这样查询指定分组下的所有国家只需要1次Query操作，高效获取完整的国家列表。

2. 用BatchGetItem批量查询销售数据 #

针对销售数据，保留以country为分区键、order_date为排序键的GSI。拿到分组对应的国家列表后，使用DynamoDB的BatchGetItem接口批量发起查询：

• 一次BatchGetItem最多可以请求100个不同分区键（即不同country）的数据
• 每个请求可以指定order_date的范围条件，直接过滤出目标日期内的销售记录
  这种方式把方案2的N次独立请求合并为1次或少量几次请求，大幅降低网络延迟和请求开销。

3. 分组映射变更的低成本处理 #

如果分组映射需要调整，不需要批量更新历史销售数据：

• 维护一个缓存（如Redis）存储最新的分组-国家映射，利用低更新频率的特性保证高命中率
• 查询时先从缓存获取当前分组对应的国家列表，再执行批量查询
• 若需要支持旧分组的历史查询，可以保留方案1的GSI作为兼容入口，新数据不再写入该GSI，或者通过Lambda+DynamoDB Streams异步增量更新历史数据（仅处理需要变更的分组数据）

4. 大量国家分组的场景优化 #

如果某个分组包含超过100个国家，将国家列表拆分多个批次，并行发起BatchGetItem请求，利用DynamoDB的并行查询能力缩短总查询时间。

方案优势对比 #

• 对比方案1：无需在写入销售数据时额外消耗RCU/WCU，分组变更时也不用批量更新全量历史数据，降低长期运维成本
• 对比方案2：请求次数从N次减少到ceil(N/100)次，大幅降低查询延迟和API调用开销

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