Транзакции в ClickHouse

ClickHouse изначально спроектирован как колоночно‑ориентированная аналитическая СУБД для высокоскоростного чтения и потоковой записи. Именно поэтому классическая модель транзакций, свойственная OLTP‑системам, в ClickHouse долгое время отсутствовала. Вместо этого приоритетом были векторизованная обработка, массовые вставки и фоновые слияния, обеспечивающие высокую пропускную способность запросов аналитического класса.

На практике корпоративные сценарии постепенно усложняются: появляются конвейеры ingest с требованиями к согласованности и видимости данных, «точки согласованности» между несколькими таблицами, строгие SLO на вставку, а также ожидания от разработчиков и архитекторов о наличии хотя бы частичной «ACID‑семантики». Ответом на этот вызов стала экспериментальная поддержка транзакций уровня ACID для операций INSERT в таблицы движка MergeTree без репликации. Это важное, но узкое по области применения улучшение, требующее осознанного проектирования потоков записи и четкого понимания ограничений OLAP‑архитектуры ClickHouse.

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

Теоретическая база: ACID, CAP и специфика колоночных СУБД

Транзакционная семантика ACID включает четыре свойства:

Атомарность (Atomicity): операция либо выполняется целиком, либо откатывается.
Согласованность (Consistency): транзакция переводит БД из одного согласованного состояния в другое, соблюдая ограничения.
Изоляция (Isolation): параллельные транзакции не мешают друг другу и наблюдают согласованные снимки данных.
Долговечность (Durability): после подтверждения результат не теряется при сбоях.

В распределенных системах действует также теорема CAP (Consistency, Availability, Partition tolerance), подчеркивающая невозможность одновременного максимума по всем трем осям в условиях сетевых разбиений. Аналитические СУБД, и особенно колоночные, традиционно оптимизируют чтение и throughput пакетных операций. Колонки эффективно сжимаются, обрабатываются векторно и дисково хранятся по столбцам, что дает выигрыши для агрегаций и сканирований, но усложняет строго последовательные, построчные обновления и полноценную транзакционность.

В OLAP важны:

векторизованное исполнение,
пакетные вставки,
фоновая компакция (слияния),
согласованные «снимки» при чтении,
предсказуемая латентность запросов на больших объемах.

Именно эти приоритеты определяют компромиссы ClickHouse по сравнению с OLTP‑решениями.

Архитектура ClickHouse, релевантная транзакциям: MergeTree, части, партиционирование, фоновые слияния

Семейство движков MergeTree - основа аналитических таблиц в ClickHouse. Ключевые элементы:

Партиции - логические разделы по ключу партиционирования (часто - по дате/месяцу).
Части (parts) - физические куски данных внутри партиций, создаваемые при вставках.
Праймари‑индекс (primary key) и сортировка - данные внутри части отсортированы по ключу, что ускоряет чтение и диапазонные фильтры.
Фоновые слияния (merge) - объединяют мелкие части в более крупные, оптимизируя хранение и чтение.

Вставка создает новые части, затем асинхронные merge‑процессы их компактизируют. Такая архитектура обеспечивает высокую скорость ingest при массовой вставке и хорошую масштабируемость чтения за счет сортировки и компрессии.

Векторизованная обработка, блоки и пакетная вставка: max_block_size и рекомендации по объёмам

ClickHouse обрабатывает данные блоками (blocks) - наборами фрагментов столбцов. Параметр max_block_size определяет целевой максимум строк в одном блоке при обработке. Хотя это не жесткая гарантия, фактически он влияет на гранулярность векторизации и на стоимость операций.

Важные следствия:

Пакетная вставка снижает накладные расходы на парсинг, распределение по партициям и создание частей.
Массовая вставка, измеряемая сотнями тысяч или миллионами строк за запрос, как правило, эффективнее, чем множество мелких INSERT.
Если данные приходят в хронологическом порядке, совпадающем с ключом партиционирования (например, по времени), деградации меньше, но методы группировки по партициям перед вставкой остаются желательными.

