ClickHouseMiddleTechnical
Что такое mutations и почему UPDATE/DELETE в ClickHouse дорогие?
Mutations — это фоновые операции, перезаписывающие куски данных целиком. UPDATE и DELETE дороги, потому что ClickHouse — append-only движок: нет in-place изменений, вся партиция читается и записывается заново.
Что такое 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 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;
Синхронное ожидание (для тестов/миграций)
-- Выполнить мутацию синхронно (блокирует до завершения)
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 минут).
Common mistakes
- Отвечать определением без production-сценария.
- Не называть runtime boundary, security boundary или failure mode.
- Игнорировать версию API, observability и тестовую проверку.
What the interviewer is testing
- Объясняет механизм своими словами и без выдуманных API.
- Называет реальные риски, диагностику и критерий корректности.
- Связывает ответ с текущей документацией и миграционными ограничениями.