DynamoDB实现列索引范围查询的常用最优方案是什么

DynamoDB 从设计上要求所有范围查询（主键、本地二级索引、全局二级索引）必须指定分区键，不存在单列范围查询的原生支持，类似按分数取Top N、按排名区间查询这类需求需要通过业务层适配实现，主流方案及适用场景如下：

已知可选方案的适用场景评估 #

• 直接使用Scan全表扫描实现
  仅适合表总数据量小于1万条、查询频率极低的非核心场景。Scan会遍历全表数据，消耗大量读容量，查询延迟随数据量增长线性上升，生产环境核心场景不推荐使用该方案。
• 设置静态统一分区键，基于分区Query实现
  适合数据量较小、写入QPS低于1000的场景。可以将全局二级索引的分区键设为固定值（比如固定为字符串score_rank），排序键设为分数属性，查询时直接指定该固定分区键，即可直接拉取排序后的Top N或者区间数据。该方案实现成本极低，缺点是单个DynamoDB分区上限为10GB、写入吞吐量上限为1000 WCU，数据规模或写入量超过阈值会出现热分区问题，无法支撑大规模业务。
• 设置固定数量的静态分片分区键，多Query结果合并
  适合中等规模数据、写入QPS较高的场景。提前将数据打散到N个固定分片，写入时将分数取模或者随机分配到shard_0到shard_N-1的分区中，查询时同时请求所有分片的对应范围数据，在服务侧合并后得到全局排序结果。该方案解决了热分区问题，成本可控，缺点是跨区间分页查询的实现复杂度较高，需要额外维护分页位点。

生产级高优补充方案 #

除上述方向外，中大规模业务还有两类更通用的落地方案：

• 写时预计算排行结果，单独存储
  适合排行榜查询频率极高、可接受秒级到分钟级更新延迟的场景。新分数数据写入后，通过异步任务预计算全量或分位排行榜，将排行结果直接存储在单独的DynamoDB表或者Redis缓存中，查询时直接读取预计算结果即可，查询延迟极低，是游戏高分榜、商品销量榜这类场景的首选方案。
• 异构存储对接检索引擎
  适合数据规模大、查询灵活度要求高的场景。通过DynamoDB Streams将数据实时同步到OpenSearch、Elasticsearch这类检索引擎，所有范围排序、多条件过滤类查询直接走检索引擎，DynamoDB仅作为主键查询的底层可信存储，该方案灵活性最高，可支持各类复杂查询需求，是当前中大规模互联网业务的主流落地方式。

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