INSERT Flow

Понимание того, что именно происходит во время INSERT, критически важно для диагностики проблем с производительностью и проектирования эффективных пайплайнов вставки. ClickHouse делает не то, что делают большинство OLTP баз данных.

Шаг за шагом: путь INSERT

Структура Block: единица обработки

Block в ClickHouse — это набор столбцов и счётчик строк. Block — единица обработки в конвейере запросов (query pipeline). Во время INSERT входные данные разбиваются на блоки размером max_insert_block_size (по умолчанию: 1 048 576 строк). Каждый блок создаёт один part на диске.

Один INSERT с 3 000 000 строк при max_insert_block_size=1 048 576:
→ Блок 1 (1 048 576 строк) → part 202401_1_1_0
→ Блок 2 (1 048 576 строк) → part 202401_2_2_0
→ Блок 3 (902 848 строк)   → part 202401_3_3_0
Итого: 3 parts за один INSERT

Atomic rename: гарантия консистентности

Атомарное переименование — критически важная деталь реализации. Вот почему это работает:

Запись идёт в:   /var/lib/clickhouse/data/default/events/tmp_202401_1_1_0/
  event_date.bin   ← пишется
  user_id.bin      ← пишется
  primary.idx      ← пишется
  checksums.txt    ← пишется
  ...

Все файлы записаны → fsync → atomic rename:
tmp_202401_1_1_0/ → 202401_1_1_0/

Теперь part видят запросы.

На уровне файловой системы rename — атомарная операция (POSIX guarantee). Либо rename завершился и part полностью доступен, либо rename не произошёл и part не виден. Нет промежуточного состояния “part пишется”.

Если сервер упадёт во время записи tmp-директории — tmp-директория остаётся на диске, но не видна запросам (имя начинается с tmp_). При следующем запуске ClickHouse очищает такие директории.

Дедупликация блоков

Для реплицированных таблиц (ReplicatedMergeTree) ClickHouse поддерживает дедупликацию блоков:

• insert_deduplicate = 1 (по умолчанию для реплицированных таблиц): ClickHouse хэширует каждый блок данных
• Хеш блока проверяется в ZooKeeper / ClickHouse Keeper
• Дублирующий блок (с тем же хешем) молча игнорируется
• Важно для обеспечения exactly-once семантики при at-least-once доставке из Kafka

-- Проверка статуса дедупликации
SELECT event_time, block_id, rows, source_part_name
FROM system.part_log
WHERE table = 'events' AND event_type = 'NewPart'
ORDER BY event_time DESC
LIMIT 20;

Мониторинг INSERT pipeline

-- Последние created parts
SELECT
    event_time,
    part_name,
    rows,
    size_in_bytes
FROM system.part_log
WHERE table = 'your_table'
  AND event_type = 'NewPart'
ORDER BY event_time DESC
LIMIT 10;

-- Метрики InsertedRows и InsertedBytes
SELECT event, value
FROM system.events
WHERE event IN ('InsertedRows', 'InsertedBytes', 'MergedRows');

Ключевые выводы

1. INSERT-порядок не важен: ClickHouse пересортирует данные по ORDER BY ключу в памяти перед записью.
2. Каждый INSERT = минимум один part: большие INSERTs могут создать несколько parts (при превышении max_insert_block_size).
3. Atomic rename гарантирует консистентность: читатели видят только полные parts — никогда частично написанные.
4. Block: единица обработки. Один блок = один part на диске. max_insert_block_size = 1 048 576 строк по умолчанию.
5. Дедупликация блоков — механизм exactly-once для ReplicatedMergeTree при at-least-once поставках из Kafka.