简单时间序列数据的 Redshift 性能

Posted

技术标签:

【中文标题】简单时间序列数据的 Redshift 性能【英文标题】:Redshift performance for simple time series data 【发布时间】:2018-08-29 15:30:07 【问题描述】:

我正在使用 AWS Redshift 表,其中包含有关函数调用的信息。 每行都有一个日期(时间戳类型)、一个 UID(varchar)和几个字段,例如持续时间、错误代码。 表的大小约为 2500 万行,包含约 1000 个不同的函数(每个函数都有不同的 UID)。

我的问题是,简单的查询作为时间窗口中几个函数的调用计数需要很长时间 - 通常是 5-30 秒。

我尝试过排序键和 dist 键的不同组合,但性能似乎仍然非常相似:

设置函数UID为dist key

以任意顺序设置日期、函数 UID 和两者的组合的复合排序键。

我在桌子上运行了 VACUUM 和 ANALYZE。 我还尝试添加/删除列压缩。

我只使用一个 dc2.large 节点。

编辑:

表 DDL 为:

create table public."invocations_metrics_$mig"(
"function_uid" varchar(256)  NOT NULL encode RAW DISTKEY
,"date" timestamp    encode zstd 
,"duration" double precision   encode zstd 
,"used_memory" integer   encode zstd 
,"error" smallint   encode zstd 
,"has_early_exit" boolean   encode zstd 
,"request_id" varchar(256)   encode zstd 
)
 SORTKEY(date,function_uid);

一行示例:

"aca500c9-27cc-47f8-a98f-ef71cbc7c0ef","2018-08-15 13:43:28.718",0.17,27,0,false,"30ee84e1-a091-11e8-ba47-b110721c41bc"

查询:

SELECT
    count(invocations_metrics_backup.function_uid) AS invocations,
    max(invocations_metrics_backup.date) AS last_invocation,
    invocations_metrics_backup.function_uid AS uid
FROM
    invocations_metrics_backup
WHERE
    function_uid IN (
        <10 UIDs>
    )
    AND DATE >= '2018-08-20T10:55:20.222812'::TIMESTAMP
GROUP BY
    function_uid

总时间为 5 秒。每个查询中的计数约为 5000。 对于具有约 1M 计数的相同查询,它需要 30 秒。

【问题讨论】:

请显示一些示例数据和您正在使用的确切 sql。连同表格的 ddl。也是该查询的确切时间(第二次运行 - 不是第一次) 已编辑。我已经为示例禁用了会话缓存(否则第二个查询非常快)。谢谢! 您的 dist 键可能会导致问题。尝试使用“diststyle even”并且没有排序键并发布时间。 提高了大约 20%。这很好,但我认为这个查询应该减少 90% 的时间。 【参考方案1】:

首先,您需要使用至少 2 个节点。单个节点必须承担作为领导者和计算者的双重职责。如果有 2 个或更多节点,您将获得一个免费的领导节点。

然后,如下更改您的 DDL,删除排序键上的压缩:

CREATE TABLE public."invocations_metrics_$mig" (
    "function_uid"   varchar(256) NOT NULL ENCODE ZSTD,
    "date"           timestamp             ENCODE RAW,
    "duration"       double precision      ENCODE ZSTD,
    "used_memory"    integer               ENCODE ZSTD,
    "error"          smallint              ENCODE ZSTD,
    "has_early_exit" boolean               ENCODE ZSTD,
    "request_id"     varchar(256)          ENCODE ZSTD
) 
DISTSTYLE KEY 
DISTKEY( function_uid )
SORTKEY ( date )
;

您还可以通过将唯一 UID 映射到整数 ID 值并在查询中使用它来提高性能。 UID 值的使用效率非常低。这些值随机出现并且相对较宽且熵非常高。它们在排序、散列聚合和散列连接期间很昂贵。

【讨论】:

以上是关于简单时间序列数据的 Redshift 性能的主要内容,如果未能解决你的问题,请参考以下文章

Redshift 时间序列数据库的 Dist/Sort 键

Redshift JSON 性能

redshift 是不是序列化写操作?

Amazon Redshift - 复制 - 数据加载与查询性能问题

Redshift SQL - 跳过的序列

为啥 Amazon Redshift UNLOAD 性能对于新数据要好得多?