Подскажите пжлста, а как нужно изменить реляционную схему цепочек событий

для удобной работы с ней в кх?

Есть события разных типов A B C D, у каждого есть свой UUID и UUID отцовского события. Т.е в табличке EventC есть поле ID и eventBID. У каждого события есть свои собственные как high так и low cardinality параметры, ссылки на сущности из MySQL и конечно же DateTime. Вся связанная пачка событий A -> B -> C -> D близка друг к дружке по времени, окно обычно минут 10, в редких случаях - час.

Количество событий - XXкк в день A, Xкк в день B, XXXк в день C и так далее.

Запросы требуется делать произвольные в реальном времени - сагрегировать события D по С.someField и отфильтровать по B.otherField. Делает запросы не техническая команда через Metabase накликивая фильтры\агрегации мышкой. Metabase делает в таких случаях просто запрос с джойном.

И конечно же вся петрушка отрабатывает за приемлимые 2-30 sec на график, покуда с правой стороны джойна не окажется события A или B, которых слишком много, и запроос просто отваливаетсся по памяти. Если бы там были бы независимые индексы по ID и по DateTime все бы летало. Но как я понимаю у КХ не такая парадигма архитектуры.

Следовательно эта схема под КХ должна готовиться по другому, но пока не очень понятно как. Подскажите?

вобще-то это экстремизм давать юзерам возможность делать такие джойны по исходным данным. В общем случае стоит подумать о звезде кимбала (https://en.wikipedia.org/wiki/Star_schema) - тут всегда сначала делается аггрегация по фактам, и только потом джойн по общим измерениям. В вашем случае (когда вы используете термин события), может быть имеет смысл собрать все 4 таблицы в одну, пусть даже с 1000 разреженных колонок, и вот по ней уже дать юзерам возможость делать свободные запросы. Если говорить о КХ, то тут принята именно такая широкая и длинная таблица. Одна. Можно со словарями, но по возможности без джойнов.

убрать джойны? можно mysql в словарь и поля в таблицы добавить как alias dictGet

Да, вы правы, там сейчас как раз по большей части эта звезда и есть и проблемма возникает на джойнее табличек A&B из-за их размеров и непонимание, как заиметь индекс по ID имея еще и order by по дате. И если нужна огромная широкая таблица, может ли ее CH строить сам через MV? Это может делать условный сервис аналатики, переодически пиная селект с этим джойном на фиксированном окне времени, но можноо ли проще?

КХ не использует индексы при join

Да, действительно, вы правы. Вопрос скорее как получить быстрый джойн в принципе здесь и если это не возможно, то как слепливать все в большую таблицу на стороне CH в фоне

я уже писал сегодня. убрать джойны? можно mysql в словарь и поля в таблицы добавить как alias dictGet понимаете о чем я?

"по большей части" - немного пугает. В классической звезде вы никогда не делаете джойн между неагреггированными таблицами фактов. Только схлопывание их до разумной размерности, и только потом джойн. Собрать широкую таблицу независимыми инсертами и MV можно заполняя недостающие поля Null. При аггрегации Null не учитываются. Null обладает своим оверхедом, но вы заменяете join на group by, что может вам помочь (а может и нет). Зато такую табличку потом можно будет ускорить предаггрегациями на основе projections. Там даже оптимизатор запросов какой-никакой есть. Другой подход - запихнуть все относительно маленькие таблицы в словари (разместить их в памяти если влезут), и никогда не использовать последнюю большую таблицу в правом джойне (и вобще никаком джойне). Только нестандартный dictGet* Однако тут ваш BI скорее всего споткнется. Наверное можно попробовать джойнить словари как таблицы - должно работать быстро, но я так не пробовал - не знаю какие там будут подводные камни.

Спасибо! По большей части - имелось ввиду что оно WiP, а не что так и должно быть)) Попробуем слепливать табличку. Мне кажется проблема вытекает из-за сопротивление смены парадигмы с реляционной и я пытаюсь понять, а как оно может там быть иначе. С широкой таблицой не поонятно как бизнесу ворочить данными как ему всдумается, только просить тех команду делать графики вручную