Redshift 查询花费太多时间

Question

在 Redshift 中，查询执行时间过长。有些查询会在一段时间后继续运行或中止。

我对 Redshift 的了解非常有限，并且越来越难以理解优化查询的查询计划。

共享我们运行的查询之一以及查询计划。执行查询需要 20 秒。

询问

SELECT
    date_trunc('day',
    ti) as date,
    count(distinct deviceID) AS COUNT    
FROM
    live_events
WHERE
    brandID = 3927
    AND ti >= '2017-08-02T00:00:00+00:00'
    AND ti <= '2017-09-02T00:00:00+00:00'
GROUP BY
    1  

主键
品牌ID

交错排序键
我们将以下列设置为交错排序键 -
BrandID、ti、event_name

查询计划

Answer 1

该表中有 1.26 亿行。在单个dc1.large节点上将花费一秒钟以上的时间。

以下是一些可以提高性能的方法：

更多节点

跨更多节点传播数据允许更多的并行化。每个节点都增加了额外的处理和存储。即使您的数据量只能证明一个节点是合理的，但如果您想要更高的性能，请添加更多节点。

排序键

对于正确的查询类型，SORTKEY 可能是提高查询速度的最佳方式。对磁盘上的数据进行排序允许 Redshift跳过它知道不包含相关数据的块。

例如，您的查询具有WHERE brandID = 3927，因此将其brandID作为 SORTKEY 将使这非常有效，因为很少有磁盘块会包含一个品牌的数据。

交错排序很少是最好的排序方法，因为它不如单个或复合排序键有效，并且需要很长时间才能 VACUUM。如果你已经显示的查询是典型的正在运行的查询的类型，然后使用复合排序关键字的brandId, ti或ti, brandId。效率会高很多。

SORTKEYs 通常是一个日期列，因为它们经常出现在 WHERE 子句中，如果数据总是按时间顺序附加，表将自动排序。

交错排序会导致 Redshift 读取更多磁盘块以查找数据，从而显着增加查询时间。

密钥

DISTKEY 通常应设置为表的 JOIN 语句中最常用的字段。这是因为与同一 DISTKEY 值相关的数据存储在同一片上。这不会对单节点集群产生如此大的影响，但仍然值得正确处理。

同样，您只显示了一种类型的查询，因此很难推荐 DISTKEY。仅基于此查询，我建议DISTKEY EVEN所有切片都参与查询。（如果没有选择特定的 DISTKEY，它也是默认的 DISTKEY。）或者，将 DISTKEY 设置为一个未显示的字段——但当然不要brandId用作 DISTKEY 否则只有一个切片将参与显示的查询。

真空

定期清空您的表，以便数据按 SORTKEY 顺序存储，并从存储中删除已删除的数据。

实验！

最佳设置取决于您的数据和您通常运行的查询。执行一些测试以比较 SORTKEY 和 DISTKEY 值并选择性能最佳的设置。然后，在 3 个月后再次测试，看看您的查询或数据是否已更改到足以使其他设置更有效的程度。