Комментарии 10
Ну с точки зрения формальной логики и произвольности данных хочется сказать, что запрос логически ошибочен. Просто представьте себе массив данных, пусть из тех же 100кк записей, просто в нём, чисто случайно, присутствуют исключительно продажи 1 и 2 типов, и ни одной записи с sales.sales_type = 0 просто нет. И становится понятно, что эта генерация всех возможных сочетаний, это ваше двойное CROSS JOIN. тупо сработало на раковину.
Я уж не говорю о том, что FROM dates CROSS JOIN sales выглядит и логичнее, и проще, и даже эстетичнее... ну разве что из-за особенностей обработки запросов в данной системе этот вариант проиграет вложенным подзапросам по скорости.
Все справедливые замечания, и по логике запроса, и по плану выполнения запроса в ClickHouse. Про запрос «до оптимизации» изначально говорилось, что он синтетический и только для целей иллюстрации, ведь если сразу написать оптимальный запрос, то нечего будет оптимизировать. Плюс здесь рассматривается именно оптимизация за счет комбинаторов ClickHouse с учетом кардинальностей, но так, конечно, подразумевается, что, например, переписывание запроса вручную даст результат лучше.
UPD: Я промахнулся веткой в этом комментарии, ответил в нужной ветке
А не проще сразу писать быстрые запросы, а тех, кто не умеет - увольнять? У меня случаи были оптимизации (руками), которые и в 10 000 раз ускоряли запрос (написанный не мной)… Ваш движок не ускорит запросы, написанные мной… Более того, для оптимизации «запросов» я применяю еще методы кэширования данных (те же MATERIALIZED VIEW и временные таблицы), изменение структуры таблиц и формата записи данных, изменения алгоритмов, которые используют эти запросы. Ваш движок такое умеет?
Я считаю, такие оптимизаторы вредными. Они позволяют тем, кто работает с БД быть тупыми…
"Дачник, уйдите, лекция для колхозников!" (с)
А не проще сразу писать быстрые запросы, а тех, кто не умеет - увольнять?
В дашбордах Visiology поддерживается DAX, в чистом виде SQL не используется, поэтому все вопросы, связанные с SQL, ДанКо решает без участия пользователя.
Получается, "кто ж его посадит, он же памятник")
Справедливости ради, автоматическая генерация и оптимизация SQL запросов является более общей и сложной задачей по сравнению с частными случаями оптимизаций, поэтому наверно такой диссонанс) Ручная "человеческая" оптимизация SQL действительно может давать SQL, выполняющийся быстрее автоматически сгенерированного, но ручная оптимизация SQL всегда требует затрат рабочего времени, ресурсов и т.д., по сравнению с автоматической в ДанКо
Хорошие примеры оптимизаций, выполненные вручную, — да, они реализованы в ДанКо.
В дашбордах Visiology поддерживается DAX, в чистом виде SQL не используется, поэтому все вопросы, связанные с SQL, ДанКо решает без участия пользователя.
В ДанКо поддерживается как минимум два вида кэширования: частей SQL запроса, кеширование всего результата DAX запроса. Также ДанКо поддерживает множество оптимизаций, изменяющих структуру SQL запроса, с учетом особенностей плана выполнения запроса в ClickHouse, типов данных, кардинальностей использованных столбцов и других параметров.
Так, будьте добры статью запилить по этому поводу, мне интересно)
UPD: опять я промахнулся веткой)
Возможности комбинаторов в ClickHouse