partition_date Date,
value Float64
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/test_table',
'{replica}') PARTITION BY partition_date ORDER BY (partition_date, value) TTL partition_date + toIntervalMonth(1);
Я ожидал, что в таблице будут удаляться данные старше чем месяц назад (по колонке partition_date), но
select min(t), max(t)
from test_table;
Выдает
+----------+----------+
|min(t) |max(t) |
+----------+----------+
|2019-12-30|2020-12-06|
+----------+----------+
В логах ничего не видно, в какую сторону копать?
удаление старых данных асинхронный процесс происходит во время background процессов либо во время background merge (после вставки новых данных идет слияние со старыми) либо во время scheduled background tasks (раз в сутки по умолчанию) https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#mergetree-query-clauses merge_with_ttl_timeout — Minimum delay in seconds before repeating a merge with TTL. Default value: 86400 (1 day). если нет вставки, то удаление раз в сутки
менять дефолтные настройки не советую если не понимаете что делаете можете увеличить нагрузку на чтение \ запись с диска необосновано
Оно так уже пару месяцев живет. Запись в таблицу раз в сутки
PARTITION BY partition_date версия КХ ? проблема в дизайне TTL , он проверяет 1 одну партицию за раз, чтобы не заниматься бесконечными TTL, потому что пока удаляешь из одной партиции, некоторые записи состарятся в другой, т.е. можно настроить в новых версиях КХ. но в вашем случае логично дропать партии целиком, а не TTL-ить по записям alter table test_table modify settings ttl_only_drop_parts=1
VERSION_FULL ClickHouse 20.3.11.97| Я посмотрю, спасибо
Обсуждают сегодня