DynamoDB无分区键查询：如何高效按timestamp范围检索数据

针对你的需求，可根据业务场景选择以下成熟的高效方案，完全规避全表Scan的性能问题，也不会出现单分区热点缺陷：

• 时间分片GSI方案（最通用）
  不再使用统一值的虚拟分区键，而是将timestamp按固定时间粒度（如天、周、月，可根据你常用的查询跨度调整）截断后的值作为全局二级索引的分区键，原始timestamp作为索引的排序键。
  例：你需要查询2024-05-01到2024-05-05的记录时，只需分别对2024-05-01、2024-05-02...2024-05-05这几个分区键发起Query请求，对每个分区键下的排序键做范围过滤，最后合并所有返回结果即可。
  该方案完全符合DynamoDB设计规范，不同时间分片的数据分散在不同分区，不会出现写入/读取热点，查询效率为Query级别，远高于Scan操作。
• 带时间前缀的ID方案（适合新表设计）
  如果你还未上线表结构，可将原有唯一ID替换为ULID、KSUID这类自带时间前缀的有序ID，直接将该ID作为表的排序键（或主键）。此时你无需额外建GSI，直接根据ID的前缀范围即可匹配到对应时间区间的记录，进一步节省索引存储成本。
• 分片增强方案（适合超高写入量场景）
  如果单时间分片的写入量超过DynamoDB单分区上限（1000写容量单位/秒），可以在时间分片的基础上再加1~N的随机后缀作为分区键，写入时随机选择后缀值，查询时遍历同一时间分片下的所有后缀分区再合并结果即可，可进一步分散负载，支撑超大规模写入。

不推荐使用全同值虚拟分区键的原因：所有索引数据会集中在同一个DynamoDB分区，最高只能支撑1000写/3000读容量单位，海量数据场景下极易触发限流，完全无法落地生产。
不推荐使用Scan的原因：Scan为全表扫描逻辑，哪怕加了时间过滤条件也会先扫描全表再过滤结果，海量数据下不仅延迟极高，还会消耗大量读容量，成本和性能都不符合要求。

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