Перейти к основному содержанию
Перейти к основному содержанию

Операции ClickHouse: практические советы по отладке от сообщества

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

Основные системные таблицы​

Эти системные таблицы являются важнейшими для отладки в продакшене:

system.errors​

Показывает все активные ошибки в вашем экземпляре ClickHouse.

SELECT name, value, changed 
FROM system.errors 
WHERE value > 0 
ORDER BY value DESC;

system.replicas​

Содержит информацию о задержке и статусе репликации для мониторинга состояния кластера.

SELECT database, table, replica_name, absolute_delay, queue_size, inserts_in_queue
FROM system.replicas 
WHERE absolute_delay > 60
ORDER BY absolute_delay DESC;

system.replication_queue​

Предоставляет подробные сведения для диагностики проблем с репликацией.

SELECT database, table, replica_name, position, type, create_time, last_exception
FROM system.replication_queue 
WHERE last_exception != ''
ORDER BY create_time DESC;

system.merges​

Отображает текущие операции слияния и может помочь выявить зависшие процессы.

SELECT database, table, elapsed, progress, is_mutation, total_size_bytes_compressed
FROM system.merges 
ORDER BY elapsed DESC;

system.parts​

Ключевой для мониторинга количества частей и выявления проблем с фрагментацией.

SELECT database, table, count() as part_count
FROM system.parts 
WHERE active = 1
GROUP BY database, table
ORDER BY count() DESC;

Распространённые проблемы в продакшене​

Проблемы с дисковым пространством​

Исчерпание дискового пространства в реплицируемых конфигурациях приводит к каскадным проблемам. Когда на одном узле заканчивается место, другие узлы продолжают пытаться синхронизироваться с ним, что вызывает всплески сетевого трафика и запутанные симптомы. Один из участников сообщества потратил 4 часа на отладку того, что оказалось просто нехваткой дискового пространства. Ознакомьтесь с этим запросом, чтобы отслеживать использование диска в конкретном кластере.

Пользователям AWS следует учитывать, что стандартные универсальные EBS-тома имеют ограничение 16 ТБ.

Ошибка "too many parts"​

Частые мелкие вставки создают проблемы с производительностью. Сообщество отмечает, что скорость вставок более 10 в секунду часто приводит к ошибкам "too many parts", поскольку ClickHouse не успевает достаточно быстро сливать части.

Решения:

  • Группировать данные с порогами в 30 секунд или 200 МБ
  • Включить async_insert для автоматического формирования батчей
  • Использовать buffer-таблицы для батчинга на стороне сервера
  • Настроить Kafka для контролируемого размера батчей

Официальная рекомендация: минимум 1 000 строк на одну вставку, в идеале от 10 000 до 100 000.

Проблемы с некорректными временными метками​

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

Риски операций ALTER​

Крупные операции ALTER над многотерабайтными таблицами могут потреблять значительные ресурсы и потенциально блокировать базы данных. В одном примере из сообщества изменение типа Integer на Float для 14 ТБ данных заблокировало всю базу данных и потребовало восстановления из резервных копий.

Мониторинг ресурсоёмких мутаций:

SELECT database, table, mutation_id, command, parts_to_do, is_done
FROM system.mutations 
WHERE is_done = 0;

Сначала тестируйте изменения схемы на небольших наборах данных.

Память и производительность​

Внешняя агрегация​

Включите внешнюю агрегацию для операций с большим потреблением памяти. Она работает медленнее, но предотвращает аварийные завершения из-за нехватки памяти за счёт выгрузки данных на диск. Это можно сделать с помощью настройки max_bytes_before_external_group_by, которая поможет избежать ошибок «недостаточно памяти» при больших операциях GROUP BY. Подробнее об этой настройке можно узнать здесь.

SELECT 
    column1,
    column2,
    COUNT(*) as count,
    SUM(value) as total
FROM large_table
GROUP BY column1, column2
SETTINGS max_bytes_before_external_group_by = 1000000000; -- порог 1 ГБ

Подробности об асинхронной вставке​

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

Связанные документы

Конфигурация распределённой таблицы​

По умолчанию распределённые таблицы используют однопоточные вставки. Включите insert_distributed_sync для параллельной обработки и немедленной отправки данных на шарды.

Отслеживайте накопление временных данных при использовании распределённых таблиц.

Пороговые значения для мониторинга производительности​

Рекомендуемые сообществом пороговые значения мониторинга:

  • Частей на партицию: желательно менее 100
  • Задержанные вставки: должны оставаться на нуле
  • Скорость вставки: ограничьте примерно до 1 операции в секунду для оптимальной производительности

Связанные документы

Краткая справка​

ПроблемаОбнаружениеРешение
Дисковое пространствоПроверить суммарный объём байт в system.partsОтслеживать использование, планировать масштабирование
Слишком много частейПосчитать количество частей на таблицуПакетные вставки, включить async_insert
Задержка репликацииПроверить задержку в system.replicasОтслеживать состояние сети, перезапустить реплики
Некорректные данныеПроверить даты партицийРеализовать проверку меток времени
Застрявшие мутацииПроверить статус в system.mutationsСначала протестировать на небольшом объёме данных

Видео-материалы​