Когда мне пытаются рассказывать, что 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.
Но есть и неочевидный минус офиса — «ложная социализация». «Люди в офисе могут тебя задерживать. Работа тебя не развивает, но люди привязали. Ты не хочешь уходить, потому что в офисе есть "родные", с которыми ты проводишь по 8 часов. Это ловушка комфорта».
Разве не этого хотели в самом начале, когда обсуждали плюшки/зп/коллектив и сошлись на коллективе и атмосфере? Неясно, почему в этом описании социализация ложная, а комфорт иллюзорный?
Сигнал №3: Размытые цели. «Матрицы компетенций и цели на квартал нужны, чтобы твой рост не зависел от настроения начальника. Ты сможешь прийти и сказать: "Я сделал X, Y, Z — я готов повысить свой грейд". Если цели ставишь ты сам себе — это фикция».
У нас за несколько лет пробовали несколько систем целей - ни один лично мне не зашел. Они все были фикцией. Независимо от того, какие были цели, если прилетит новый проект с высоким приоритетом - ты делаешь его. И оценивают по тому, что оказалось важно по факту, какую реальную пользу ты принес, а не по тому, что написано в целях. И это норм, а придумывание целей - лишняя трата времени.
Когда мне пытаются рассказывать, что 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.
Разве не этого хотели в самом начале, когда обсуждали плюшки/зп/коллектив и сошлись на коллективе и атмосфере? Неясно, почему в этом описании социализация ложная, а комфорт иллюзорный?
У нас за несколько лет пробовали несколько систем целей - ни один лично мне не зашел. Они все были фикцией. Независимо от того, какие были цели, если прилетит новый проект с высоким приоритетом - ты делаешь его. И оценивают по тому, что оказалось важно по факту, какую реальную пользу ты принес, а не по тому, что написано в целях. И это норм, а придумывание целей - лишняя трата времени.