Изменения, удаления и TTL

Mutations, lightweight DELETE, версионные записи и отложенное освобождение места.

ClickHouse умеет изменять и удалять данные, но физическая работа отличается от точечного изменения строки в OLTP-базе. Части MergeTree в основном неизменяемы: операция либо создаёт новое представление затронутых данных, либо сохраняет дополнительные сведения для чтения.

Mutations

Традиционные ALTER TABLE UPDATE и DELETE создают mutation — задачу изменения частей. Например, в таблице events с полями event_id и status:

ALTER TABLE events
UPDATE status = 'corrected'
WHERE event_id = 42;

Даже если условие выбирает немного строк, затронутые данные может потребоваться переписать в большем объёме. Частые точечные обновления создают нагрузку на диск и фоновые процессы. Ключевые поля, влияющие на организацию данных, нельзя свободно обновлять таким способом.

По умолчанию mutation выполняется асинхронно: получение ответа не означает, что все части уже изменены. mutations_sync позволяет ожидать соответствующий уровень завершения, а system.mutations показывает состояние и ошибки. Во время выполнения не следует предполагать атомарный переход всей большой таблицы от старого состояния к новому.

Lightweight DELETE

DELETE FROM events WHERE ... помечает строки невидимыми через маску существования. Обычное чтение исключает их после применения удаления, а физическое освобождение места происходит позже при слиянии частей.

Стоимость удаления зависит от формата parts: в Wide отдельную маску можно записать дешевле, чем переписывать данные Compact-части.

Для обязательного физического удаления нужно учитывать срок фоновой очистки, реплики и резервные копии. Отсутствие строки в SELECT само по себе не доказывает уничтожение всех её копий.

Lightweight UPDATE

Современный UPDATE может сохранять patch parts — небольшие части с изменёнными значениями и указанием строк, к которым их применять. Чтение учитывает патчи, а фоновые процессы позднее объединяют их с основными данными.

В ветке 25.8 механизм beta: нужны соответствующие настройки и совместимая таблица. В основной практике он не используется. Для своей версии проверяют ограничения ключевых полей и требования к идентификации строк.

Для частых поступающих состояний нередко используют новые версионные строки и ReplacingMergeTree. Тогда чтение должно выбирать актуальное состояние, а модель обязана учитывать поздние версии и повторы.

TTL

TTL, time to live, задаёт правило жизненного цикла данных. Например, события можно удалять через 30 дней после их времени:

CREATE TABLE expiring_events
(
    event_time DateTime('UTC'),
    event_type String
)
ENGINE = MergeTree
ORDER BY event_time
TTL event_time + INTERVAL 30 DAY DELETE;

Это возраст по event_time, а не по времени загрузки. Поздно поступившая старая запись уже может подпадать под правило. TTL применяется в фоне, обычно при merge; он не удаляет каждую строку ровно в заданную секунду.

TTL также может перемещать данные между настроенными уровнями хранения, очищать отдельные значения или укрупнять данные по заданной агрегации. Срок сырой истории и срок хранения витрины задают отдельно. Удаление или исправление исходных строк не пересчитывает инкрементальную materialized view автоматически.