Практика показывает, что оптимальными являются партии порядка 100 000+ строк; для крупных пайплайнов - миллионы строк. Слишком мелкие партии приводят к избыточному числу частей, росту очередей merge и падению производительности.

Почему в ClickHouse нет полноценных транзакций

Полноценные транзакции сложны для эффективной реализации в колоночной архитектуре с массовыми вставками, фоновыми слияниями и распределенной природой кластера. Для OLAP важнее:

throughput и компрессия, чем мгновенная построчная долговечность;
согласованные снимки на чтение, чем строгая серилизуемость OLTP;
экономия на случайных дисковых записях, чем немедленная запись каждого события.

Эти приоритеты противоречат ожиданиям «жестких» ACID‑свойств для произвольных DML/DDL. Поэтому ClickHouse ограничился экспериментальной ACID‑семантикой для вставок в локальные MergeTree‑таблицы, где архитектурно проще обеспечить атомарность частей и предсказуемую видимость без сложных протоколов координации.

Экспериментальная поддержка ACID для INSERT в MergeTree без репликации: область применимости и ограничения

Экспериментальная транзакционность распространяется только на операции INSERT и только для таблиц движка MergeTree без репликации. Это означает:

Нельзя полагаться на транзакционность для UPDATE/DELETE/ALTER или для реплицируемых таблиц.
Создание таблиц и DDL не являются транзакционными.
Вложенные транзакции не поддерживаются.
Семантика «атомной» вставки действует на уровне частей и партиций.

Такая зона применимости позволяет достичь баланса между потребностями ingest‑контуров и архитектурными рамками OLAP.

Гарантии ACID для INSERT: атомарность, согласованность, изоляция, долговечность

В рамках экспериментальной функции гарантируются:

Атомарность: если вставка целится в один раздел (партицию) одной таблицы, операция либо целиком видна, либо полностью отклонена. При вставке в несколько партиций атомарность действует отдельно на каждую партицию: часть по каждой партиции формируется независимо.
Согласованность: если таблица имеет ограничения, их корректность проверяется построчно; при нарушении хотя бы для одной строки соответствующий INSERT останавливается.
Изоляция: конкурирующие клиенты наблюдают согласованный снимок - состояние до начала вставки или после ее завершения. Промежуточных состояний не видно.
Долговечность: успешная вставка фиксируется в файловой системе до подтверждения клиенту; при необходимости можно потребовать синхронизацию данных на носитель настройкой fsync_after_insert.

Для нереплицируемых MergeTree‑таблиц долговечность относится к локальному диску узла. Кворумные механизмы вставки (insert_quorum) релевантны прежде всего реплицируемым таблицам и к экспериментальной транзакционности локальных MergeTree прямого отношения не имеют.

Синхронная вставка: сортировка по ключу, формирование частей и подтверждение операции

Синхронная вставка работает следующим образом:

Клиент отправляет INSERT.
Данные сортируются по первичному ключу и разбиваются по партициям согласно ключу партиционирования.
По каждой целевой партиции формируется как минимум одна новая часть на диске.
После успешной записи части (частей) и, при включенном fsync_after_insert, после синхронизации с носителем, сервер подтверждает INSERT клиенту.

Важные аспекты:

Параллельные INSERT могут выполняться и подтверждаться в любом порядке, изоляция соблюдается за счет «снимков».
Вставки в несколько партиций одновременно замедляют обработку; для максимальной производительности рекомендуется группировать записи по партициям и вставлять пачками.

Асинхронная вставка: async_insert, HTTP-протокол, wait_for_async_insert и отсутствие дедупликации

Для сценариев с множеством мелких запросов доступен асинхронный режим INSERT по HTTP:

async_insert включает асинхронную вставку: данные сначала записываются во внутренний буфер, фактический INSERT выполняется позже.
Параметр wait_for_async_insert управляет тем, дожидается ли клиент завершения вставки. При значении 1 (по умолчанию) клиент ожидает результат и сохраняется атомарность; при значении 0 клиент получает ответ без ожидания, и атомарность на границе клиентского запроса не гарантируется.
Асинхронные INSERT поддерживаются только через HTTP.
Дедупликация для асинхронных вставок не выполняется. Это означает, что при сетевых повторных попытках или тайм‑аутах следует проектировать идемпотентные конвейеры самостоятельно (например, путем вложения детерминированных ключей, семантики upsert на стороне приёма или внешнего реестра поставок).

