EP
нет
Size: a a a
2021 March 22
EP
но на этом CH очень старая версия. 18.12.17
DL
Подскажите как можно решить такую задачу: есть таблица из нее надо агрегировать последнюю неделю, записей очень много, хотелось бы организовать через mv.
KS
Подскажите как можно решить такую задачу: есть таблица из нее надо агрегировать последнюю неделю, записей очень много, хотелось бы организовать через mv.
можно рядом сделать MV которая будет хранить по TTL последнюю неделю и по ней уже строить запрос агрегации
DL
можно рядом сделать MV которая будет хранить по TTL последнюю неделю и по ней уже строить запрос агрегации
А как хранить по TTL, в самой таблице есть только время
KS
без даты?
DL
С датой
DL
Я имею в виду как из таблицы с последней неделю удалять лишние устаревшие записи
KS
Я имею в виду как из таблицы с последней неделю удалять лишние устаревшие записи
TTL event_time + INTERVAL 1 WEEK;
KS
и принудительно делать оптимизации при необходимости
DL
D
спасибо за ссылку 🙂
Блин мне уже 10 нотификейшнов пришло ))) офигеть, я вот точно знаю что слак публичный же...
@milovidov_an - а кто админит слак? люди походу не могут присоединиться
@milovidov_an - а кто админит слак? люди походу не могут присоединиться
DC
Evgen Pr
но на этом CH очень старая версия. 18.12.17
а ну это deadlock тогда. Только kill -9 и потом снова drop
EP
понял, спасибо
NG
Блин мне уже 10 нотификейшнов пришло ))) офигеть, я вот точно знаю что слак публичный же...
@milovidov_an - а кто админит слак? люди походу не могут присоединиться
@milovidov_an - а кто админит слак? люди походу не могут присоединиться
ссылка на сайте устарела. Видимо потому что слак больше не дает создавать бессрочные ссылки и теперь нужно обновлять раз в 20-25 дней.
не знаю есть ли способ присоединиться к публичному сообществу в слэке кроме как через ссылку. но за выделенные себе на это 5 минут не справился. если напрямую зайти на https://clickhousedb.slack.com/ (если конечно знаешь где взять такую ссылку), то незнакомые email-ы отфутболивает.
не знаю есть ли способ присоединиться к публичному сообществу в слэке кроме как через ссылку. но за выделенные себе на это 5 минут не справился. если напрямую зайти на https://clickhousedb.slack.com/ (если конечно знаешь где взять такую ссылку), то незнакомые email-ы отфутболивает.
RK
я тогда видимо вообще все не так понял.
Т.е. у вас ReplicatedMergeTree , вы пытаетесь колонки очищать toIntervalDay(1)
но у вас часть строк остается неочищенными, несмотря на то что в партиции один парт?
При этом эти поля с TTL, не являются частью partition by / order by.
Т.е. у вас 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 надо будет это заново смотреть.
...
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
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 надо будет это заново смотреть.
...
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 -- увидите ошибку
запускайте c optimize_throw_if_noop=1 -- увидите ошибку
D
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 надо будет это заново смотреть.
...
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
мои 2 копейки. я не видел глобальных исправлений связанных с ТТЛ выполненных в этом промежутке.
можете тут смотреть https://github.com/ClickHouse/ClickHouse/issues/10128
полайкайте мой тикет плз (надо бы его отредактировать чтоб он на колочный ттл тоже был применим)
https://github.com/ClickHouse/ClickHouse/issues/20451
AM
Блин мне уже 10 нотификейшнов пришло ))) офигеть, я вот точно знаю что слак публичный же...
@milovidov_an - а кто админит слак? люди походу не могут присоединиться
@milovidov_an - а кто админит слак? люди походу не могут присоединиться
Мы админим слак. А в чём проблема, там ссылка не работает?