Ребята, всем привет. Тут столкнулись с проблемой потребления большого к-ва памяти

при join таблиц.
Есть 2 большие ReplacingMergeTree таблицы с партициями по месяцм. Эти таблицы джойнятся во вьюхе(left join).

Когда пытаешься селектить данные из вьюхи с date between, кликхаус выбирает все данные в память, джойнит, а потом уже фильтрует данные по дейт ренджу. Все согласно документации:
При запуске JOIN, отсутствует оптимизация порядка выполнения по отношению к другим стадиям запроса. Соединение (поиск в «правой» таблице) выполняется до фильтрации в WHERE и до агрегации. Чтобы явно задать порядок вычислений, рекомендуется выполнять JOIN подзапроса с подзапросом.

Но такой подход потребляет очень большое к-во оперативной памяти.

Вопрос: в будущем планируется ли оптимизация планировщика запросов, чтобы он добалял фильтрацию в таблицы, которые джойнятся?

На сколько это важная и сложная задача для контрибьютеров clickhouse?

Если известны условия фильтрации, то можно (и лучше) сразу вместо join table2 делать join (select field1, field2 from table2 where ...).

Спасибо. Но у нас другой кейс, очень нужно сделать вьюху, в которой будут джойниться таблицы, а потом менять условия селекта

Если допустимо отставание в актуальности данных, можно ещё вместо фильтрации сделать таблицу типа Set/Join, обновлять её по мере необходимости и работать с ней вместо джойна целой таблицы. Мне для обновления статистики раз в сутки такой вариант подошёл и сэкономил очень много времени.

https://kb.altinity.com/altinity-kb-queries-and-syntax/altinity-kb-parameterized-views

у нас около 70тыс таблиц)

а откуда они взялись эти 70 тыщ таблиц? это из MySQL один в один перетекли данные? зачем так вообще?

Выглядит как хороший вариант, спасибо. Но как такой вариант будет работать, если мы подключим BI tool типа Tableau или Looker? Будет ли вообще работать, т.к. SQL выглядит кастомным

Храним репорты клиентов, много клиентов у каждого много репортов

Ну, это к сожалению уже другой вопрос :)

Сейчас задумываемся делать кастомные трансформации через DBT и визуализировать эти трансформации в BI Tool

нельзя хранить в одной общей таблице с client id в PK? и сделать RBAC и row policy чтобы вытаскивать только то что можно...

У каждого отчета отдельная структура и гранулярность данных

Насколько эта структура отлична друг от друга?

насколько я понимаю условия которые указываются в WHERE у вьюхи накладываются на результаты уже в самом конце, а не пробрасываются внутрь вьюхи. так что даже если сделают какую-то оптимизацию для джойнов, то при построении вьюхи сначала загрузятся все данные, а потом уже в самом конце отфильтруются за один день.

сильно различаются, в одном репорте может быть 30 колонок, в другом 1000 Зависит от дата соурса и к-ва динамических метрик в нем настроенных

Я б на вашем месте вначале попробовал бы узнать наличие дублей (не помню, вы говорили какой движок у таблиц или нет), это раз. Динамические метрики, но суть их одна и та же? Вынести в таблицу и переделать схему хранения

Такая же проблема будет, если просто взять SQL вьюхи и дописать where в конце. Вьюха - это же просто сохраненный SQL. Я это к тому, что бд должна найти оптимальный план запроса, чтобы эффективно достать данные.

У наз ReplacingMergeTree, дублей либо нет, либо их совсем немного. Что вы имеете ввиду Вынести в таблицу и переделать схему хранения?

В прямом смысле, рассмотреть с точки зрения бизнес-логики верны ли ваши схемы, и можно ли информацию, там имеющуюся, переделать. ReplacingMergeTree? Ну хз, если задан неправильный ORDER BY key, да даже при правильно заданном, юзер может искать пробовать одну и ту же инфу

С точки зрения бизнес логики и здравого смысла у нас правильная схема данных. Все данные в одну таблицу запихать непоулчится. И это не решает вопрос с неоптимальным планом queery при join таблиц

Ммм, я б поспорил,да не буду. Я б задался вопросом: а правильно ли выбор пал на Кликхаус в вашем случае? Но менять что-либо поздно. :)

Ну не прям поздно) просто очень дорого)

важная, только делать особо некому