Redshift производительность для простых данных временных рядов - PullRequest
Новая
       16

Redshift производительность для простых данных временных рядов

0 голосов
/ 29 августа 2018

Я использую таблицу AWS Redshift, которая содержит информацию о вызовах функций. Каждая строка имеет дату (типа отметки времени), UID (varchar) и несколько полей, таких как длительность, код ошибки. Размер таблицы составляет ~ 25 миллионов строк с ~ 1000 различными функциями (каждая с разным UID).

Моя проблема в том, что простые запросы в виде количества вызовов нескольких функций во временном окне занимают много времени - обычно 5-30 секунд.

Я пробовал разные комбинации клавиш сортировки и клавиши dist, но производительность, похоже, остается примерно одинаковой:

  • Установка UID функции в качестве клавиши dist

  • Установка составного ключа сортировки даты, UID функции и их комбинации в любом порядке.

Я запустил ВАКУУМ и АНАЛИЗ на столе. Я также попытался добавить / удалить сжатие столбцов.

Я использую только один узел dc2.large.

EDIT:

Таблица 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 секунд.

1 Ответ

0 голосов
/ 07 сентября 2018

Во-первых, вам нужно использовать как минимум 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 со значением целочисленного идентификатора и используя его в своих запросах. Значения UID довольно неэффективны для работы. Значения встречаются случайно и являются относительно широкими с очень высокой энтропией. Они дороги во время сортировок, хэширования и хеш-соединений.

...