Redshift：是否需要使用外键来利用分发键？

Question

在 Amazon 的指南中，他们提到为所有 table 指定 PRIMARY 和 FOREIGN KEY，然后在有意义的地方指定分布键，比如在经常用于连接 [=41= 的列上] 在一起。我知道即使使用单个 table 查询，正确的 DISTKEY 规范也有助于执行 GROUP BY，但是对于 JOINing 两个或多个 tables，是否必须将 DISTKEY 列指定为 FOREIGN KEY 作为出色地？或者 Redshift 是否会根据用作 DISTKEY 的列的数据类型（可能还有名称）将来自不同 table 的行共同定位到相同的节点？[=13=]

我问的原因是因为我并没有在我的应用程序中真正使用维度 tables。我可以简单地创建它们作为外键引用来帮助分发，但是必须维护维度 tables。

考虑以下示例，其中我有两个经常加入的 table：

CREATE TABLE motorcycles
(
  id INT,
  hexcolor CHAR(6)
);

CREATE TABLE helmets
(
  id INT,
  hexcolor CHAR(6)
);

现在假设在我的应用程序中，我们经常将 摩托车 table 加入头盔 table hexcolor 列。那么使用 DISTSTYLE KEY 和 DISTKEY (hexcolor) 就有意义了，对吧？但是，您不能真正说 motorcycles table 中的 hexcolor 列是头盔 table 反之亦然。我可以创建一个维度 table，其中包含所有可能的 hexcolor 值的列表，然后是 motorcycles 和 helmets tables 可以有这个维度的外键 table，但是必须维护这个维度 table 会很痛苦（亚马逊的指南也警告不要指定未正确维护的主键或外键，因为它会混淆查询规划器）。

那么，以我的摩托车和头盔为例，是否需要维度 table 的外键？或者 Redshift 是否会基于用作分布键的列的数据类型相同这一事实假设它应该以相同的方式为这两个 table 分布行？

Answer 1

只要列具有相同的数据类型，您应该期望 Redshift 以相同的方式分发摩托车和头盔表。

在您的案例中没有理由使用外键。查询规划器将能够利用表按相同键分布的事实。

但阅读执行计划并确保它显示 DS_DIST_NONE 总是好的 - 这意味着不需要重新分配数据。

Redshift：是否需要使用外键来利用分发键？

Redshift: Is using a foreign key necessary to take advantage of distribution keys?

amazon-redshift