DynamoDB中PartiQL的SELECT ... WHERE PrimaryKey IN语句底层实现与性能疑问

问题背景 #

当使用PartiQL执行如下针对主键的IN查询时：

SELECT * FROM Table WHERE PK IN [1, 2, 3]

已知DynamoDB原生Query API的键条件表达式仅支持=操作，不支持IN，想明确该PartiQL语句的底层实现逻辑、触发的请求次数，以及性能表现。

底层实现逻辑 #

1. 不会通过Filter Expression实现：Filter Expression是在Query/扫描操作返回结果后再做过滤，会浪费大量读容量单位（RCU），且无法高效定位主键对应的项，因此PartiQL不会采用这种方式。
2. 拆解为多个独立的Query请求：由于原生Query API仅支持单个分区键值的查询，PartiQL会将PK IN [1,2,3]拆解为3次独立的Query请求（每个PK值对应一次Query），然后将所有请求的结果聚合后返回给调用方。
   • 如果查询的是包含排序键的完整主键（如PK IN [(1, 'SK1'), (2, 'SK2')]），则底层会转化为BatchGetItem请求，一次性获取多个主键对应的项，而非多次Query。

性能表现 #

• 延迟：总延迟取决于单个Query的延迟以及请求的并行度。PartiQL通常会并行执行这些Query请求，因此总延迟会接近单个Query的延迟，而非串行执行的3倍延迟。
• 吞吐量消耗：每个Query请求会根据返回项的大小消耗对应的RCU，总RCU消耗为各次Query的RCU之和。例如，若每个Query返回1个4KB的项，总消耗为3个RCU（假设使用强一致性读）。
• 请求限制：如果IN子句中的主键值数量过多，可能会触发DynamoDB的请求限流，需要注意控制单次IN查询的主键值数量（建议不超过100个，对应BatchGetItem的上限）。

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