Вставка больших объёмов: батчи, а не строки

Таблицы спроектированы: типы подобраны, ключ сортировки выбран, партиции по месяцу. Пора наливать данные. Приложение «Гонца» шлёт событие на каждое открытие экрана, поиск и нажатие, сотни событий в секунду. Самое естественное решение: пришло событие, сделай INSERT. Для PostgreSQL это нормально. Для ClickHouse это самая частая ошибка новичка, и сейчас станет понятно почему.

Вспомним части

В уроке про MergeTree мы видели: каждая вставка пишет на диск новую часть, отдельную папку с файлами колонок. Фоновые слияния собирают мелкие части в крупные.

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

Это как с почтой. Можно отправлять сто писем в день по одному, каждое в своём конверте, с марками и походом на почту. А можно складывать письма в коробку и раз в день отправлять одну посылку. Содержимое то же, а работы у почты в сто раз меньше.

Что будет, если не послушаться

ClickHouse защищается от потока мелких частей. Пока в одной партиции копится больше 1000 активных частей, сервер начинает искусственно замедлять каждую вставку, давая слияниям догнать. А когда частей становится больше 3000, вставка падает с ошибкой:

Code: 252. DB::Exception: Too many parts (3001 with average size of 1.12 KiB)
in table 'default.events'. Merges are processing significantly slower than inserts.
(TOO_MANY_PARTS)

Это одна из самых известных ошибок ClickHouse. Она означает не поломку, а неправильный способ загрузки.

Правило батча

Документация ClickHouse даёт простой ориентир:

• в одной вставке не меньше тысячи строк, а лучше от 10 до 100 тысяч;
• не больше одной вставки в секунду в таблицу.

Батч собирают на стороне того, кто пишет. Сервис событий копит строки в памяти и раз в секунду или по достижении 50 тысяч строк отправляет их одним INSERT. Часто между приложением и ClickHouse стоит очередь Kafka: приложение пишет туда события по одному, а отдельный загрузчик читает их пачками. Это мы увидим в уроке про интеграции.