Redshift：主表的 DIST KEY 和 SORT KEY 的适当组合是啥？

Posted 2023-02-26

【中文标题】Redshift：主表的 DIST KEY 和 SORT KEY 的适当组合是啥？

【英文标题】：Redshift : What can be appropriate combination of DIST KEY and SORT KEY for Master Tables?Redshift：主表的 DIST KEY 和 SORT KEY 的适当组合是什么？

【发布时间】：2018-10-05 10:51:32

【问题描述】：

让我问一下 Redshift 中主表的合适 distkey（dist 样式）和排序键。

我们有几个大小、用途和基数不同的主表，现在我们正在验证哪种 SORTKEY 和 DISTKEY 组合更合适。

例如，我们的客户主表中有两个主键，在我们的 BI 查询中经常使用，其他表的连接键如下；

例如。 MST_CUSTOMER（约 700 万，在 SQL Server 中为 850MB）

CUSTOMER_ID     <-- Primary Key, Unique and High Cardinality
CUSTOMER_CATEGORY   <-- Low Cardinality (like VIP, BZ) but not always uses in BI query
CUST_NAME
CUST_ADDRESS...

首先，如果我们可以将这两个列都用于 SORTKEY，那么在这种情况下，最好的顺序是什么？

1.Should Low cardinality comes first (CUST_CATEGORY, CUST_ID) 
2.Hifh frequency comes first (CUST_ID, CUST_CATEGORY)
3.should chose only single column eigher of CUST_ID or CUST_CATEGORY

一般来说，我可以问一下在这种情况下最好的组合是什么？

1.DISTSTYLE KEY & COMPOUND SORTKEY
2.DISTSTYLE KEY & SORTKEY
3.DISTSTYLE ALL & INTERLEAVED SORTKEY...

我想如果我们经常在查询计划中找到“DS_BCAST_INNER”，我们最好考虑“DISTSTYLE ALL”。 但仍然不确定主表的最佳做法是什么。

任何建议将再次受到赞赏。

最好的问候

【问题讨论】：

两张大表之间最常见的连接是什么？您最常见的 where 子句标准是什么（您总是使用什么 - 例如日期范围）

如果您要将表连接在一起，那么您应该尝试匹配较大表的分布键，或者考虑对较小的表使用 DIST ALL。您不能真正为每个表单独做出分配决策，您需要考虑将在它们上运行什么样的查询并将数据分布到所有节点，以便每个节点最终完成大致相同的工作量.

@Jon Scott 非常感谢您的 cmets，Jon。 Customer_ID 更频繁地寻找和加入其他事务表，但 Customer_Category 仍然在我们的 BI 中用于分析目的。所以我想知道是否应该考虑基数。也许频率优先，Customer_ID 应该放在第一位。谢谢。

@Nathan 再次感谢您的大量 cmets，Nathan。正如您所说，我们最好更多地考虑节点上的实际查询和平衡。我们将尝试与其他表进行键匹配或全部分发。非常感谢！

【参考方案1】：

如果您经常通过 customer_id 加入，则将其设为排序键。 Customer_category 将成为一个很好的辅助排序键。 数据应与将要加入的数据一起分发。如果您有按客户 ID 分发的事实表，则将其设为分发键。 这还取决于您获得了多少新客户。如果销售严重偏向于新客户，那么您的数据分布就会出现偏差，并且 customer_id 将不是一个好的分布键。

【讨论】：

非常感谢您的友好指导，内特。听到这两列都可以是很好的排序键，我松了一口气，只要它们肯定是查询中的搜索键或连接键。我们将尝试继续验证最合适的设置。