Ключевые настройки производительности

Среди сотен настроек ClickHouse есть четыре, которые напрямую определяют поведение запросов в production: max_threads, join_algorithm, distributed_product_mode, optimize_move_to_prewhere. Каждая из них влияет на разные аспекты выполнения запроса — от параллелизма чтения до правильности результатов в распределённых системах.

Обзор четырёх ключевых настроек

max_threads: параллелизм чтения

max_threads управляет числом потоков, которые ClickHouse использует для параллельного чтения данных и обработки. По умолчанию равен числу CPU-ядер на сервере.

-- Проверить текущее значение
SELECT value FROM system.settings WHERE name = 'max_threads';

-- Установить явное значение для запроса
SET max_threads = 8;

SELECT
    user_id,
    count() AS events
FROM large_events_table
GROUP BY user_id;

Значение max_threads отражается в EXPLAIN PIPELINE как × N:

EXPLAIN PIPELINE
SELECT count() FROM large_table;

-- Вывод: MergeTreeSelect × 8 означает, что данные читаются 8 потоками
-- (ReadFromMergeTree)
-- MergeTreeSelect(pool: ReadPoolParallelizeOutput, algorithm: Thread) × 8

Смотрите также: Module 06 урок 02 для детального разбора EXPLAIN PIPELINE и интерпретации параллелизма.

Когда уменьшать max_threads

В многопользовательских и многозадачных системах один запрос не должен монополизировать все CPU:

-- Сервер с 32 CPU-ядрами, 10 concurrent пользователей
-- Разумное значение: 32 / 10 ~ 3-4 потока на запрос
SET max_threads = 4;

join_algorithm: выбор алгоритма JOIN

join_algorithm определяет, каким способом ClickHouse выполняет JOIN-операции. Выбор алгоритма критически влияет на потребление памяти и производительность.

-- По умолчанию: hash join (правая таблица целиком в RAM)
SET join_algorithm = 'hash';

-- Для больших таблиц с spill на диск: grace_hash
SET join_algorithm = 'grace_hash';

SELECT l.user_id, r.country_name
FROM user_events l
JOIN countries r ON l.country_code = r.code;

Сравнение алгоритмов JOIN

Для детального разбора каждого алгоритма, включая примеры и критерии выбора, смотрите Module 06 урок 04.

distributed_product_mode: подзапросы в Distributed таблицах

При работе с Distributed таблицами в кластерном ClickHouse подзапросы, ссылающиеся на Distributed таблицы, требуют явного указания поведения через distributed_product_mode.

-- Попытка подзапроса с Distributed таблицей (по умолчанию выдаст ошибку)
SELECT *
FROM distributed_events
WHERE user_id IN (
    SELECT user_id FROM distributed_users WHERE country = 'RU'
);
-- Ошибка при distributed_product_mode = 'deny'

-- Решение: переключить на global (рекомендовано для большинства случаев)
SET distributed_product_mode = 'global';

Значения distributed_product_mode

-- Режим global: подзапрос выполняется на каждом шарде,
-- результаты объединяются и бродкастятся для основного JOIN
SET distributed_product_mode = 'global';

SELECT e.user_id, e.event_type
FROM distributed_events e
WHERE e.user_id IN (
    SELECT user_id FROM distributed_vip_users WHERE plan = 'premium'
);

optimize_move_to_prewhere: автоматический PREWHERE

optimize_move_to_prewhere (по умолчанию 1 — включён) автоматически переносит подходящие условия из WHERE в PREWHERE. PREWHERE — механизм ClickHouse, который читает только колонки-фильтры для первичной отсечки гранул, уменьшая объём I/O.

-- optimize_move_to_prewhere = 1 (по умолчанию)
-- ClickHouse автоматически оптимизирует этот запрос:
SELECT user_id, revenue
FROM orders
WHERE status = 'completed'
  AND region = 'EU';
-- ClickHouse может перенести 'status = completed' в PREWHERE автоматически

-- Явное отключение (редко нужно):
SET optimize_move_to_prewhere = 0;

Для детального понимания механизма PREWHERE и критериев автоматического переноса условий смотрите Module 06 урок 03.

Когда выключать optimize_move_to_prewhere:

• Сложные WHERE с побочными эффектами (крайне редкий случай)
• Диагностика: когда нужно проверить поведение без автоматической оптимизации

Сводная таблица

Ключевые выводы

1. max_threads по умолчанию равен числу CPU-ядер. В многопользовательских системах уменьшайте его до CPU_cores / max_concurrent_users, чтобы избежать CPU contention.
2. join_algorithm = 'grace_hash' — безопасный выбор для JOIN на таблицах неизвестного размера: spill-to-disk предотвращает OOM при превышении RAM.
3. distributed_product_mode = 'global' — корректный выбор для cross-shard подзапросов. deny (дефолт) защищает от случайных неполных результатов.
4. optimize_move_to_prewhere = 1 (дефолт) автоматически оптимизирует WHERE через PREWHERE. Выключать только для диагностики или при редких побочных эффектах.
5. Эти настройки применяются на уровне запроса через SET или как SETTINGS в конце SELECT — без перезапуска сервера.