特定查询场景下DynamoDB建模优化咨询及RDS适用性评估

现有方案的问题梳理 #

• 方案一：分区键设为A，排序键用D#E#B#C
  • 核心问题：整数D、E转字符串拼接时必须补前导零才能保证排序逻辑正确（比如10和2直接转字符串排序会变成10在前，和数值排序逻辑相反），而且无法直接基于时间范围筛选，必须扫描分区A下的所有数据后再过滤，性能损耗大。
• 方案二：分区键A，排序键B#C，同时给D#E建LSI
  • 核心问题：排序键B#C对目标查询毫无帮助，LSI只能基于排序键做范围查询，没法结合时间条件筛选，同样需要大量后续过滤操作，而且无法直接实现C值的去重。

优化的DynamoDB建模方案 #

方案1：GSI+投影属性组合 #

主表结构设计：

• 分区键：A
• 排序键：start_date#end_date#B#C
• 存储属性：D, E, start_date, end_date

配套创建全局二级索引(GSI)：

• GSI分区键：A
• GSI排序键：D#E#C（注意：D、E要转成固定长度的字符串，比如整数范围0-999999就补成6位，避免排序逻辑错误）
• 投影属性：start_date, end_date, C

查询步骤：

1. 针对GSI执行查询，指定分区键A='Y'，按D#E#C降序扫描
2. 扫描过程中逐条过滤出current_timestamp处于start_date和end_date之间的条目
3. 收集不重复的C值，凑够10个后立即停止扫描

注意：如果符合时间条件的数据占分区A总数据的比例较高，这个方案性能不错；如果占比极低，会浪费较多读取容量。

方案2：预聚合表（适合查询频繁、更新少的场景） #

如果该查询调用频率高，且数据更新不频繁，可以维护一张预聚合表：

• 分区键：A
• 排序键：D#E#C
• 存储属性：is_active（标记当前时间是否在start_date和end_date范围内）, start_date, end_date

可以用Lambda定时任务定期更新is_active的状态，查询时直接取A='Y'且is_active=true的条目，按D#E#C降序取前10个不重复的C值。

优势：查询时无需再做时间过滤，性能大幅提升；劣势：需要额外维护数据一致性，不适合数据频繁更新的场景。

RDS是否更适配？ #

如果你的场景符合以下情况，RDS（关系型数据库）会是更省心的选择：

• 数据量不大（单表千万级以内），常规查询性能就能满足需求
• 除了这个查询外，还有其他复杂的多条件查询、聚合查询需求
• 不想为了适配DynamoDB做额外的建模逻辑和数据一致性维护

关系型数据库的实现非常直接：

• 主键设为(A,B,C)
• 创建联合索引(A, start_date, end_date, D, E, C)
• 执行SQL：

SELECT DISTINCT TOP 10 C 
FROM table 
WHERE A = 'Y' 
  AND CURRENT_TIMESTAMP BETWEEN start_date AND end_date 
ORDER BY D DESC, E DESC;

这个查询能通过联合索引快速定位符合条件的数据，直接完成排序和去重，开发成本低，性能稳定。

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