ClickHouse 25.3 валится по OOM на джойнах, я уже все настройки перекрутил

[ralfalfa]

наболело. Аналитика: events 1.2 млрд строк, users 40 млн. Любой join больше чем на пару дней данных кладет сервер. 64 ГБ RAM, max_memory_usage 50 ГБ, max_bytes_before_external_group_by выставлен, join_algorithm пробовал hash, partial_merge, grace_hash. grace_hash хотя бы не падает, но запрос идет 11 минут вместо ожидаемых секунд 40. Сервер один, шардов нет, версия 25.3 LTS. Что я делаю не так, или кликхаус правда настолько не умеет в джойны?

[golang_nerd]

@ralfalfa, кх не умеет в джойны, это архитектура такая, смиритесь. правая таблица тянется в память целиком. 40 млн юзеров со всеми колонками это сколько в гигабайтах? в подзапросе правой части оставь только id и две нужные колонки, у половины страдальцев OOM лечится одним этим

[debian91]

Вынеси users в dictionary и замени join на dictGet. Для справочника юзеров это ровно целевой кейс: layout hashed или sparse_hashed, обновление по таймеру раз в N минут. 40 млн ключей с парой атрибутов влезут гигов в 6-8. Запросы по events с dictGet летают так, как join не полетит никогда. Мы так с 9 минут до 14 секунд ужались на похожих объемах.

[Omoto]

@golang_nerd, денормализуй и не мучайся. да, противно, да, events распухнет процентов на 30. зато никаких джойнов вообще. кликхаус так задуман, это не постгрес, хватит тащить в него реляционные привычки

[rburr]

@debian91, а оперативки на сервере сколько?

[ansible777]

выше человек спрашивает про память, ТС же написал, 64 гб, читаем тред. по делу: обновись с 25.3 на свежий LTS, там автоматический выбор join algorithm допилили и full sorting merge стал приличнее. но честно, на одной ноде с 64 гб ты из тюнинга больше не выжмешь. либо словари, либо денормализация, либо доткни еще 64 гб, память сейчас не такая конская по деньгам, как в 23-м была