Comments 16
А как делать связь многие ко многим?
вы можете назвать СУБД где выбор из нескольких соединенных таблиц быстрее чем выбор из одной таблицы с заранее объединенными там данными из других таблиц особенно в распределенной среде с шардами?
Вы ясно понимаете отличия OLAP подхода от OLTP?
В любом случае, это хорошо, что вы открываете для себя что-то новое. Плохо другое - вы свои маленькие открытия и виде очевидных истины считаете необходимым постить на Хабр, где предполагается другой, более профессиональный уровень материала.
Кстати, если все таки по разными причинам вам необходимо будет джойнить справочники или таблицы, которые можно привести к таковым, к основной таблице (например, фактов), то почитайте про Dictionary - тоже помогает увеличить скорость
Ну и самое основное в производительности CH - это конечно же правильный выбор столбцов, попадающих в первичные ключи или предложение ORDER BY. А все остальные способы увеличения производительности в CH больше про удобство.
Лучше бы из клика удалили JOIN, так как его изначательно не было, и, кажется, что сделали больше чтобы просто показать что такое есть. Наличие больше вводит в заблужение "как в postgres", чем помогает
Кто-то "открыл Америку" для себя. Мда...
Тесты на 4-х запросах можно только менеджерам показывать, они серавно нифига не понимают. Протестируй на tpc-h
А почему ни слова не сказано об альтернативном решении при помощи dictionary?
А есть подробнее инфо про это?
Как ни странно, но наиболее подробная информация об этом в документации
И вы не показали еще запросы с JOIN-ами, в ClickHouse их надо писать по особому, чтобы было быстро
Вопрос: какая производительность у CH по сравнению с PG или например Starrocks в расчете скользящих средних, например? Т.е. когда сторого говоря JOIN не нужен, но требуется сопоставление рядов плоской таблицы с ними же по определенному индексу?
В ClickHouse одна плоская таблица лучше, чем несколько соединенных таблиц