sql - Redshift : DIST KEY and SORT KEY strategy for Range Joins

Question

我有一个缓慢变化的维度，代表我们所有文章主数据的变化，并且非常庞大:150 亿行并且还在增长。

该表目前分布在自然集合中，例如(国家/地区、供应商)。

由于表的性质，使用它的大多数查询都是范围联接，例如对不断变化的文章属性进行简单的订单计数:

SELECT x.article_id, x.changing_article_season, COUNT(*) counting_orders
FROM article_slow_changing_dimension x
LEFT JOIN orders y ON x.article_id=y.article_id
AND y.order_timestamp BETWEEN x.from_timestamp AND y.to_timestamp

这里选择排序键的有趣策略是什么？ 我正在考虑做 SORTKEY(from_timestamp, to_timestamp) 但我不确定。

我尝试了一些方法，但任何测试都需要很长时间才能设置，而且实际上很难凭经验进行评估。有什么想法吗？

编辑:根据评论添加一些细节 1/ table 被吸尘 2/集群非常小(4个节点)，查询运行得非常快，但它没有投入生产，所以基本上只有我开发人员运行一些查询。我想在投入生产之前进行优化 3/目前大约有 150 亿行，聚合特定时间戳需要 1 分钟；但我想把它缩短到 20 秒

Answer 1

很好的问题。

一点背景知识，排序键有 2 个主要目的:1)最小化从磁盘扫描的数据，2)启用大型表之间的联接以使用合并联接(最快联接)。 https://docs.aws.amazon.com/redshift/latest/dg/query-performance-improvement-opportunities.html

SORTKEY(from_timestamp, to_timestamp)通常是一个非常好的选择，但它不会提高示例查询的性能。当您在像 WHERE from_timestamp > '2019-01-01' AND to_timestamp < current_date 这样的谓词中使用这些字段时，它会更有帮助。 .

这种范围连接的优化程度是有限的，因为数据库必须将其视为笛卡尔积(又名“交叉连接” - 将 a 中的每一行与 b 中的每一行连接起来) )。您知道连接将匹配单行，但数据库不知道。

在全维 DW 中，我会创建一个 article_sk代理键。该值将恰好解析为 SCD 中的一个值。但这会使 ETL 过程变得复杂，因为您必须在处理过程中注入(inject)代理键。

您可以做的另一件事是使用 article 分配两个表。柱子。这允许在每个切片上并行完成连接。然而，article可能不会成为您的 orders 的自然分发 key 事实表(通常是 customer 或 account )。