ClickHouse съедает всю память при сложных JOIN — как бороться?

[kirill_backend]

Столкнулись с проблемой на ClickHouse 24.8 (LTS). Есть запрос с тремя JOIN: большая таблица событий (2 млрд строк) джойнится с двумя словарными таблицами (~10M строк каждая). При выполнении запроса ClickHouse съедает 180 GB RAM из доступных 256 GB и либо OOM-кидает, либо начинает свопировать и запрос идёт 40 минут. Без JOIN тот же запрос — 8 секунд. Как правильно настроить JOIN в ClickHouse чтобы не взрывать память?

[ruslan_web]

Классическая проблема с hash join на большом build side. Первое что нужно сделать — явно указать алгоритм: SET join_algorithm = 'partial_merge'; Это переключает на merge join который работает с диском и не держит всё в памяти. Да, будет медленнее чем hash join, но не упадёт. Второй вариант: SET join_algorithm = 'auto'; — ClickHouse сам выберет алгоритм исходя из размера. С версии 23.x это работает достаточно хорошо.

Ещё очень помогает правильный порядок таблиц в JOIN: большая таблица всегда слева (она становится probe side), маленькая справа (build side). ClickHouse не всегда сам переставляет таблицы как PostgreSQL, порядок важен.

[pavel9971]

Для словарных таблиц (10M строк — это как раз словарь) используйте Dictionary в ClickHouse вместо обычного JOIN. Создаёте Dictionary с layout HASHED или FLAT, и вместо JOIN пишете dictGet('my_dict', 'column_name', id). Словарь живёт в памяти отдельно, кэшируется, и запрос превращается из JOIN в простой lookup. У нас это убрало 90% проблем с памятью на аналитических запросах.

[cloudml9635]

max_bytes_in_join и max_rows_in_join — ваши друзья. Поставьте лимит и ClickHouse упадёт с внятной ошибкой вместо того чтобы тихо свопировать:

SET max_bytes_in_join = 10000000000; -- 10 GB
SET join_overflow_mode = 'throw';

Когда будете знать точный размер build side — можно поднять лимит осознанно. Ещё проверьте join_use_nulls, иногда включение добавляет лишний overhead.

[grigory2566]

@anna_qa, В ClickHouse 2026 появился cost-based join reordering и parallel hash join по умолчанию — это реально меняет картину. Если вы на 24.8 LTS — попробуйте обновиться до последнего стабильного (сейчас 25.x). Parallel hash join использует несколько потоков для построения hash table и значительно снижает пиковую память за счёт параллелизма. По нашим тестам на похожей нагрузке память упала с 160 GB до 90 GB просто от обновления.

[ruslan_ml61]

Ещё один вариант для вашего случая: партиционирование запроса вручную. Разбиваете диапазон дат или другой ключ на куски и джойните каждый кусок отдельно через UNION ALL или через приложение. Некрасиво, но работает когда нужно быстрое решение прямо сейчас. Долгосрочно — Dictionary + правильный join_algorithm решают задачу чище.