речь идёт не о полноценном джойне, а выборе строки по айдишнику. на уровне приложения открывается страница сущности, которая лежит в mysql и там же делается поиск по айдишнику в кх

если версия clickhouse 20.5+
то можно профайлинг для памяти включить ненадолго
https://github.com/Slach/clickhouse-flamegraph/blob/master/docker/clickhouse/profiling.xml
и посмотреть куда память тратится

20.4 ) смотрю конфигурации не нахожу про память ничего,  как будто кх просто жрёт всё что есть

кликхауз - некоторые события (мероприятия) в мире, их там очень много с разными параметрами. у нас таблица с обзорами событий, их значительно меньше и хочется иметь ссылку на общий перечень событий

кликхауз - некоторые события (мероприятия) в мире, их там очень много с разными параметрами. у нас таблица с обзорами событий, их значительно меньше и хочется иметь ссылку на общий перечень событий

clickhouse не предназначен для выбора ОДНОЙ СТРОКИ по IDшнику

как минимум выборка WHERE UUID IN ...
и она будет медленная, потому что у вас UUID это рандомная величина
всю таблицу надо будет сканировать
чтобы выбрать

как вы в MySQL узнаете какой UUID должен получиться "в другой сущности"?

а какой порядок кол-ва строк в таблице мероприятий (клик) и какой в таблице обзоров (мускуль)?

ну естественно предполагалось, что эта колонка будет проиндексирована. ну хорошо, а выбор одной строки по 2 колонкам, образующим уник это тоже не корректный юзкейс?

ну мы можем по определённым колонкам выбрать из кх те строки, для которых будет связанная сущность в мускуле и просто по очереди с ними работать

у вас на INSERT вылетает ошибка с аллокацией памяти?

а как вы INSERT делаете? в каком формате?
есть два вида инсертов, стриминговые (память аллоцируется пропорционально кол-ву вставляемых столбцов и дальше потоковый парсинг) и statement (когда перед тем как вставить надо весь SQL распарсить в память)

у вас какой?

Almost all the restrictions only apply to SELECT.

Если не затруднит, можете ссылкой в меня кинуть где об этом почитать?

точнее, значения из /etc/metrika.xml (хотя пишет, что использовал его при негерации)

это тогда плохой инсерт. Он не стримабл.

надо убрать now из инсерта и написать now где-нибудь в дефолтах таблицы.

Плохие инсерты должны влезать в max_query_size он 256кб.

Хорошие инсерты обрабатываются стрим парсером и могут быть любого бесконечного размера, если стрим парсер видит функцию -- например now он переключается на ast парсер , ast парсер ждет конца запроса и складывает запрос в буфер. Буфер по умолчанию -- 256kb