amazon-web-services - 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、ti、事件名称

查询计划

Answer 1

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

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

更多节点

将数据分布到更多节点可以实现更多并行化。每个节点都增加了额外的处理和存储。即使您的数据量仅支持一个节点，但如果您想要更高的性能，请添加更多节点。

排序键

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

例如，您的查询有 WHERE brandID = 3927 , 所以有 brandID因为 SORTKEY 将使这一过程非常高效，因为很少有磁盘 block 包含一个品牌的数据。

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

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

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

DISTKEY

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

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

真空

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

实验!

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