Асинхронный режим полезен для высокочастотных источников, где цена round‑trip критична, а «мягкая» гарантия доставки и последующей вставки приемлема.

Кворум и долговечность: insert_quorum, fsync_after_insert и взаимодействие с файловой системой

fsync_after_insert - настройка, обязательная к рассмотрению для систем с жесткими требованиями к долговечности. При включении сервер явно просит ОС синхронизировать данные на носитель перед подтверждением INSERT. Это увеличивает латентность, особенно на медленных дисках, но повышает надежность.
insert_quorum - параметр, актуальный для реплицируемых таблиц: подтверждение клиенту происходит только после того, как часть появится на нужном числе реплик. Для локальных MergeTree (без репликации) кворум неприменим.

Важно учитывать файловую систему и режимы монтирования. В условиях агрессивного кэширования ОС и журналирования ФС эффект fsync_after_insert становится критичным для реальной долговечности.

Транзакционность в сложных сценариях: несколько партиций, материализованные представления, распределённые таблицы

Несколько партиций: при одном INSERT в разные партиции атомарность действует на уровне партиции. Возможны ситуации «частичного успеха» между партициями. Рекомендуется группировать данные по партициям для предсказуемости.
Материализованные представления (Materialized Views): INSERT в исходную таблицу может приводить к дополнительным вставкам в целевые таблицы представлений. В нереплицируемых конфигурациях обработка выполняется синхронно в рамках конвейера вставки. Следует внимательно тестировать согласованность: для бизнес‑критичных сценариев желательно, чтобы производные данные становились видны вместе с исходными, без промежуточных состояний.
Распределенные таблицы (Distributed): INSERT в распределенную таблицу не является транзакционным в целом. По сути, это «фан‑аут» на подлежащие шардовые таблицы, и транзакционность нужно оценивать на каждом целевом сегменте отдельно. В результате невозможна глобальная атомарность на уровне всех шардов.

Нетривиальные движки и их семантика: Buffer и Replicated*; влияние на транзакционность

Buffer: данные буферизуются в оперативной памяти и периодически сбрасываются в целевую таблицу. Такая вставка не является транзакционной по определению: буфер может потерять содержимое при сбое, а момент материализации непредсказуем для внешнего наблюдателя.
ReplicatedMergeTree и семейство Replicated*: в этих движках задействуется координация через ClickHouse Keeper/ZooKeeper. Экспериментальная транзакционность INSERT не распространяется на реплицируемые таблицы. Надежность обеспечивается другими механизмами - очередями репликации, кворумом вставки, дедупликацией частей по блок‑номерам для защиты от повторной доставки.

При выборе движка следует соотносить требования к ACID‑вставкам с потребностями в репликации и отказоустойчивости.

Управление жизненным циклом транзакций: включение allow_experimental_transactions, BEGIN/COMMIT и видимость данных

Экспериментальная функция выключена по умолчанию и должна быть включена в конфигурации сервера:

После включения поддерживаются базовые инструкции управления транзакциями (например, BEGIN TRANSACTION, COMMIT). Важные замечания:

Поддержка распространяется только на INSERT и только на нереплицируемые MergeTree‑таблицы.
Вложенные транзакции не поддерживаются.
Видимость: при выполнении транзакционной вставки в рамках одного сеанса можно увидеть вставленные строки до фиксации, однако согласованные «снимки» для других клиентов отражают состояние либо до начала, либо после COMMIT.
Проверить наличие транзакций можно через таблицу system.transactions, но из другого сеанса (внутри текущей транзакции запрос к system.transactions недоступен).

Наблюдаемость и диагностика: system.transactions, журналирование и операционные оговорки

Для мониторинга транзакций и вставок используйте:

system.transactions - видимые активные транзакции и их состояние.
system.parts, system.part_log - анализ количества и динамики частей.
system.merges, system.merge_tree_settings - контроль фоновых слияний.
Журналы сервера - для диагностики тайм‑аутов, ошибок при формировании частей и конфликтов ограничений.

