Merge Scheduling

Parts — immutable. ClickHouse никогда не изменяет уже записанный part. Вместо этого фоновый планировщик слияний непрерывно объединяет мелкие parts в более крупные. Понять, когда и почему происходят слияния — значит научиться диагностировать ошибки “too many parts” и проектировать эффективные пайплайны вставки.

Почему слияния необходимы

Без слияний каждый INSERT создаёт крошечный part. 1000 INSERTs — 1000 директорий на диске. Запрос SELECT count() должен открыть все 1000 parts, прочитать файлы из каждого, объединить результаты. Производительность деградирует линейно.

Фоновое слияние решает проблему: после нескольких INSERT появившиеся мелкие parts объединяются в один крупный. Вместо 1000 files operations — одна. Запросы видят меньше parts — I/O меньше, latency ниже.

Алгоритм планировщика слияний

Планировщик работает как фоновый поток в BackgroundProcessingPool. Он непрерывно сканирует активные parts каждой партиции и принимает решение о слиянии:

Ключевые параметры планировщика:

Процесс слияния: шаг за шагом

После выбора кандидатов фоновая задача выполняет слияние в 6 шагов:

1. Выбор частей-кандидатов — смежные по block number parts в одной партиции
2. Чтение всех кандидатов — параллельное чтение .bin файлов каждой части
3. Merge-sort по ORDER BY ключу — объединение в один отсортированный поток строк
4. Запись нового merged part — новый level = max(уровней кандидатов) + 1
5. Atomic swap — новый part становится активным, старые помечаются inactive
6. Удаление старых parts — когда ref count = 0 (все in-flight запросы завершены)

До слияния:  202401_1_1_0 + 202401_2_2_0 + 202401_3_3_0
После:       202401_1_3_1   ← level=1 (первое слияние)

Ещё одно:   202401_1_3_1 + 202401_4_5_1
Результат:  202401_1_5_2   ← level=2 (второе слияние)

Старые parts физически не удаляются мгновенно: они остаются на диске пока активны in-flight запросы, которые открыли их снапшот до swap. Только когда последний такой запрос завершается — части удаляются.

OPTIMIZE TABLE: ручное управление слияниями

OPTIMIZE TABLE позволяет вручную инициировать слияния:

-- Запустить один цикл слияния (необязательно объединит все parts)
OPTIMIZE TABLE events;

-- Принудительно объединить все parts всех партиций в один part на партицию
OPTIMIZE TABLE events FINAL;

-- Принудительное слияние конкретной партиции
OPTIMIZE TABLE events PARTITION '202401' FINAL;

-- Текущие слияния и их прогресс
SELECT * FROM system.merges;

-- Статистика merge-событий с момента запуска
SELECT event, value
FROM system.events
WHERE event LIKE '%Merge%';

-- Число активных parts по таблицам
SELECT table, count() AS parts, sum(rows) AS rows
FROM system.parts
WHERE active = 1
GROUP BY table
ORDER BY parts DESC;

Диагностика “too many parts”

Ошибка DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts означает, что планировщик слияний не успевает за темпом INSERT.

Типичные причины:

1. Слишком мелкие INSERT — каждый INSERT с 1-100 строками создаёт отдельный part
2. Перегруженный background pool — другие операции (мутации, TTL) занимают потоки
3. Большие партиции — PARTITION BY toYYYYMMDD(dt) при большом трафике создаёт много parts в одной дате

Диагностика:

-- Parts по партициям (где больше всего parts?)
SELECT
    partition,
    count() AS part_count,
    sum(rows) AS total_rows
FROM system.parts
WHERE table = 'events' AND active = 1
GROUP BY partition
ORDER BY part_count DESC
LIMIT 20;

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

1. Parts immutable: ClickHouse никогда не изменяет записанный part. Слияние создаёт новый part и удаляет старые.
2. Merge scheduler: фоновый поток в BackgroundProcessingPool, балансирует число parts с затратами на слияние.
3. max_parts_in_total = 100 000: превышение блокирует INSERT. Пороги parts_to_delay_insert и parts_to_throw_insert работают на уровне партиции.
4. Level в имени part: монотонно растёт с каждым слиянием. level=0 — свежий INSERT, level=2 — прошёл два слияния.
5. OPTIMIZE TABLE FINAL: только для обслуживания. В production write path — никогда.