Операции 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 ТБ.

Ошибка слишком большого количества частей

Маленькие частые вставки создают проблемы с производительностью. Сообщество выявило, что скорость вставки выше 10 в секунду часто вызывает ошибки "слишком много частей", потому что ClickHouse не может достаточно быстро объединять части.

Решения:

• Пакетируйте данные, используя пороги в 30 секунд или 200 МБ
• Включите async_insert для автоматической пакетной обработки
• Используйте таблицы-буферы для пакетной обработки на стороне сервера
• Настройте 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; -- 1GB threshold

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

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

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

• Выбор стратегии вставки

Настройка распределенной таблицы

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

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

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

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

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

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

• Пользовательский ключ партиционирования

Быстрая справка

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

Видеоресурсы

• 10 уроков по эксплуатации ClickHouse
• Быстрая, параллельная и последовательная асинхронная вставка в ClickHouse