DynamoDB带过滤的Scan与Redshift查询操作的差异探究

过滤时机与资源消耗的本质区别 #

DynamoDB的Scan操作逻辑是先全量读取表内所有数据（消耗对应规模的读容量），之后才应用过滤表达式筛选结果，所以无论是否添加过滤条件，读容量的消耗完全一致。而Redshift这类SQL数据仓库的处理逻辑截然不同：

• Redshift的过滤是前置执行：当你编写带WHERE子句的查询时，Redshift的查询优化器会生成最优执行计划，在数据读取阶段就应用过滤条件——只读取符合条件的数据块，而非全量扫描整张表。这意味着过滤条件直接决定了需要处理的数据量，进而降低CPU、IO等计算资源的消耗，同时缩短查询耗时。
• 资源消耗与过滤效率强相关：如果过滤条件能匹配Redshift的排序键（SORT KEY）、分布键（DIST KEY），或者利用物化视图、索引等优化手段，查询效率会大幅提升，资源消耗进一步降低。即使触发全表扫描，Redshift的资源消耗也是基于实际处理的数据量，而非像DynamoDB那样固定消耗全表读容量。

其他SQL数据仓库的共性逻辑 #

BigQuery、Snowflake等云原生SQL数据仓库的处理逻辑和Redshift一致：查询优化器会尽可能在数据处理的早期阶段应用过滤条件，最小化需要处理的数据量，资源消耗随过滤后的数据量减少而降低，不会出现DynamoDB Scan那种「全量读取+后置过滤」导致的固定资源消耗情况。

底层设计原因 #

DynamoDB作为键值型NoSQL数据库，没有SQL数据仓库的查询优化器和列式存储、数据分区等架构优化，Scan本质就是全表遍历操作，过滤只是结果返回前的最后一步数据筛选，因此读容量不受过滤条件影响。而SQL数据仓库的核心目标是高效处理分析型查询，所以会通过各类优化手段减少不必要的数据处理。

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