Redshift：基于键的分配是否优化了相等过滤器？答案

【问题标题】：Redshift: Does key-based distribution optimize equality filters?Redshift：基于键的分配是否优化了相等过滤器？
【发布时间】：2017-11-14 14:28:28
【问题描述】：

This 文档描述了 redshift 中的密钥分布如下：

行根据一列中的值分布。这领导节点将尝试在同一节点上放置匹配的值片。如果您在连接键上分配一对表，则领导节点根据值配置切片上的行在连接列中，以便匹配来自公共列的值物理存储在一起。

我想知道键分布是否还有助于优化相等过滤器。我的直觉说应该，但没有在任何地方提及。

另外，我看到了一个关于排序键的documentation，它说要选择一个排序键：

查找在范围过滤器和平等过滤器中使用的列。

这让我感到困惑，因为明确提到排序键是一种优化相等过滤器的方法。

我问这个是因为我已经有一个候选排序键，我将在它上面进行范围查询。但我也想在另一列上使用快速相等过滤器，这在我的情况下是一个很好的分布键。

【问题讨论】：

【解决方案1】：

在分布键上进行过滤是一个非常糟糕的主意，尤其是在您的表/集群很大的情况下。

原因是过滤器可能只在一个切片上运行，实际上运行时没有 MPP 的好处。

例如，如果您的 dist 键为“ added_date”，您可能会发现上一周的所有添加日期都在一个切片上。

然后，您将有大部分查询过滤最近的 added_date 范围，这些查询将集中并饱和该切片。

【讨论】：

【解决方案2】：

简单的规则是：

对 SORTKEY 和 DISTKEY 使用相同的字段实际上是有好处的。来自Choose the Best Sort Key：

如果您经常连接表，请将连接列指定为排序键和分布键。

这使查询优化器能够选择排序合并联接而不是较慢的哈希联接。因为数据已经按连接键排序，查询优化器可以绕过排序合并连接的排序阶段。

随意进行一些性能测试——创建几个不同版本的表，并使用 INSERT 或 SELECT INTO 填充它们。然后，尝试常见查询以查看它们的执行情况。

【讨论】：

约翰，你什么时候推荐“SORTKEY 和 DISTKEY 的相同字段”
用参考更新了答案。
为什么我们也不能将 DISTKEY 用于相等过滤器？ DISTKEY 将帮助我识别数据所在的切片。这不是一个足够好的优化（即使我们不能利用 MPP）？
如果使用 WHERE 子句标识列中的单个值，并且该列是 DISTKEY，则表示只有一个切片参与查询。 Redshift 的强大之处在于并行化查询，因此最好同时使用多个切片。