DynamoDB按最后修改时间查询的表结构与GSI设计咨询

针对现有需求的具体方案 #

1. 按ID查询接口 #

你的主表已经将分区键设为整数类型ID，这完全满足按ID查询的需求——直接使用GetItem API即可，这是DynamoDB中效率最高的单条数据查询方式，无需额外设置排序键为ID。如果需要批量查询多个ID，可以用BatchGetItem，同样高效。

2. 全表查询接口 #

既然是硬性需求，只能使用Scan操作，但可以做以下优化降低影响：

• 采用分段扫描：通过设置Limit参数控制单次返回的数据量，配合ExclusiveStartKey实现分页查询，避免单次扫描占用过多资源。
• 开启并行扫描：将表分成多个段同时扫描，提升大表的扫描速度，但注意控制并发度避免影响主表的正常读写。
• 尽量减少全表扫描的调用频率，日常查询优先用后面的时间范围查询接口替代。

3. lastModified大于昨日数据的查询接口 #

你提出的GSI设计思路是可行的，且能有效降低查询成本，具体优化如下：
创建一个全局二级索引（GSI）：

• 分区键设为lastModifiedDay：格式用YYYYMMDD的整数或字符串，将数据按日期分组，分散查询负载。
• 排序键设为lastModifiedTs：精确到秒或毫秒的Unix时间戳，用于在日期分区内做时间范围过滤。

查询逻辑示例：
假设昨日的日期是20240520，昨日0点的时间戳是1716153600，那么：

• 查询lastModifiedDay > 20240520的所有分区，直接获取今日及以后的所有数据。
• 再单独查询lastModifiedDay = 20240520且lastModifiedTs > 1716153600的数据（如果需求是“大于昨日0点”而非“大于昨日结束时间”）。
  将两部分结果合并即可，全程用Query操作，避免全表扫描。

如果数据量不大，也可以考虑将GSI分区键设为固定值（比如"TIME_GROUP"），排序键用lastModifiedTs，直接查询partitionKey = "TIME_GROUP" AND lastModifiedTs > 昨日时间戳，但这种方式在数据量较大时会出现分区热点，不推荐用于大规模数据集。

总结 #

• 主表保持分区键为整数ID，无需设置排序键为ID，按ID查询用GetItem/BatchGetItem即可。
• 全表扫描用分段/并行扫描优化，尽量降低调用频率。
• 用日期分区+时间戳排序键的GSI满足时间范围查询需求，彻底替代大部分全表扫描场景。

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