</>
halfcoder

Гайды

Настройка и оптимизация ClickHouse

Память и max_threads, query_log, TTL и партиции, кодеки сжатия, репликация и обслуживание parts.

~12 мин чтения

Базы данныхClickHouseПроизводительностьOLAP

Настройка и оптимизация ClickHouse

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

1. Где конфигурация

Обычно /etc/clickhouse-server/config.xml и users.xml. В Docker — переменные или монтируемые файлы.

Важно: память (max_memory_usage в профиле), потоки (max_threads), дефолты MergeTree.

2. Память и тяжёлые запросы

sql
SET max_memory_usage = 10000000000;

SET max_bytes_before_external_group_by = 536870912;
SET max_bytes_before_external_sort = 536870912;

Симптом нехватки памяти — отмена запроса или исключения; смотрите логи и peak memory.

3. max_threads

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

4. Профилирование

sql
EXPLAIN PIPELINE SELECT ...;

EXPLAIN indexes = 1
SELECT count()
FROM analytics.events
WHERE event_date >= today() - 1;

EXPLAIN indexes = 1 (для MergeTree) показывает цепочку partition / primary key / skip индексов и сколько parts/granules отсечено — быстрый способ увидеть полный скан и неудачный префикс ORDER BY. На очень новых версиях сверьтесь с докой: часть настроек анализатора может влиять на вывод.

system.query_log (если включён):

sql
SELECT
    query_duration_ms,
    read_rows,
    read_bytes,
    memory_usage,
    query
FROM system.query_log
WHERE type = 'QueryFinish'
  AND event_time > now() - INTERVAL 1 HOUR
ORDER BY query_duration_ms DESC
LIMIT 20;

5. Схема таблицы

ORDER BY

Сужайте префикс ORDER BY под реальные WHERE — меньше чтения по гранулам primary key.

PARTITION BY

toYYYYMM(date) — классика для временных рядов. Слишком мелкие партиции → много метаданных; слишком крупные — хуже TTL.

TTL

sql
ALTER TABLE analytics.events
MODIFY TTL event_date + INTERVAL 180 DAY DELETE;

Следите за фоновыми мутациями.

6. Кодеки сжатия

sql
CREATE TABLE example (
    id UInt64 CODEC(Delta, ZSTD(1)),
    payload String CODEC(ZSTD(3))
) ENGINE = MergeTree() ORDER BY id;

Выше ZSTD → лучше сжатие, больше CPU при чтении.

7. Вставка

Батчи на приложении остаются главным рычагом. Параметры вроде async_insert (если поддерживается версией) — см. доки.

Projections (материализованные структуры внутри таблицы) ускоряют альтернативные срезы GROUP BY без дублирования полной копии данных — полезно, когда один факт-табельный поток читают и по user_id, и по event_type, а ORDER BY выбрать один префикс сложно.

8. Репликация и кластер (кратко)

ReplicatedMergeTree + ZooKeeper или ClickHouse Keeper. ON CLUSTER для DDL. Distributed — маршрутизация по шардам.

9. Обслуживание

  • system.parts — число parts; много мелких → OPTIMIZE ... FINAL осторожно на больших таблицах.
  • Мутации ALTER UPDATE/DELETE — асинхронны и тяжелы; предпочитайте партиции.
  • Бэкапы: FREEZE, снимки диска, облако.

Read-only реплика для тяжёлых ad-hoc отчётов снижает влияние на основной инжест; синхронизация задержки (system.replicas) должна быть в дашбордах.

10. Профили в users.xml и квоты

Разводите аналитиков и сервисный инжест разными профилями (readonly, лимиты max_execution_time, readonly = 2 только на чтение, свои max_memory_usage). Quotas ограничивают число запросов в окне — защита от случайного скрипта в Jupyter. Имена настроек уточняйте в доке вашей версии — синтаксис XML-профилей эволюционирует.

11. Чек-лист

  • Вставки батчами, контроль parts
  • ORDER BY согласован с фильтрами
  • Память и spill под железо
  • query_log для поиска outlier'ов
  • TTL и партиции для жизненного цикла данных
  • Отдельные профили для отчётов и для приложений

См. также