amazon-web-services - Amazon Redshift Equality 过滤器性能和排序键

Question

Redshift 是否有效地(即二分搜索)找到在 A 列上排序的表块，用于条件 A= 的查询？

举个例子，假设有一个表 T 有 ~500m 行，~50 个字段，分布和排序在字段 A 上。字段 A 具有高基数 - 所以有 ~4.5 m 不同的 A 值，其中的行数完全相同T:每个值约 100 行。
假设一个具有单个 XL 节点的 redshift 集群。
字段 A 未压缩。正如 ANALYZE COMPRESSION 所建议的那样，所有其他字段都有某种形式压缩。与未压缩的表相比，给出了 1:20 的比率。

给定一个简单的查询:

select avg(B),avg(C) from
(select B,C from T where A = <val>)

在 VACUUM 和 ANALYZE 之后给出以下解释计划:

XN Aggregate (cost=1.73..1.73 rows=1 width=8)
-> XN Seq Scan on T (cost=0.00..1.23 rows=99 width=8)
Filter: (A = <val>::numeric)

此查询需要 39 秒才能完成。
主要问题是: 这是 Redshift 的预期行为吗？

根据文档 Choosing the best sortkey :
“如果您对一列进行频繁的范围过滤或相等过滤，请将该列指定为排序键。Redshift 可以跳过读取该列的整个数据块，因为它会跟踪存储在每个块上的最小和最大列值，并且可以跳过不适用于谓词范围的块。”

在 Choosing sort keys :
“另一个依赖于排序数据的优化是有效处理范围受限谓词。Amazon Redshift 将列数据存储在 1 MB 磁盘块中。每个块的最小值和最大值都存储为元数据的一部分。如果范围受限column 是排序键，查询处理器能够在扫描表期间使用最小值和最大值快速跳过大量块。例如，如果一个表存储了按日期排序的五年数据，并且查询指定了一个日期一个月的范围内，多达98%的磁盘块可以从扫描中消除。如果数据没有排序，则必须扫描更多的磁盘块(可能是全部)。有关这些优化的更多信息，请参阅选择分发 key 。”

次要问题:
上述对排序键的跳过扫描的复杂性是多少？它是线性的( O(n) )还是二进制搜索的某种变体( O(logn) )？
如果键已排序 - 是否正在跳过唯一可用的优化？
这个“跳过”优化在解释计划中会是什么样子？
以上解释是此查询的最佳解释吗？
在这种情况下，预计 Redshift 最快的结果是什么？
在这个用例中，vanilla ParAccel 有不同的行为吗？

Answer 1

这个问题是在亚马逊论坛上回答的:https://forums.aws.amazon.com/thread.jspa?threadID=137610