Size: a a a

ClickHouse не тормозит

2021 March 22

EP

Evgen Pr in ClickHouse не тормозит
нет
источник

EP

Evgen Pr in ClickHouse не тормозит
но на этом CH очень старая версия. 18.12.17
источник

DL

Daniil Lapko in ClickHouse не тормозит
Подскажите как можно решить такую задачу: есть таблица из нее надо агрегировать последнюю неделю, записей очень много, хотелось бы организовать через mv.
источник

KS

Konstantin Sevastian... in ClickHouse не тормозит
Daniil Lapko
Подскажите как можно решить такую задачу: есть таблица из нее надо агрегировать последнюю неделю, записей очень много, хотелось бы организовать через mv.
можно рядом сделать MV которая будет хранить по TTL последнюю неделю и по ней уже строить запрос агрегации
источник

DL

Daniil Lapko in ClickHouse не тормозит
Konstantin Sevastianov
можно рядом сделать MV которая будет хранить по TTL последнюю неделю и по ней уже строить запрос агрегации
А как хранить по TTL, в самой таблице есть только время
источник

KS

Konstantin Sevastian... in ClickHouse не тормозит
без даты?
источник

DL

Daniil Lapko in ClickHouse не тормозит
С датой
источник

DL

Daniil Lapko in ClickHouse не тормозит
Я имею в виду как из таблицы с последней неделю удалять лишние устаревшие записи
источник

KS

Konstantin Sevastian... in ClickHouse не тормозит
Daniil Lapko
Я имею в виду как из таблицы с последней неделю удалять лишние устаревшие записи
TTL event_time + INTERVAL 1 WEEK;
источник

KS

Konstantin Sevastian... in ClickHouse не тормозит
источник

KS

Konstantin Sevastian... in ClickHouse не тормозит
и принудительно делать оптимизации при необходимости
источник

DL

Daniil Lapko in ClickHouse не тормозит
Спасибо, видимо то что нужно
источник

D

Dj in ClickHouse не тормозит
Nikita Gribalev
спасибо за ссылку 🙂
Блин мне уже 10 нотификейшнов пришло ))) офигеть, я вот точно знаю что слак публичный же...

@milovidov_an  - а кто админит слак? люди походу не могут присоединиться
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Evgen Pr
но на этом CH очень старая версия. 18.12.17
а ну это deadlock тогда. Только kill -9 и потом снова drop
источник

EP

Evgen Pr in ClickHouse не тормозит
понял, спасибо
источник

NG

Nikita Gribalev in ClickHouse не тормозит
Dj
Блин мне уже 10 нотификейшнов пришло ))) офигеть, я вот точно знаю что слак публичный же...

@milovidov_an  - а кто админит слак? люди походу не могут присоединиться
ссылка на сайте устарела. Видимо потому что слак больше не дает создавать бессрочные ссылки и теперь нужно обновлять раз в 20-25 дней.

не знаю есть ли способ присоединиться к публичному сообществу в слэке кроме как через ссылку. но за выделенные себе на это 5 минут не справился. если напрямую зайти на https://clickhousedb.slack.com/ (если конечно знаешь где взять такую ссылку), то незнакомые email-ы отфутболивает.
источник

RK

Rebrikov Konstantin in ClickHouse не тормозит
Denny Crane [not a Yandex bot]
я тогда видимо вообще все не так понял.

