Redshift Query占用了太多时间

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  

主键
brandID

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

查询计划

Python Zen

Answer 1

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

以下是一些可以改善效果的方法：

更多节点

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

<强> SORTKEY

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

例如，您的查询有WHERE brandID = 3927，因此将brandID作为SORTKEY可以提高效率，因为很少有磁盘块会包含一个品牌的数据。

交错排序很少是最好的排序方法，因为它的效率低于单个或复合排序键，并且需要很长时间才能使用VACUUM。如果您显示的查询是您正在运行的查询类型的典型，那么使用brandId, ti或ti, brandId的复合排序键。它会更有效率。

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

Interleaved Sort会导致Redshift读取更多磁盘块以查找数据，从而大大增加查询时间。

<强> DISTKEY

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

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

<强>真空

定期对您的表进行VACUUM，以便数据以SORTKEY顺序存储，并从存储中删除已删除的数据。

<强>实验！

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

Answer 2

有时候，问题可能是由于其他进程获取了锁引起的。您可以参考：https://aws.amazon.com/premiumsupport/knowledge-center/prevent-locks-blocking-queries-redshift/