Производительность запросов ClickHouse

Вставка батчами: считаем пороги

Пороги в ClickHouse не абстрактные, их видно в настройках. При 1000 активных кусков в партиции сервер начинает искусственно притормаживать вставки - это parts_to_delay_insert. При 3000 он отказывает с ошибкой too many parts - это parts_to_throw_insert. Плюс общий потолок 100 000 кусков на таблицу.

Теперь арифметика. Бэкенд пишет по строке, двести раз в секунду - это двести кусков в секунду. Тысяча наберётся за пять секунд, три тысячи - за пятнадцать. Фоновые мержи столько склеить не успевают физически, поэтому вопрос не в том, случится ли авария, а через сколько минут.

Норма - батчи от десятков тысяч строк с частотой примерно раз в секунду. Тогда кусков рождаются единицы в секунду, и мержи справляются с большим запасом. Заодно вставка становится дешевле: сортировка и сжатие на большом блоке эффективнее, чем на одной строке.

// Если поток мелких событий неизбежен, есть два пути. Буфер перед базой - очередь вроде Kafka или собственный батчер в приложении. Либо async_insert: сервер копит блоки сам, но меняется семантика подтверждения - по умолчанию клиент получает ответ до того, как данные записаны, и это решение надо принимать осознанно, а не по умолчанию.

too many parts

отказ вставки при 3000 активных кусков в партиции: мержи не успевают за мелкими вставками

ORDER BY и типы - решения навсегда

Ключ сортировки выбирается один раз: поменять его у существующей таблицы нельзя, только создать новую и перелить данные. На петабайте это событие масштаба проекта, поэтому «потом переделаем» не наступает никогда.

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

Типы решают не меньше. Измерено: миллион строк из трёх повторяющихся значений занимает 31,9 КиБ обычной строкой и 14,0 КиБ в LowCardinality - в 2,3 раза меньше, потому что вместо текста хранятся номера в словаре. Дальше по мелочи, которая складывается: узкие числа вместо Int64 везде, DateTime вместо строковой даты, Enum вместо текстовых статусов.

// Кодеки сжатия задаются по колонке и подбираются под её профиль: Delta и DoubleDelta для времени и монотонных счётчиков, ZSTD вместо LZ4 там, где место дороже процессорного времени. Это уже тонкая настройка, но на больших колонках она даёт разы.

CREATE TABLE events (
  tenant   LowCardinality(String),
  event    LowCardinality(String),
  ts       DateTime CODEC(Delta, ZSTD),
  user_id  UInt64,
  value    UInt32
) ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
ORDER BY (tenant, event, ts);
-- фильтры по арендатору и типу отсекают гранулы, время идёт последним

LowCardinality

словарное кодирование повторяющихся строк: вместо текста хранится номер значения

Диагностика: три взгляда вместо гадания

Фраза «ClickHouse медленный» без трёх конкретных цифр ничего не значит. Первая - system.query_log: сколько строк и байт запрос реально прочитал. Обычно там сразу видно, что вместо ожидаемых миллионов прочитаны миллиарды.

Вторая - EXPLAIN indexes=1 и строчка Granules: сколько гранул отсеклось. 12 из 244 - индекс работает, 244 из 244 - не работает, и дальше надо разбираться с ключом и фильтром.

Третья - system.parts: сколько активных кусков у таблицы. Рост числа кусков - ранний сигнал, что вставка организована неправильно, и он появляется задолго до ошибки too many parts.

// Вторичные индексы по пропуску данных (minmax, set, bloom_filter) существуют, но это заплатка для точечных фильтров вне ключа, а не замена правильному ORDER BY. Сначала ключ, потом они. И отдельно - лимиты на пользователей (max_memory_usage, max_execution_time): один аналитик со звёздочкой по всей истории не должен ронять кластер.

Как отвечать: «Как правильно организовать вставку данных в ClickHouse?»

Батчами, от десятков тысяч строк, с частотой около раза в секунду. Причина в устройстве: каждая вставка рождает отдельный кусок на диске, при тысяче кусков в партиции сервер начинает притормаживать вставки, при трёх тысячах отказывает с ошибкой too many parts. Если писать по строке двести раз в секунду, три тысячи кусков набегут за пятнадцать секунд, и мержи за этим не угонятся физически. Если источник - поток мелких событий, ставлю перед базой буфер: очередь или батчер в приложении. Либо включаю async_insert, но осознанно, потому что у него другая семантика подтверждения - клиент получает ответ раньше, чем данные легли. И вставляю в правильно спроектированную таблицу: ключ сортировки под будущие фильтры и экономные типы, потому что это решения, которые потом меняются только пересозданием таблицы. Слежу за числом кусков в system.parts - это ранний сигнал, что вставка организована неверно.

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

На чём валят

• −Вставлять по одной строке из приложения: три тысячи кусков и остановка записи набегают за секунды.
• −Включить async_insert, не разобравшись, что подтверждение вставки теперь означает другое.
• −Держать String для статусов и дат вместо LowCardinality, Enum и DateTime - двукратная плата на каждом чтении.
• −Ставить ключ сортировки по времени первым, когда все запросы фильтруют по арендатору.
• −Вешать индексы пропуска на все колонки вместо продуманного ORDER BY.
• −Обещать «пересоздадим таблицу с новым ключом потом»: на реальном объёме это уже никогда.