Операционные оговорки:

Диагностика транзакций выполняется из отдельного сеанса.
В условиях высокой нагрузки рост числа мелких частей быстро приводит к деградации. Мониторьте backlog merges и ограничивайте число активных слияний, балансируя с ingest.

Мутации и DDL: отсутствие атомарности мутаций по частям, порядок применения, system.mutations, ALTER и alter_sync

Мутации (UPDATE/DELETE на MergeTree) исполняются постфактум, перезаписывая данные по частям:

Атомарность на уровне всей таблицы отсутствует. Части заменяются мутированными постепенно; запросы SELECT, запущенные во время мутации, видят смешанное состояние.
Мутации линейно упорядочены и применяются к каждой части в порядке добавления. Гарантируется согласованность порядка относительно вставок: данные, вставленные до старта мутации, будут изменены; после окончания - не затронутся.
Добавление мутации завершается мгновенно (в Replicated - через Keeper, в нереплицируемых - запись на ФС). Исполнение - асинхронно.
Наблюдаемость - таблица system.mutations. Прервать проблемную мутацию можно KILL MUTATION; откат не поддерживается.
Хранение истории завершенных мутаций регулируется finished_mutations_to_keep.

DDL:

Для нереплицируемых таблиц ALTER выполняется синхронно.
Для реплицируемых таблиц ALTER добавляет инструкции в Keeper; при необходимости ожидание синхронизируется настройкой alter_sync. Время ожидания для неактивных реплик - replication_wait_for_inactive_replica_timeout.

Декомпозиция компонентов и их взаимодействие: путь INSERT, снапшоты чтения, Keeper/ZooKeeper как координатор

Путь INSERT в локальную MergeTree:

Парсинг и планирование.
Векторное формирование блоков.
Сортировка по первичному ключу и разбиение по партициям.
Создание временной части на диске.
Атомарное переименование во «взрослую» часть и регистрация в метаданных.
Подтверждение клиенту (после опционального fsync).

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

Keeper/ZooKeeper:

*Для Replicated выполняют роль координатора**: очереди операций, фиксация статусов, раздача блокировок и согласование репликаций.
Для локальных MergeTree при экспериментальных транзакциях Keeper не вовлечен; координация ограничена узлом.

Интеграция технологических стеков: Native/HTTP, Apache NiFi, Kafka-коннекторы, материализованные представления

Способы вставки:

Протокол Native - минимальные накладные расходы, высокоскоростная двоичная вставка.
HTTP - универсальный, удобный для сервисов и шлюзов. Поддерживает async_insert и wait_for_async_insert.

Интеграции:

Apache NiFi - потоки ingest с контрольными точками, трансформациями и ретраями. Рекомендуется буферизация и группировка по партициям до отправки в ClickHouse.
Kafka‑коннектор и движок Kafka в ClickHouse - потребление из топиков и доставка в MergeTree через MATERIALIZED VIEW. Важно настроить размер партий и мониторить отставание консьюмера.
Материализованные представления - удобный способ денормализации и предагрегации. При проектировании критичных к консистентности конвейеров необходимо проверять поведение на отказах, поскольку синхронность и атомарность зависят от движков и параметров.

Кейсы применения: телеметрия и IoT, безопасность и логи, e-commerce/AdTech, финансовая аналитика

Телеметрия/IoT: высокая частота событий, естественное партиционирование по времени. Рекомендованы крупные батчи, сортировка по timestamp, асинхронный INSERT через HTTP для микросервисов, где приемлема задержка подтверждения.
Безопасность и логи: устойчивость к всплескам трафика, возможность догоняющих вставок. Полезны MATERIALIZED VIEW для нормализации и извлечения индикаторов. Контролируйте количество частей и глубину merge.
E-commerce/AdTech: микс потоковых кликов/показов и справочных обновлений. Для потоков - буферизация, для справочников - отдельные конвейеры и аккуратные мутации вне пиков.
Финансовая аналитика: повышенные требования к долговечности. Рассмотрите fsync_after_insert, дисциплину крупных батчей, отказ от асинхронной вставки в узловых сегментах, а также детерминированные ключи идемпотентности на стороне источников.

