Что такое mutations и почему UPDATE/DELETE в ClickHouse дорогие?

Синтаксис и мониторинг

-- Обновление
ALTER TABLE events UPDATE status = 'archived'
WHERE event_date < '2024-01-01';

-- Удаление
ALTER TABLE events DELETE
WHERE user_id = 42;

-- Статус фоновых мутаций
SELECT
    mutation_id,
    command,
    parts_to_do,
    parts_done,
    is_done,
    latest_fail_reason
FROM system.mutations
WHERE is_done = 0
ORDER BY create_time DESC;

Что такое Mutations

В ClickHouse команды ALTER TABLE ... UPDATE и ALTER TABLE ... DELETE называются mutations (мутациями). Они не изменяют данные мгновенно: вместо этого создаётся фоновая задача, которая читает существующие куски (parts), применяет предикат и записывает новые куски с изменёнными данными. Старые куски удаляются после завершения.

Почему это дорого

MergeTree — append-only колоночное хранилище. Нет WAL с механизмом MVCC как в PostgreSQL; данные записаны в неизменяемые файлы колонок (`.bin`). Чтобы изменить одну строку, ClickHouse вынужден:

• Прочитать весь part целиком (включая все колонки).
• Применить предикат к каждой строке.
• Записать новый part на диск.
• Обновить индексные файлы (primary.idx, *.mrk3).
• Удалить старый part после финализации.

Синхронное ожидание (для тестов/миграций)

-- Выполнить мутацию синхронно (блокирует до завершения)
ALTER TABLE events DELETE WHERE user_id = 42
SETTINGS mutations_sync = 1;

Альтернативы мутациям

• ReplacingMergeTree — вставить новую версию строки; старая будет вытеснена при слиянии. Подходит для обновлений без гарантий реального времени.
• CollapsingMergeTree / VersionedCollapsingMergeTree — «отменить» строку парой (sign=-1, старые данные) + (sign=+1, новые данные).
• Партиционирование + DROP PARTITION — если удаляются целые временные срезы, ALTER TABLE DROP PARTITION мгновенен и бесплатен.
• TRUNCATE TABLE — мгновенное удаление всех данных без мутаций.

Настройки для снижения нагрузки

<!-- config.xml -->
<background_pool_size>4</background_pool_size>

-- Ограничить скорость мутаций (число одновременных)
SET max_mutations_for_background_processing = 2;

Подводные камни

• Мутации не транзакционны — если узел упал в середине мутации, она будет перезапущена с начала; это безопасно (идемпотентно), но дорого по времени.
• Мутации блокируют слияния — фоновый пул разделяется между мерджами и мутациями; массовое удаление может остановить штатные слияния, что приводит к взрыву числа частей.
• Частые UPDATE на горячих таблицах — мутация на таблице с активными вставками создаёт «вечный» цикл: новые parts вставляются быстрее, чем мутация их обрабатывает.
• system.mutations не чистится автоматически — завершённые мутации накапливаются; периодически запускайте ALTER TABLE ... CLEAR COLUMN или проверяйте размер таблицы.
• mutations_sync = 1 опасен в продакшне — блокирует HTTP/TCP-соединение до завершения мутации; используйте только для миграций в обслуживании.
• DELETE не освобождает дисковое пространство сразу — старые parts помечаются как inactive и удаляются только после old_parts_lifetime секунд (по умолчанию 8 минут).

• Отвечать определением без production-сценария.
• Не называть runtime boundary, security boundary или failure mode.
• Игнорировать версию API, observability и тестовую проверку.

• Объясняет механизм своими словами и без выдуманных API.
• Называет реальные риски, диагностику и критерий корректности.
• Связывает ответ с текущей документацией и миграционными ограничениями.