какое офигенное видео! большое спасибо, Евгений!очень полезно и без воды. как идея-было бы неплохо рассмотреть оптимизацию ресурсов и поиск утечек памяти(с помощью VisualVM к примеру)
В explain 1 цифра - это стоимость для начала конкретного этапа, а 2 - это общая стоимость выполнения. Первая цифра включает все операции выполненные до этого, чтобы начать текущий этап. Чтобы получить стоимость конкретного этапа нужно вычесть из цифры 2 цифру 1. Общая стоимость выполнения запроса это 2 цифра на последнем этапе, цифры не нужно суммировать, как это делает автор. По сути после первого преобразования запроса автором, запрос отработал медленнее))) Но это вполне объяснимо маленьким объемом данных и поэтому цифры будут скакать)
Быстро, ёмко, полезно. Спасибо за видео про оптимизацию запросов. Однозначно хотелось бы продолжение. Было бы здорово серия видео на тему оптимизации запросов и заигрывания с индексами.
Как всегда, огромное спасибо, Евгений. Ёмко и понятно. Узнал об удобстве DataGrip и о cost'ах. Буду тестировать. Всё сводится к анализу и, как следствие, удалению избыточных запросов (информации). Воочию представил насколько отсутствие оптимизации влияет на ресурсы и время предоставления информации, хотя таблица состоит всего из нескольких записей. Спасибо!
Евгений, огромное спасибо за видео! Как раз сейчас разбираюсь с индексами и оптимизацией запросов. Очень коротко и максимально понятно, а что самое главное нужно любому бэкенд разработчику.
Есть нюанс который не очевиден, используется timestamptz туда заливаются просто даты без времени и временной зоны. После оптимизации используется диапазон дат, но не учитывается временная зона, если указать другую временную зону, то селективность дат поменяется как и сам план запроса. Считаю, что timestamptz в данном примере не сильно подходит. Создавая тип данных, который потом не используется в полной мере, не совсем хорошая затея, так как увеличивает косты на обслуживание в зависимости от типа бд. В целом очень информативное видео без воды и по сути проблемы! Приятно смотреть на квалифицированного человека в RUclips.
Евгений, спасибо за контент! Ещё мой руководитель на проекте говорит что нужно всегда избегать подзапросов, практически всегда можно обойтись без них, а на производительность они влияют очень сильно
Совет от бывалых: не пытайтесь всё сразу вытащить одним запросом из кучи таблиц, бывает гораздо быстрее сделать 2 последовательных запроса. На очень больших таблицах добавляет скорости отсечь ненужные в выборке данные по первичному ключу. Сравнивать лонги проще, чем даты, особенно если дата имеет косвенную/прямую связь с порядком автоинкрементного первичного ключа.
Смысл запроса поменялся. В первом случае мы искали все январи, во втором случае январь определенного года. Я думаю, еще можно добавит про порядок join-ов. Таблица с FROM должна максимально отфильтровываться. Если у нас фильтр, который отсекает значительную часть данных, то применять его нужно на таблицу с FROM
Я бы сказал, что описанние в видео выглядит не как оптимизация, а скорей как просто логика и понимание принципов работы с базой данных, да и запросы очень простые, чтобы заморачиваться с их оптимизацией. Было бы интересно посмотреть на более сложные варианты запросов, где например используется последовательная выборка из множества таблиц, где по данным из первой ищется во второй, а затем например по данным из первой и второй ищется по третьей или что то подобное, ну то есть где возможны разные варианты и нужно выбрать оптимальный, ну или запрос выдает строки со связанными данными из разных таблиц, в таких запросах с кучей join и вложенными запросами действительно есть что оптимизировать. На одном из проектов сейчас как раз такая тема- дофига сложные запросы на пол экрана, и мне кажется, рано или поздно сталкиваешься с такими проектами, и тогда понимаешь, что не шаришь в sql)) А по работе с datagrip- вот это интересно! Стыдно признаться, о нем даже на слышал)) но выглядит круто
Хороший пример для начала, но если посмотреть в последнем плане, то: 1) кверя выполняется дольше, вероятно изза кеша 2) фул скан таблицы, т.е убери индексы и ничего не изменится))
Спасибо за комментарий! Да, согласен, что с точки зрения реалистичности этих сценариев много вопросов. Цель видео - это познакомить зрителя с инструментарием.
Урок получился симпатичный, но демонстрировать оптимизацию на 5 записях... Ну, такое. На малом кол-ве строк индексы могут мешать, а не ускорять. В Oracle'овых БД для тесткейсов часто используем генераторы строк вида "select rownum id, lpad('x',30,'x') from dual connect by level
Спасибо за комментарий! Цель - показать именно основы, потому что многие люди никогда не сталкивались с таким типом задач в принципе. А реальная оптимизация куда сложнее и коварнее.
@@EugeneSuleimanov Да я же не агитирую Вас усложнить сам запрос и его анализ. Не хотите объяснять работу генератора строк, скажите, что не поленились и написали 10 тыс insert'ов руками. Тогда и результат оптимизации в секундах будет более существенным.
Полное сканирование сразу понятно было. Странно описание таблиц не полное, где developer_id unsigned int not null (default допустим не нужно) - на ревью завалится. Потом created_at тоже not null default now... Про экспрес функцию многие забывают - важный аспект.
6:38 а как получилась итоговая сложность? она где-то написана в выводе explain-а (не вижу), или вручную пришлось сложить сложности? Большое спасибо за видео, качественно и информативно. Про explain на собеседованиях уже спрашивали, теперь понятно откуда начинать)
Спасибо за видео! Для учебных целей очень хорошо, наглядно - многие начинающие просто пишут запросы лишь бы заработало. Оптимизация - это следующая ступень эволюции 😊 Есть ли бесплатный аналог инструмента, которым вы пользовались, доступный из России без всяких vpn-ухищрений?
Вы стоимость неправильно считаете и вводите людей в заблуждение. "Важно понимать, что стоимость узла верхнего уровня включает стоимость всех его потомков" цитата из документации postgresql.
Спасибо за видео! Вопрос. А есть ли смысл в данном случае вместо двух индексов сделать один индекс на 2 поля (developer_id и created_at)? поскольку джойн по им обоим одновременно идет
Получается индекс из таблицы из которой мы пишем forieng key не создается автоматом при указании связи (developer_id) а создается у той таблицы на которую ссылаемся developers_id?
Спасибо. К сожалению, вся эта красота от JetBrains работает не со всеми БД. И если бы Евгений писал не свой большой и красивый монитор, а маленький - ноутбучный, то зрителям было бы видно гораздо лучше :)
Это просто отвратительно 2:30 Автор: Давайте выполним вот такой запрос Ответ: давайте мы не выполним такой запрос… Для того чтобы писать запросы а тем более их оптимизировать, нужна четко поставленная задача от заказчика. И где оно? Т.е. берем какой-то работающий запрос от балды из продакшина и без постановки начинает его «оптимизировать». Ты условие начальное видел, что убираешь один джоин и меняешь тип второго? Как можно менять extract на интервал, если там дата не за один год? Ну добавь 01-01-2022 и результат не сойдется. Про функциональный индекс на базе extract автор даже и не думал. Вопрос автору - куда ты лезешь ничего не понимая в предметной области и что ты хотел донести до аудитории? А потом все слушатели которые тут отлайкали начнут с таким подходом писать такой же говнокод и таким же подходом - читай со свиным рылом лезть в калашный ряд - продакшин
Когда невозможно придраться к форме, придираются к содержанию. Евгений, у Вас в конечный результат не попадает 1 января, и, соответственно, вся аналитика идет по другой борозде. ))
Обзор инструментов интересный, но конечно оптимизация притянута за уши, потому что изначальный пример взят из книги "как писать не надо". Такие вещи и интуитивно понятны, никто же в здравом уме не будет сравнивать месяц в дате с единицей - это как минимум даст неверные данные (за все года). Интересно было бы посмотреть как оптимизировать запрос который большой, "всю жизнь" работал, но под увеличенными нагрузками устал.
Очень мало обьяснения понятий. Что за начальная сложность, что за конечная сложность. Не обьяснили чем скобки помешали. Не обьяснили этапы которые почему то ушли после оптимизации. Очень сумбурное видео. Вам не хватает сценария чтоли. Но идея хорошая.
ИМХО для человека, который только знакомится с оптимизацией запросов - это уже не совсем основы. Более серьёзные подходы и теоретическая база требует большего времени.
Странная оптимизация. "Уберем лишнюю таблицу из запроса"... Дак это так можно надобавлять в запрос 50 ненужных таблиц, а потом героически с ними справиться. Кто будет добавлять в свои запросы ненужные таблицы?
Ёмко. Без воды. Доброжелательная подача. Спасибо)
Спасибо за отзыв :)
какое офигенное видео! большое спасибо, Евгений!очень полезно и без воды. как идея-было бы неплохо рассмотреть оптимизацию ресурсов и поиск утечек памяти(с помощью VisualVM к примеру)
Спасибо за поддержку!
Это тоже есть планах :)
@@EugeneSuleimanov тоже интересно (и как анализировать heap dump)
Спасибо большое.
Как идея, видео об транзакциях, аннотации @Transactional, уровнях изоляции, а так же локах на таблицы и избежание deadlock))
Спасибо за отзыв и идею :)
Евгений, после просмотра видео очень хочется пожать вам руку и сказать СПАСИБО!
Большое спасибо за отзыв!
В explain 1 цифра - это стоимость для начала конкретного этапа, а 2 - это общая стоимость выполнения.
Первая цифра включает все операции выполненные до этого, чтобы начать текущий этап.
Чтобы получить стоимость конкретного этапа нужно вычесть из цифры 2 цифру 1.
Общая стоимость выполнения запроса это 2 цифра на последнем этапе, цифры не нужно суммировать, как это делает автор.
По сути после первого преобразования запроса автором, запрос отработал медленнее)))
Но это вполне объяснимо маленьким объемом данных и поэтому цифры будут скакать)
@@toddis4912 спасибо за полезный комментарий и конструктив.
Быстро, ёмко, полезно. Спасибо за видео про оптимизацию запросов. Однозначно хотелось бы продолжение. Было бы здорово серия видео на тему оптимизации запросов и заигрывания с индексами.
Спасибо за отзыв и идею!
Как всегда, огромное спасибо, Евгений. Ёмко и понятно. Узнал об удобстве DataGrip и о cost'ах. Буду тестировать.
Всё сводится к анализу и, как следствие, удалению избыточных запросов (информации).
Воочию представил насколько отсутствие оптимизации влияет на ресурсы и время предоставления информации, хотя таблица состоит всего из нескольких записей.
Спасибо!
Большое спасибо за отзыв!
Лучший)) Коротко. Чётко. Ёмко. Полезно. Жаль, что пока мало видосов на канале. Не бросайте это дело
Спасибо за поддержку!
Бомбическое видео! Я горжусь тем, что мой преподаватель по Java сам пишет профессиональные статьи. Спасибо тебе, Женя, большое))
Спасибо за отзыв :)
Евгений, огромное спасибо за видео! Как раз сейчас разбираюсь с индексами и оптимизацией запросов. Очень коротко и максимально понятно, а что самое главное нужно любому бэкенд разработчику.
Спасибо за отзыв!
Искал медь, нашёл золото - это про канал Евгения)
Спасибо за поддержку :)
Классное и очень полезное видео, прям во время вышло!!! Спасибо, Евгений👍👍👍
Спасибо за поддержку!
Есть нюанс который не очевиден, используется timestamptz туда заливаются просто даты без времени и временной зоны.
После оптимизации используется диапазон дат, но не учитывается временная зона, если указать другую временную зону, то селективность дат поменяется как и сам план запроса.
Считаю, что timestamptz в данном примере не сильно подходит. Создавая тип данных, который потом не используется в полной мере, не совсем хорошая затея, так как увеличивает косты на обслуживание в зависимости от типа бд.
В целом очень информативное видео без воды и по сути проблемы!
Приятно смотреть на квалифицированного человека в RUclips.
Евгений, спасибо за контент! Ещё мой руководитель на проекте говорит что нужно всегда избегать подзапросов, практически всегда можно обойтись без них, а на производительность они влияют очень сильно
Спасибо за отзыв!
А зачем же мы их так усиленно учим))
"Практически всегда можно обойтись без них" - громко сказано)
Совет от бывалых: не пытайтесь всё сразу вытащить одним запросом из кучи таблиц, бывает гораздо быстрее сделать 2 последовательных запроса.
На очень больших таблицах добавляет скорости отсечь ненужные в выборке данные по первичному ключу. Сравнивать лонги проще, чем даты, особенно если дата имеет косвенную/прямую связь с порядком автоинкрементного первичного ключа.
Большое спасибо.Как же я соскучился за всем этим)
Спасибо за отзыв!
Лучший! Продолжайте пожалуйста в том же духе, с наступающим, всех благ
Большое спасибо за отзыв и поздравления!
С наступающими праздниками!!!
Благодарность за классный и ценный ролик
Спасибо за поддержку!
Смысл запроса поменялся. В первом случае мы искали все январи, во втором случае январь определенного года.
Я думаю, еще можно добавит про порядок join-ов. Таблица с FROM должна максимально отфильтровываться. Если у нас фильтр, который отсекает значительную часть данных, то применять его нужно на таблицу с FROM
Спасибо Евгений, лаконично и понятно
Спасибо за отзыв!
Супер ! спасибо огромное, Евгений!)
Большое спасибо за отзыв!
Полезный видосик, спасибо!
Спасибо за комментарий!
Я бы сказал, что описанние в видео выглядит не как оптимизация, а скорей как просто логика и понимание принципов работы с базой данных, да и запросы очень простые, чтобы заморачиваться с их оптимизацией. Было бы интересно посмотреть на более сложные варианты запросов, где например используется последовательная выборка из множества таблиц, где по данным из первой ищется во второй, а затем например по данным из первой и второй ищется по третьей или что то подобное, ну то есть где возможны разные варианты и нужно выбрать оптимальный, ну или запрос выдает строки со связанными данными из разных таблиц, в таких запросах с кучей join и вложенными запросами действительно есть что оптимизировать. На одном из проектов сейчас как раз такая тема- дофига сложные запросы на пол экрана, и мне кажется, рано или поздно сталкиваешься с такими проектами, и тогда понимаешь, что не шаришь в sql)) А по работе с datagrip- вот это интересно! Стыдно признаться, о нем даже на слышал)) но выглядит круто
Спасибо за комментарий!
В IDEA Ultimate это все тоже есть - и explain в удобном виде, и визуализация
Большое спасибо за такое полезное видео!)
Спасибо за поддержку!
Отличное видео, спасибо большое!
Спасибо за отзыв!
Класс. Спасибо. ❤
Только на 14:28 в where должно быть больше ИЛИ РАВНО 1 Января
@@selub1058 большое спасибо за поддержку и за уточнение.
да ты мое золото. просто лучший!
Спасибо за поддержку!
Блогодарю за полезное видео
Спасибо за комментарий!
Хороший пример для начала, но если посмотреть в последнем плане, то:
1) кверя выполняется дольше, вероятно изза кеша
2) фул скан таблицы, т.е убери индексы и ничего не изменится))
Спасибо за комментарий!
Да, согласен, что с точки зрения реалистичности этих сценариев много вопросов. Цель видео - это познакомить зрителя с инструментарием.
Супер полезное видео!
Спасибо за отзыв!
Очень круто. Супер лайк
Спасибо за отзыв!
Женя - топовый чувак
Спасибо за поддержку!
Спасибо за видео. Вы в практике часто используете функцию extract? Я вроде ни разу не использовал
Спасибо за отзыв!
Нет, не использую, но несколько раз видел. Это учебный пример.
Урок получился симпатичный, но демонстрировать оптимизацию на 5 записях... Ну, такое. На малом кол-ве строк индексы могут мешать, а не ускорять. В Oracle'овых БД для тесткейсов часто используем генераторы строк вида "select rownum id, lpad('x',30,'x') from dual connect by level
Спасибо за комментарий!
Цель - показать именно основы, потому что многие люди никогда не сталкивались с таким типом задач в принципе. А реальная оптимизация куда сложнее и коварнее.
@@EugeneSuleimanov Да я же не агитирую Вас усложнить сам запрос и его анализ. Не хотите объяснять работу генератора строк, скажите, что не поленились и написали 10 тыс insert'ов руками. Тогда и результат оптимизации в секундах будет более существенным.
Если придираться, то тогда для более верного сравнения стоимости запроса лучше выполнять его на разных данных и несколько раз.
Полное сканирование сразу понятно было. Странно описание таблиц не полное, где developer_id unsigned int not null (default допустим не нужно) - на ревью завалится. Потом created_at тоже not null default now... Про экспрес функцию многие забывают - важный аспект.
Спасибо за комментарий!
Разумеется, это не «боевой» код.
что не так с created_at not null default now?
6:38 а как получилась итоговая сложность? она где-то написана в выводе explain-а (не вижу), или вручную пришлось сложить сложности?
Большое спасибо за видео, качественно и информативно. Про explain на собеседованиях уже спрашивали, теперь понятно откуда начинать)
Да, просто сложил общую сложность :)
Отличная подача материала, доступно и полезно. Вопрос: не вредно ли добавлять >1 индекса в одну таблицу в OLTP СУБД?
Спасибо за отзыв!
Здесь нужно искать компромисс, ведь вставка замедлится. Но зависит от контекста задачи.
фактологическая ошибка.... косты не надо суммировать, их общая стоимость уже приведена в первой строке explain
Спасибо за уточнение!
thanks, that was very helpfull
Thank you for the comment!
А можно ж было сделать функциональный индекс с экстрактом месяца по колонке с датой. Или виртуальную колонку, плюс партиционирование по ней.
Это уже не основы, а несколько более продвинутый подход.
И спасибо за комментарий.
смысла в этом нет, только раздувание данных в таблице
Спасибо за видео! Для учебных целей очень хорошо, наглядно - многие начинающие просто пишут запросы лишь бы заработало. Оптимизация - это следующая ступень эволюции 😊
Есть ли бесплатный аналог инструмента, которым вы пользовались, доступный из России без всяких vpn-ухищрений?
Спасибо за отзыв!
Касательно аналога - PG Admin - стандартный интерфейс.
@@EugeneSuleimanov спасибо, но, кажется там нет наглядного отображения плана запроса. Или есть?
@@svetlana4530 верно, только raw описание, к сожалению.
Я правилтно понимаю, что замена join на left join это не оптимизация, а испраление логической ошибки?
👍👍
Вы стоимость неправильно считаете и вводите людей в заблуждение. "Важно понимать, что стоимость узла верхнего уровня включает стоимость всех его потомков" цитата из документации postgresql.
@@СергейПанин-л6к да, вы абсолютно правы, большое спасибо за конструктивную критику. Я допустил ошибку.
Спасибо за видео! Вопрос. А есть ли смысл в данном случае вместо двух индексов сделать один индекс на 2 поля (developer_id и created_at)? поскольку джойн по им обоим одновременно идет
Да, можно попробовать сделать такой индекс.
Спасибо за отзыв!
Получается индекс из таблицы из которой мы пишем forieng key не создается автоматом при указании связи (developer_id) а создается у той таблицы на которую ссылаемся developers_id?
Верно, Postgres не создает индекс для внешнего ключа автоматически. Автоматически создаются индексы для первичных ключей и уникальный полей.
Спасибо!🙂
Спасибо за комментарий!
Jetbrains со своим Data Grip послал Россиию на 3 буквы насколкьо я знаю, или что то поменялось ? У меня все платные аккаунты заблочили в этом году
Спасибо. К сожалению, вся эта красота от JetBrains работает не со всеми БД.
И если бы Евгений писал не свой большой и красивый монитор, а маленький - ноутбучный, то зрителям было бы видно гораздо лучше :)
Спасибо за комментарий!
По размеру шрифта, постараюсь учесть и справить на будущее :)
В конечном итоге можно ведь сократить запрос до обычного селекта по таблице tasks, джоин лишний
Здесь был задел на то, что будут запрещены данные developer. Но и пример учебный.
Дякую
Дякую за коментар!
Со смартфона - ничего не могу разобрать, сильно мелко. А так материал - ОК. Спасибо
Спасибо за комментарий!
А ты уверен, что показывает не сразу всю сумму поддерева?
Это просто отвратительно
2:30
Автор: Давайте выполним вот такой запрос
Ответ: давайте мы не выполним такой запрос…
Для того чтобы писать запросы а тем более их оптимизировать, нужна четко поставленная задача от заказчика. И где оно?
Т.е. берем какой-то работающий запрос от балды из продакшина и без постановки начинает его «оптимизировать».
Ты условие начальное видел, что убираешь один джоин и меняешь тип второго?
Как можно менять extract на интервал, если там дата не за один год? Ну добавь 01-01-2022 и результат не сойдется.
Про функциональный индекс на базе extract автор даже и не думал.
Вопрос автору - куда ты лезешь ничего не понимая в предметной области и что ты хотел донести до аудитории?
А потом все слушатели которые тут отлайкали начнут с таким подходом писать такой же говнокод и таким же подходом - читай со свиным рылом лезть в калашный ряд - продакшин
Спасибо за ваше мнение.
Всем икспердам желаю меньше пафоса. Ведь вы никогда не расскажете, как сами пока росли облажались не раз на коммерческих проектах.
И зачем суммировать стоимость костов? тебе последний шаг и так сумму выдал всех предыдущих шагов.
11:42 это опять внешний ключ, индекс и так был.
В Postgres внешний ключ по умолчанию не индексируется. Только первичный и unique constraint.
Цікаво, що ваш сайт заблокований для доступу з України)
Проверю, спасибо за сигнал.
Когда невозможно придраться к форме, придираются к содержанию. Евгений, у Вас в конечный результат не попадает 1 января, и, соответственно, вся аналитика идет по другой борозде. ))
Справедливо :)
Спасибо за комментарий!
Обзор инструментов интересный, но конечно оптимизация притянута за уши, потому что изначальный пример взят из книги "как писать не надо". Такие вещи и интуитивно понятны, никто же в здравом уме не будет сравнивать месяц в дате с единицей - это как минимум даст неверные данные (за все года). Интересно было бы посмотреть как оптимизировать запрос который большой, "всю жизнь" работал, но под увеличенными нагрузками устал.
Спасибо за комментарий!
Пример как делать не нужно из палаты мер и весов :)
неужели ютуб начал советовать нормальные материалы =)
Спасибо за комментарий!
Очень мало обьяснения понятий. Что за начальная сложность, что за конечная сложность. Не обьяснили чем скобки помешали. Не обьяснили этапы которые почему то ушли после оптимизации. Очень сумбурное видео. Вам не хватает сценария чтоли. Но идея хорошая.
Спасибо за отзыв и вообще мнение!
полная чушь
расскажите хотя бы человеку, что бывает предварительный план выполнения, а бывает реальный
ИМХО для человека, который только знакомится с оптимизацией запросов - это уже не совсем основы. Более серьёзные подходы и теоретическая база требует большего времени.
Евгений спасибо огромное! У вас есть ошибка в последнем запросе: должно быть created_at >= '2023-01-01', но на результат не влияет
Спасибо за отзыв!
Да, уже подсказали об ошибке, спасибо :)
+
Спасибо за поддержку!
Столько глупостей наговорил. Может не стоит с такими поверхностными представлениями из чужой области лезть учить других?
Странная оптимизация. "Уберем лишнюю таблицу из запроса"... Дак это так можно надобавлять в запрос 50 ненужных таблиц, а потом героически с ними справиться. Кто будет добавлять в свои запросы ненужные таблицы?