Сектора экономики и типовые требования к вставкам и консистентности

Телеком и IIoT: важна стабильная пропускная способность и прогнозируемая латентность вставки; консистентность «eventually consistent» приемлема для телеметрии, но отчеты требуют срезов с четкой отсечкой по времени.
Финансы и страхование: строгие требования к долговечности и воспроизводимости; рекомендуется fsync_after_insert, тщательное тестирование сценариев восстановления, отказ от неидемпотентных ретраев.
Ритейл и маркетплейсы: многоканочные источники, периодические пики; критична устойчивость к дубликатам при асинхронной вставке, необходимы «зубчатые» окна консистентности для витрин.
AdTech/MarTech: сверхвысокая частота событий, допуск к небольшим расхождениям онлайн; асинхронная вставка и батчирование - норма, консистентность доводится downstream‑обработкой.

Анализ рисков и ограничений: отсутствие полноценных транзакций, ограничения эксперимента, асинхронные вставки, операционные риски Keeper

Отсутствие полноценных транзакций: UPDATE/DELETE/DDL не транзакционны; кросс‑табличные гарантии ограничены.
Ограничения эксперимента: действует только для INSERT и только на нереплицируемых MergeTree; вложенные транзакции недоступны.
Асинхронные вставки: нет дедупликации, возможны дубликаты при ретраях; при wait_for_async_insert=0 отсутствует атомарность на границе клиента.
Keeper/ZooKeeper: для Replicated* отказ или деградация Keeper приводит к росту очередей, задержкам репликации и непредсказуемым латентностям DDL; мониторинг и кластерная эксплуатация критичны.
Части и merge: избыток мелких частей снижает производительность и создает длинный хвост фоновых слияний.

Метрики эффективности и тестирование: латентность и TPS INSERT, глубина слияний, количество частей, ошибки ограничений

Практические рекомендации и анти‑паттерны: размеры батчей, группировка по партициям, ретраи и SLA на вставку

Формируйте батчи не менее 100 000 строк; для высоконагруженных конвейеров - 1-5 млн строк с контролем потребления памяти.
Группируйте данные по ключу партиционирования до вставки; избегайте одномоментной вставки в множество партиций.
При синхронной вставке критичных данных рассматривайте fsync_after_insert; учитывайте увеличение латентности.
Для асинхронного INSERT по HTTP проектируйте идемпотентность: внешние ключи поставки, дедупликация на источнике или downstream‑консолидация.
Избегайте чрезмерных мелких INSERT - это производственный анти‑паттерн, ведущий к «взрыву частей».
Планируйте окна обслуживания для тяжелых мутаций; не совмещайте интенсивные UPDATE/DELETE с пиками ingest.
При использовании MATERIALIZED VIEW валидируйте согласованность цепочки вставок и настраивайте алерты на отставание.

Политики отказоустойчивости: кворумная запись, fsync, стратегии восстановления и мониторинг

Для Replicated* применяйте insert_quorum на критичных путях, понимая влияние на латентность и зависимость от здоровья реплик.
Для локальных MergeTree - уделите внимание надежности носителей, параметрам ФС и fsync_after_insert на чувствительных участках.
Восстановление: документируйте сценарии рестарта во время вставок, проверяйте корректное появление/исчезновение временных частей, автоматизируйте контроль целостности по system.parts.
Мониторинг: лаги merge, рост числа частей на партицию, метрики транзакций и неуспешных вставок, состояние Keeper (для реплицируемых таблиц).

Конкурентный анализ: ClickHouse vs OLTP (PostgreSQL/MySQL) и OLAP (Druid/Pinot/Vertica/BigQuery)

