На счет правильного спорно. Тут всякие дополнительные истории возникают с сессиями, с распределенным кластером - легко можно вообще не обнаружить созданную таблицу при запросе с попыткой ее использования.
Если хочется cte, то это можно обойти с помощью костыля:
with
(
select groupArray(num)
from ( /* тут исходный запрос из cte */
SELECT
num
FROM generateRandom('num UInt64', NULL)
LIMIT 1000000
)
) as cte_constant,
cte_numbers as (
select arrayJoin(cte_constant) as num
)
SELECT
count()
FROM cte_numbers
WHERE num IN (SELECT num FROM cte_numbers)
┌─count()─┐
│ 1000000 │
└─────────┘
через groupArray() возвращаем одно значение, которое через синтаксис with (...) as материализуется в константу, а потом обратно разворачиваем где нужно через arrayJoin().
В более общем случае надо в tuple завернуть значения, если их несколько:
with
(
select groupArray((c1, c2, ...))
from (
select c1, c2, ...
)
) as cte_constant,
cte_values as (
select (arrayJoin(cte_constant) as tpl).1 as c1, tpl.2 as c2...
)
select ...
Но у меня работа во многом про оптимизацию, и как правило я сталкиваюсь с тем, что cte из запроса выпиливаю, потому что в разных местах запроса оптимальнее использовать разные подзапросы, чем переиспользовать что-то универсальное.
Когда мне пытаются рассказывать, что decimal точнее, чем float аналогичной размерности, мое лицо похоже на лицо этих аудиторов. Хотя мои примеры обычно попроще, вроде вставки в базу 0.009 и получением в результате 0.00.
Если анализировать за большой промежуток времени, то лучше не "лайкать" query_log, так как это может быть долго, а вместо этого использовать not has(tables, 'system.query_log').
Когда к ClickHouse обращаются несколько сервисов (дашборды, оркестраторы пайплайнов, ручные запросы аналитиков), в query_log тысячи записей, и непонятно, кто создаёт нагрузку.
Странно, что тут не написано про банальные initial_user и user. Ну и есть еще полезные client_hostname и initial_address. Статья про поиск проблемы, а наличие прописанного log_comment - это не дефолтное поведение. Про это, наверное, можно было бы в конце статьи написать как рекомендацию к использованию.
Пример тяжёлого запроса … FROM events final WHERE event_date > ‘2024-01-01’ … PARTITION BY toYYYYMM(event_date) ORDER BY (event_id, user_id, event_date); … Теперь картина ясна. Что можно сделать?
Самое эффективное здесь будет добавить в конец запроса settings do_not_merge_across_partitions_select_final = 1;. А еще помимо замены на uniq можно воспользоваться хаком из моей статьи :-) uniqExact(cityHash64(event_id)) - всего x2 памяти сэкономим, но посчитаем точно.
Ну и не по теме статьи, но если это реальная таблица у вас, то скорее всего у вас там ключ сортировки неоптимальный. На первом месте event_id UUID и после него всё остальное уже не имеет смысла в плане эффективности ключа. Полагаю любой из вариантов (event_date, user_id, event_id) или (user_id, event_date, event_id) будет лучше, а если вам нужен поиск по event_id, то можно bloom_filter на эту колонку навесить.
Когда гуглил, там было какое-то расширение для скрытия по авторам. А что если автор "исправится"? Понимаю желание, но нет, я в свое не буду это добавлять. Вообще изначально было суперпросто - только скрытие хаба, но выяснилось, что хабы проставляются не везде, и не везде добавлен нужный.
Это правильный вопрос. Но сбрасывая кеши тоже получаешь результат отличный от того, что будет в продакшене, так как там кеши есть. Тот же Mark Cache если сбросить, то это будет ситуация, не имеющая отношения к реальности. Page cache тоже в реальности должен хоть как-то работать. Поэтому я не фанат тестов со сбросом кеша. Query cache, конечно, не использовался :-).
Тесты проводились в clickhouse-client локально на машине с clickhouse. Обычно я сначала делаю запросы, не имеющие отношения к тесту, потом тестовые. Затем повторно тестовые + в обратном порядке, чтобы убедиться, что время особо не меняется. Не слишком строгий подход, но мне этого достаточно, когда я вижу, что время сильно не скачет. Вообще статья больше про память, а скорость - это бонус (могло быть и медленнее, но статья всё равно бы была).
Сейчас посмотрел в логах OpenedFileCacheHits и OpenedFileCacheMisses по тестовым запросам - там 50/50 было примерно.
Про разные таблицы - как вариант, но что-то мне интуитивно не нравится. Как минимум те же кеши получаются раздельные и на более "легких" тестах заполняемость может быть лучше, что даст дополнительное преимущество. Разные парты будут, а если до одного схлопнуть, тоже обычно не реальная ситуация. Но это не слишком сильные аргументы с моей стороны.
В любом случае я специально сделал воспроизводимые тесты, чтобы желающие могли повторить. Если в каких-то условиях оно будет давать качественно иной результат, можно обсудить.
Успехов. Но хеширование, конечно, не единственный и не главный прием при оптимизации сферического запроса в вакууме. Начать всегда стоит с максимума условий в where (для каждой используемой таблицы) и правильного порядка джойнов (справа меньше данных, чем слева).
Главная проблема клиппинга это не сама потеря скорости, а непредсказуемость этого процесса для едущих позади пилотов. И главное обсуждение в руководстве сейчас именно с точки зрения безопасности.
сейчас обсуждение ведется в основном по поводу квалификации
Вот только в квалификации на быстром круге друг за дружкой не едут, и эта опасность не проявляется
Только с боковой панелью (где закладки, загрузки и т.д.) как-то странно и неудобно работает. Она у меня изначально полностью скрыта. Но если включаю режим автоскрытия, то боковая панель появляется в развернутом виде и остается висеть пока не наведешь на нее мышкой и не уберешь мышь опять. Но после выхода из режима автоскрытия боковая панель становится видимой (в узком виде, где только иконки).
Однако при более внимательном анализе возникает существенное противоречие.
«90,7% используют английский в обучении, но при этом 57,4% оценивают свой уровень как начальный»
Не вижу никакого противоречия.
Если человек идет на техническую специальность, то с большей вероятностью у него есть способности к технической части, чем к иностранному языку.
Как ни крути - это второстепенный навык. Точно также какому-нибудь бэкенд разработчику необходим навык SQL, но точно также он оценит навык как начальный.
Как у вас устроено создание новых версий схем в Schema Registry? Новая версия согласуется командой Databus, или всё в руках команд сервисов, отправляющих события? Если первое, то сразу делаются схемы Dev/Stage/Prod или последовательно сначала только Dev, потом проверка данных по новой версии схемы на Dev и только потом Stage/Prod? Или как-то еще иначе?
к 2028 году 1% мировой вычислительной мощности будет находиться на орбите
Еще бредовее, чем высадка человека на Марс в {выберите любой год, озвученный Маском в прошлом или будущем} году. Ставлю, что и к 2128 году не будет.
Радиаторы размером с квартал, невозможность обслуживания, температурная нестабильность, излучение/частицы, отсутствие хоть каких-то необходимых технологий... И ладно еще было бы зачем (чего-то, чего нельзя было бы получить на Земле, как с некоторыми космическими телескопами), дак тут и этого нет.
Честно говоря, кажется, что описано что-то из фантастического мира сферических розовых пони в вакууме.
1. А оно точно нужно? Бизнес действительно не может жить без этого костыля прямо сейчас? Или мы просто боимся сказать «нет» и потратить время на нормальное решение?
Половина «срочных» временных решений нужна не бизнесу, а чтобы отчитаться о закрытии тикета в спринте.
Ответ менеджера в реальном мире: Да, естественно мы боимся потратить время, и нам надо закрыть задачу/проект.
2. Мы знаем, как сделать правильно? У нас есть четкое понимание, как должна выглядеть архитектура итогового решения? Все ли блоки мы можем реализовать?
Если правильное решение непонятно, то «временное» — это не решение, а отсрочка провала. Вы не покупаете себе время, а закладываете мину.
Ответ менеджера в реальном мире (да и мой в этом случае был бы таким же): Естественно, если мы сейчас знаем только одно решение, которое мы можем сделать сейчас и закрыть боль заказчика, то делаем это решение а потом думаем.
Мое любимое - это когда врут, не подозревая, что врут: stacked графики (когда каждая величина откладывается не от нуля, а вверх от предыдущей линии). На скриншоте значение оранжевой величины всегда неизменно, а кажется, что оно сильно падало в промежутке от x=4 до x=5.
На счет правильного спорно. Тут всякие дополнительные истории возникают с сессиями, с распределенным кластером - легко можно вообще не обнаружить созданную таблицу при запросе с попыткой ее использования.
Если хочется cte, то это можно обойти с помощью костыля:
через
groupArray()возвращаем одно значение, которое через синтаксисwith (...) asматериализуется в константу, а потом обратно разворачиваем где нужно черезarrayJoin().В более общем случае надо в tuple завернуть значения, если их несколько:
Но у меня работа во многом про оптимизацию, и как правило я сталкиваюсь с тем, что cte из запроса выпиливаю, потому что в разных местах запроса оптимальнее использовать разные подзапросы, чем переиспользовать что-то универсальное.
Когда мне пытаются рассказывать, что decimal точнее, чем float аналогичной размерности, мое лицо похоже на лицо этих аудиторов. Хотя мои примеры обычно попроще, вроде вставки в базу 0.009 и получением в результате 0.00.
Если анализировать за большой промежуток времени, то лучше не "лайкать" query_log, так как это может быть долго, а вместо этого использовать
not has(tables, 'system.query_log').Странно, что тут не написано про банальные initial_user и user. Ну и есть еще полезные client_hostname и initial_address. Статья про поиск проблемы, а наличие прописанного
log_comment- это не дефолтное поведение. Про это, наверное, можно было бы в конце статьи написать как рекомендацию к использованию.Самое эффективное здесь будет добавить в конец запроса
settings do_not_merge_across_partitions_select_final = 1;.А еще помимо замены на uniq можно воспользоваться хаком из моей статьи :-)
uniqExact(cityHash64(event_id))- всего x2 памяти сэкономим, но посчитаем точно.Ну и не по теме статьи, но если это реальная таблица у вас, то скорее всего у вас там ключ сортировки неоптимальный. На первом месте
event_id UUIDи после него всё остальное уже не имеет смысла в плане эффективности ключа. Полагаю любой из вариантов(event_date, user_id, event_id)или(user_id, event_date, event_id)будет лучше, а если вам нужен поиск поevent_id, то можно bloom_filter на эту колонку навесить.Когда гуглил, там было какое-то расширение для скрытия по авторам. А что если автор "исправится"? Понимаю желание, но нет, я в свое не буду это добавлять. Вообще изначально было суперпросто - только скрытие хаба, но выяснилось, что хабы проставляются не везде, и не везде добавлен нужный.
Ссылку поправил, спасибо.
Это правильный вопрос. Но сбрасывая кеши тоже получаешь результат отличный от того, что будет в продакшене, так как там кеши есть. Тот же Mark Cache если сбросить, то это будет ситуация, не имеющая отношения к реальности. Page cache тоже в реальности должен хоть как-то работать. Поэтому я не фанат тестов со сбросом кеша. Query cache, конечно, не использовался :-).
Тесты проводились в clickhouse-client локально на машине с clickhouse. Обычно я сначала делаю запросы, не имеющие отношения к тесту, потом тестовые. Затем повторно тестовые + в обратном порядке, чтобы убедиться, что время особо не меняется. Не слишком строгий подход, но мне этого достаточно, когда я вижу, что время сильно не скачет. Вообще статья больше про память, а скорость - это бонус (могло быть и медленнее, но статья всё равно бы была).
Сейчас посмотрел в логах OpenedFileCacheHits и OpenedFileCacheMisses по тестовым запросам - там 50/50 было примерно.
Про разные таблицы - как вариант, но что-то мне интуитивно не нравится. Как минимум те же кеши получаются раздельные и на более "легких" тестах заполняемость может быть лучше, что даст дополнительное преимущество. Разные парты будут, а если до одного схлопнуть, тоже обычно не реальная ситуация. Но это не слишком сильные аргументы с моей стороны.
В любом случае я специально сделал воспроизводимые тесты, чтобы желающие могли повторить. Если в каких-то условиях оно будет давать качественно иной результат, можно обсудить.
Ответ про cityHash64() оформил в виде статьи, спасибо за идею:)
https://habr.com/ru/articles/1012624/
Успехов. Но хеширование, конечно, не единственный и не главный прием при оптимизации сферического запроса в вакууме. Начать всегда стоит с максимума условий в where (для каждой используемой таблицы) и правильного порядка джойнов (справа меньше данных, чем слева).
Вот только в квалификации на быстром круге друг за дружкой не едут, и эта опасность не проявляется
Не судьба.upd. Без vpn получилось.
У меня нет этой кнопки, без гугла не смог бы разобраться как это включить. Но да, в гостевом профиле тоже самое.
Имеется в виду приватный режим? Да, также.
del
Фича с автоскрытием классная (наверное😀).
Только с боковой панелью (где закладки, загрузки и т.д.) как-то странно и неудобно работает. Она у меня изначально полностью скрыта. Но если включаю режим автоскрытия, то боковая панель появляется в развернутом виде и остается висеть пока не наведешь на нее мышкой и не уберешь мышь опять. Но после выхода из режима автоскрытия боковая панель становится видимой (в узком виде, где только иконки).
Не вижу никакого противоречия.
Если человек идет на техническую специальность, то с большей вероятностью у него есть способности к технической части, чем к иностранному языку.
Как ни крути - это второстепенный навык. Точно также какому-нибудь бэкенд разработчику необходим навык SQL, но точно также он оценит навык как начальный.
Что-то такой упор на число поворотов и оптимальные алгоритмы. Но кажется, что в первую очередь всё упирается на механическую скорость и точность.
Как у вас устроено создание новых версий схем в Schema Registry? Новая версия согласуется командой Databus, или всё в руках команд сервисов, отправляющих события? Если первое, то сразу делаются схемы Dev/Stage/Prod или последовательно сначала только Dev, потом проверка данных по новой версии схемы на Dev и только потом Stage/Prod? Или как-то еще иначе?
Это ничего не изменит в плане перспектив вывода ЦОД на орбиту.
появлением
Еще бредовее, чем высадка человека на Марс в {выберите любой год, озвученный Маском в прошлом или будущем} году. Ставлю, что и к 2128 году не будет.
Радиаторы размером с квартал, невозможность обслуживания, температурная нестабильность, излучение/частицы, отсутствие хоть каких-то необходимых технологий... И ладно еще было бы зачем (чего-то, чего нельзя было бы получить на Земле, как с некоторыми космическими телескопами), дак тут и этого нет.
Честно говоря, кажется, что описано что-то из фантастического мира сферических розовых пони в вакууме.
Ответ менеджера в реальном мире: Да, естественно мы боимся потратить время, и нам надо закрыть задачу/проект.
Ответ менеджера в реальном мире (да и мой в этом случае был бы таким же): Естественно, если мы сейчас знаем только одно решение, которое мы можем сделать сейчас и закрыть боль заказчика, то делаем это решение а потом думаем.
Мое любимое - это когда врут, не подозревая, что врут: stacked графики (когда каждая величина откладывается не от нуля, а вверх от предыдущей линии). На скриншоте значение оранжевой величины всегда неизменно, а кажется, что оно сильно падало в промежутке от x=4 до x=5.