Таблица 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 надо будет это заново смотреть.