Против OLTP (PostgreSQL/MySQL):
- OLTP обеспечивает полноценные ACID‑транзакции, блокировки строк и серилизуемость при цене на throughput сканирований.
- ClickHouse оптимизирует сканирования и агрегирования, поддерживает частичную ACID‑семантику для INSERT (эксперимент), но не заменяет OLTP для транзакционных рабочих нагрузок.
Против OLAP (Druid/Pinot/Vertica/BigQuery):
- Druid/Pinot ориентированы на низкую латентность запросов по индексированным событиям с ingest через сегменты; транзакционность обычно ограничена окнами и атомностью сегментов.
- Vertica предлагает богатую SQL‑совместимость и мощный колоночный движок, с иными компромиссами по ingest и управлению кластерами.
- BigQuery - серверлесс‑модель с сильной консистентностью на уровне задач загрузки; транзакции в классическом понимании отсутствуют, а атомность достигается на уровне джобов/партиций.
- ClickHouse сочетает высокий throughput и гибкость в on‑prem/локальных установках; экспериментальная транзакционность INSERT добавляет контроль на горячем контуре без утраты OLAP‑производительности.

Дорожная карта и открытые вопросы транзакционности в ClickHouse

Остаются важные направления развития:

Расширение области применимости транзакций за пределы локальных MergeTree.
Кросс‑партиционная атомарность и улучшение согласованности при вставках в несколько партиций.
Глубже интегрированная согласованность для MATERIALIZED VIEW в сложных конвейерах.
Улучшения асинхронных вставок: гарантии доставки, дедупликация, наблюдаемость очередей.
Упрощение эксплуатации при больших масштабах, снижение операционных рисков при координации и репликации.

Заключение

ClickHouse остается высокопроизводительной OLAP‑платформой, где массовые вставки и векторная обработка - первоочередные ценности. Экспериментальная поддержка ACID для INSERT в нереплицируемых MergeTree добавляет недостающие гарантии атомарности, изоляции и долговечности для критичных контуров ingest, но не превращает ClickHouse в OLTP‑СУБД. Архитекторам важно сознательно проектировать сценарии записи: выбирать режимы вставки (синхронный/асинхронный), размер батчей, группировку по партициям, параметры долговечности и мониторинга. Тогда ограничения OLAP станут предсказуемыми, а получаемые гарантии - достаточными для требуемого уровня надежности и согласованности.

Вопрос-Ответ:

Вопрос: Почему в ClickHouse нет полноценных транзакций?
Ответ: Из‑за приоритета OLAP‑архитектуры: колоночное хранение, векторизация, массовые вставки и фоновые слияния плохо сочетаются с «жесткими» ACID для любых DML/DDL.
Вопрос: На что распространяется экспериментальная транзакционность?
Ответ: Только на операции INSERT и только для нереплицируемых таблиц MergeTree; вложенные транзакции не поддерживаются.
Вопрос: Чем отличается синхронная вставка от асинхронной?
Ответ: Синхронная сразу формирует части на диске и подтверждается после записи (и, опционально, fsync). Асинхронная по HTTP буферизует вставку; при wait_for_async_insert=1 клиент ждет завершения, при 0 - нет атомарности на границе запроса.
Вопрос: Обеспечивается ли атомарность при вставке в несколько партиций?
Ответ: Атомарность действует на уровне партиции. Единый INSERT в разные партиции может частично «успеть» по отдельным разделам.
Вопрос: Как усилить долговечность вставки?
Ответ: Включить fsync_after_insert, использовать надежные файловые системы/носители, избегать мелких партий и следить за корректным завершением вставок.
Вопрос: Транзакционны ли мутации (UPDATE/DELETE) в MergeTree?
Ответ: Нет. Мутации применяются по частям асинхронно; во время их выполнения SELECT может видеть смешанное состояние.
Вопрос: Можно ли добиться транзакционности при записи в несколько таблиц?
Ответ: Частично - через MATERIALIZED VIEW, но гарантии зависят от движков и конфигурации; глобальной ACID‑атомарности на несколько таблиц/шардов нет.
Вопрос: Какие анти‑паттерны вставки наиболее опасны?
Ответ: Множество мелких INSERT, вставка одновременно в множество партиций, отсутствие идемпотентности при асинхронных вставках и тяжелые мутации в часы пикового ingest.

← Предыдущая статья

Тонкости агрегации в ClickHouse_ как избежать OOM-ошибки с GROUP BY

Следующая статья →

Энциклопедия ClickHouse