Redshift 表适用于我的表的分配键和排序键答案

【问题标题】：Redshift table appropiate distribution key and sort key for my tableRedshift 表适用于我的表的分配键和排序键
【发布时间】：2021-05-21 17:21:32
【问题描述】：

我有一个表，其中列像 record_id、creation_date、active_time、inactive_time 和更多数据列。截至目前，表中有大约 12M 条记录。表中不同的'record_id'（varchar（6））值计数为：8M（此列上的数据分布均匀）表中不同的“creation_date”（日期）值计数为：800（此列上的数据分布均匀）集群详细信息 - 总切片为 16。

如果我说这个表与其他表的连接，它主要是基于列'record_id'和'creation_date'。并且有一段时间 active_time 和 inactive_time 也参与加入。

问题是：-

我应该将什么作为该表的 distribution_key、record_id 或 creation_Date ？
我应该使用什么排序键？正如我上面所说的 active_time 和 inactive_time 也参与了一段时间的连接，所以我应该将这 2 列包含在排序键中吗？

【问题讨论】：

标签： amazon-web-services amazon-redshift

【解决方案1】：

Amazon Redshift 的一般规则是：

将DISTKEY设置为JOIN中最常用的列
将SORTKEY设置为WHERE中最常用的列

1200 万行的表对于 Redshift 来说不是很大。即使你弄错了，它也会运行得很好。

我会推荐 record_id 的 DISTKEY（因为它似乎经常被加入）。

将 SORTKEY 设置为您通常用来限制结果的值。它只能是一列。 Redshift 将按照给定列的顺序存储行，并且会记住每个 1MB 存储块中该列的最小值和最大值。这允许它“跳过”不包含该值的块。这使得查询运行得很快，因为它可以避免磁盘访问，这是所有数据库中最慢的部分。

见：Amazon Redshift best practices for designing tables - Amazon Redshift

【讨论】：

感谢约翰的宝贵意见。我也同意 12M 的记录对于 redshift 来说并不多，即使我们选择任何键，它也会很快工作，让我们暂时忘记这件事。
这里 'record_id' 和 'creation_date' 列在 join 中具有同等重要性。如果我谈论单个record_id的平均记录数小于
示例查询如下。 select a.*,b.* from table_A a join table_B b on a.record_id = b.record_id and a.creation_date = b.creation_date and a.creation date >= current_date -1;
Redshift 集群中有多少节点和切片？（请参阅Data warehouse system architecture - Amazon Redshift） DISTKEY 用于跨切片分发数据。如果您没有很多切片，则 DISTKEY 无关紧要，因为更多数据已经位于同一切片上。在您的情况下，我建议只选择其中一个作为 DISTKEY，但您可以随意测试每一个，看看哪一个效果最好。测试时，由于缓存，运行两次查询。
根据您的示例查询，我建议使用 record_id 的 DISTKEY 和 creation_date 的 SORTKEY（因为它的使用更像是 WHERE 而不是 JOIN）。它匹配多个创建日期，因此不适合 DISTKEY。