DynamoDB PartiQL双键IN与单键IN查询的RCU计算方式咨询

使用场景 #

需从DynamoDB中检索多组PartitionKey（PK）+SortKey（SK）组合的数据，因此在PartiQL中同时对PK和SK使用IN运算符。

POC测试结果 #

• 模式1：执行查询

  SELECT * from "test" where pk IN ['12185','05405','14222'] and sk IN ['CELL_ID:101','CAM_ID:12185','CAM_ID:05405','CAM_ID:14222','CAM_ID:14223'];
  

  消耗RCU为5，返回4条数据。
• 模式2：执行查询

  SELECT * from "test" where pk IN ['12185','05405','14222'];
  

  消耗RCU为1.5，返回30条数据。

RCU计算逻辑解析 #

模式2（仅PK使用IN）的RCU计算 #

这种PartiQL查询等价于对每个PK值单独发起Query请求，再合并结果。RCU核心计算规则基于扫描的数据总大小（而非返回的数据量），同时受读取模式影响：

• 最终一致读取（DynamoDB默认）：每8KB数据消耗1 RCU；强一致读取：每4KB数据消耗1 RCU。
• 测试中消耗1.5 RCU，对应最终一致读取模式下，3个PK下所有数据的总大小为12KB（12÷8=1.5），与结果完全匹配。

模式1（PK+SK同时使用IN）的RCU计算 #

这种查询会被DynamoDB解析为遍历所有PK与SK的组合，对每组(PK, SK)发起GetItem请求（因为这是对组合主键的精确匹配），无论该组合是否存在对应数据：

• 查询共生成3×5=15组主键组合，每个GetItem请求（无论命中与否）都会消耗RCU：
  • 强一致读取：每个请求消耗1 RCU（≤4KB的项或不存在的项）；
  • 最终一致读取：每个请求消耗0.5 RCU（≤4KB的项或不存在的项）。
• 测试中消耗5 RCU，说明实际执行时存在部分优化（比如同一分区内的批量请求合并），但核心逻辑是按主键组合的数量计算RCU，而非扫描的数据大小，这也是其RCU远高于模式2的原因。

查询优化建议 #

从RCU消耗来看，双键使用IN的方案性价比极低。建议采用仅在PK上使用IN执行Query，拿到对应PK下的所有数据后在应用侧过滤SK的方案：

• 这种方式的RCU仅取决于PK下的总数据大小，和模式2一致，能大幅降低成本；
• 虽然会多返回一些数据，但应用侧的内存过滤开销远低于额外消耗的RCU成本，尤其当需要匹配的SK占PK下总SK比例较低时，优化效果更明显。

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