Т.е. у вас ReplicatedMergeTree , вы пытаетесь колонки очищать toIntervalDay(1)
но у вас часть строк остается неочищенными, несмотря на то что в партиции один парт?
При этом эти поля с TTL, не являются частью partition by / order by.
Таблица ReplicatedMergeTree ( end_datetime типа DateTime - время самого события):
...
PARTITION BY toYYYYMMDD(end_datetime)
ORDER BY (user_id, end_datetime)
TTL (toDate(end_datetime) + toIntervalDay(5)
SETTINGS min_rows_for_wide_part = 4194304, ttl_only_drop_parts = 1;

На используемом (тестовом) стенде проблемы с местом, поэтому чтобы выжать максимальное число дней в глубине хранения, поставил  
... TTL toDate(end_datetime) + toIntervalDay(1)  на все второстепенные столбцы.
Поля, входящие в ключ, без TTL.

merge_with_ttl_timeout = 14400 (дефолтный), но без дополнительного стимулирования он сам довольно лениво чистил. Пробовал периодическими MATERIALIZE TTL ClickHouse подгонять, но пару раз видимо переборщил, и нехорошее начиналось (типа того, что DJ описывал - https://t.me/clickhouse_ru/168468 ).

В отличие от этого OPTIMIZE FINAL каждой ночью безопасный. Но столкнулся с тем, что при этом в старых партишнах, схлопнутых до 1 парта иногда для части записей столбцы, на которых стоит TTL toIntervalDay(1) оставались не очищенными.
В итоге вернулся к периодическим MATERIALIZE TTL – но вдумчиво и аккуратно, только "MATERIALIZE TTL IN PARTITION".

У меня устаревшая версия 20.10, так что, наверное, это не актуально – на 21.3 надо будет это заново смотреть.
источник

DC

Denny Crane [not a Y... in ClickHouse не тормозит
Rebrikov Konstantin
Таблица ReplicatedMergeTree ( end_datetime типа DateTime - время самого события):
...
PARTITION BY toYYYYMMDD(end_datetime)
ORDER BY (user_id, end_datetime)
TTL (toDate(end_datetime) + toIntervalDay(5)
SETTINGS min_rows_for_wide_part = 4194304, ttl_only_drop_parts = 1;

На используемом (тестовом) стенде проблемы с местом, поэтому чтобы выжать максимальное число дней в глубине хранения, поставил  
... TTL toDate(end_datetime) + toIntervalDay(1)  на все второстепенные столбцы.
Поля, входящие в ключ, без TTL.

merge_with_ttl_timeout = 14400 (дефолтный), но без дополнительного стимулирования он сам довольно лениво чистил. Пробовал периодическими MATERIALIZE TTL ClickHouse подгонять, но пару раз видимо переборщил, и нехорошее начиналось (типа того, что DJ описывал - https://t.me/clickhouse_ru/168468 ).

В отличие от этого OPTIMIZE FINAL каждой ночью безопасный. Но столкнулся с тем, что при этом в старых партишнах, схлопнутых до 1 парта иногда для части записей столбцы, на которых стоит TTL toIntervalDay(1) оставались не очищенными.
В итоге вернулся к периодическим MATERIALIZE TTL – но вдумчиво и аккуратно, только "MATERIALIZE TTL IN PARTITION".

У меня устаревшая версия 20.10, так что, наверное, это не актуально – на 21.3 надо будет это заново смотреть.
y вас просто OPTIMIZE FINAL не срабатывает иногда, потому что места на диске нет.
запускайте c optimize_throw_if_noop=1 -- увидите ошибку
источник

D

Dj in ClickHouse не тормозит
Rebrikov Konstantin
Таблица ReplicatedMergeTree ( end_datetime типа DateTime - время самого события):
...
PARTITION BY toYYYYMMDD(end_datetime)
ORDER BY (user_id, end_datetime)
TTL (toDate(end_datetime) + toIntervalDay(5)
SETTINGS min_rows_for_wide_part = 4194304, ttl_only_drop_parts = 1;

На используемом (тестовом) стенде проблемы с местом, поэтому чтобы выжать максимальное число дней в глубине хранения, поставил  
... TTL toDate(end_datetime) + toIntervalDay(1)  на все второстепенные столбцы.
Поля, входящие в ключ, без TTL.

merge_with_ttl_timeout = 14400 (дефолтный), но без дополнительного стимулирования он сам довольно лениво чистил. Пробовал периодическими MATERIALIZE TTL ClickHouse подгонять, но пару раз видимо переборщил, и нехорошее начиналось (типа того, что DJ описывал - https://t.me/clickhouse_ru/168468 ).

В отличие от этого OPTIMIZE FINAL каждой ночью безопасный. Но столкнулся с тем, что при этом в старых партишнах, схлопнутых до 1 парта иногда для части записей столбцы, на которых стоит TTL toIntervalDay(1) оставались не очищенными.
В итоге вернулся к периодическим MATERIALIZE TTL – но вдумчиво и аккуратно, только "MATERIALIZE TTL IN PARTITION".

У меня устаревшая версия 20.10, так что, наверное, это не актуально – на 21.3 надо будет это заново смотреть.
>У меня устаревшая версия 20.10, так что, наверное, это не актуально – на 21.3 надо будет это заново смотреть.

мои 2 копейки. я не видел глобальных исправлений связанных с ТТЛ выполненных в этом промежутке.
можете тут смотреть https://github.com/ClickHouse/ClickHouse/issues/10128

полайкайте мой тикет плз (надо бы его отредактировать чтоб он на колочный ттл тоже был применим)
https://github.com/ClickHouse/ClickHouse/issues/20451
источник

AM

Alexey Milovidov in ClickHouse не тормозит
Dj
Блин мне уже 10 нотификейшнов пришло ))) офигеть, я вот точно знаю что слак публичный же...

@milovidov_an  - а кто админит слак? люди походу не могут присоединиться
Мы админим слак. А в чём проблема, там ссылка не работает?
источник