какое офигенное видео! большое спасибо, Евгений!очень полезно и без воды. как идея-было бы неплохо рассмотреть оптимизацию ресурсов и поиск утечек памяти(с помощью VisualVM к примеру)
@EugeneSuleimanov8 ай бұрын
Спасибо за поддержку! Это тоже есть планах :)
@admiralakbar19368 ай бұрын
@@EugeneSuleimanov тоже интересно (и как анализировать heap dump)
@qaserus12268 ай бұрын
Спасибо большое. Как идея, видео об транзакциях, аннотации @Transactional, уровнях изоляции, а так же локах на таблицы и избежание deadlock))
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв и идею :)
@user-lx4dc1ls3e8 ай бұрын
Классное и очень полезное видео, прям во время вышло!!! Спасибо, Евгений👍👍👍
@EugeneSuleimanov8 ай бұрын
Спасибо за поддержку!
@ZamalSpace8 ай бұрын
Быстро, ёмко, полезно. Спасибо за видео про оптимизацию запросов. Однозначно хотелось бы продолжение. Было бы здорово серия видео на тему оптимизации запросов и заигрывания с индексами.
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв и идею!
@Devivl8 ай бұрын
Как всегда, огромное спасибо, Евгений. Ёмко и понятно. Узнал об удобстве DataGrip и о cost'ах. Буду тестировать. Всё сводится к анализу и, как следствие, удалению избыточных запросов (информации). Воочию представил насколько отсутствие оптимизации влияет на ресурсы и время предоставления информации, хотя таблица состоит всего из нескольких записей. Спасибо!
@EugeneSuleimanov8 ай бұрын
Большое спасибо за отзыв!
@zicksu21425 ай бұрын
Евгений, после просмотра видео очень хочется пожать вам руку и сказать СПАСИБО!
@EugeneSuleimanov5 ай бұрын
Большое спасибо за отзыв!
@user-ol9iu4iy6i8 ай бұрын
Искал медь, нашёл золото - это про канал Евгения)
@EugeneSuleimanov8 ай бұрын
Спасибо за поддержку :)
@MultiKenes5 ай бұрын
Лучший)) Коротко. Чётко. Ёмко. Полезно. Жаль, что пока мало видосов на канале. Не бросайте это дело
@EugeneSuleimanov4 ай бұрын
Спасибо за поддержку!
@ratsmasher8 ай бұрын
Евгений, огромное спасибо за видео! Как раз сейчас разбираюсь с индексами и оптимизацией запросов. Очень коротко и максимально понятно, а что самое главное нужно любому бэкенд разработчику.
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв!
@user-xu3px8pu4t8 ай бұрын
Большое спасибо.Как же я соскучился за всем этим)
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв!
@anjelomanoranjan8 ай бұрын
Бомбическое видео! Я горжусь тем, что мой преподаватель по Java сам пишет профессиональные статьи. Спасибо тебе, Женя, большое))
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв :)
@user-fy7qn9bv7y5 ай бұрын
Супер ! спасибо огромное, Евгений!)
@EugeneSuleimanov5 ай бұрын
Большое спасибо за отзыв!
@romankryvolapov79618 ай бұрын
Я бы сказал, что описанние в видео выглядит не как оптимизация, а скорей как просто логика и понимание принципов работы с базой данных, да и запросы очень простые, чтобы заморачиваться с их оптимизацией. Было бы интересно посмотреть на более сложные варианты запросов, где например используется последовательная выборка из множества таблиц, где по данным из первой ищется во второй, а затем например по данным из первой и второй ищется по третьей или что то подобное, ну то есть где возможны разные варианты и нужно выбрать оптимальный, ну или запрос выдает строки со связанными данными из разных таблиц, в таких запросах с кучей join и вложенными запросами действительно есть что оптимизировать. На одном из проектов сейчас как раз такая тема- дофига сложные запросы на пол экрана, и мне кажется, рано или поздно сталкиваешься с такими проектами, и тогда понимаешь, что не шаришь в sql)) А по работе с datagrip- вот это интересно! Стыдно признаться, о нем даже на слышал)) но выглядит круто
@EugeneSuleimanov8 ай бұрын
Спасибо за комментарий!
@SplashDmg20118 ай бұрын
В IDEA Ultimate это все тоже есть - и explain в удобном виде, и визуализация
@iamusayev13378 ай бұрын
Лучший! Продолжайте пожалуйста в том же духе, с наступающим, всех благ
@EugeneSuleimanov8 ай бұрын
Большое спасибо за отзыв и поздравления! С наступающими праздниками!!!
@Lenz_868 ай бұрын
Евгений, спасибо за контент! Ещё мой руководитель на проекте говорит что нужно всегда избегать подзапросов, практически всегда можно обойтись без них, а на производительность они влияют очень сильно
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв!
@klaussr8 ай бұрын
А зачем же мы их так усиленно учим))
@zvuk33168 ай бұрын
"Практически всегда можно обойтись без них" - громко сказано)
@user-ur7bn1kd1p7 ай бұрын
Совет от бывалых: не пытайтесь всё сразу вытащить одним запросом из кучи таблиц, бывает гораздо быстрее сделать 2 последовательных запроса. На очень больших таблицах добавляет скорости отсечь ненужные в выборке данные по первичному ключу. Сравнивать лонги проще, чем даты, особенно если дата имеет косвенную/прямую связь с порядком автоинкрементного первичного ключа.
@user-lk8n0fgjk7 ай бұрын
Благодарность за классный и ценный ролик
@EugeneSuleimanov7 ай бұрын
Спасибо за поддержку!
@MO3rOBOuBbICEP8 ай бұрын
Полезный видосик, спасибо!
@EugeneSuleimanov8 ай бұрын
Спасибо за комментарий!
@AnnaSmirnova18 ай бұрын
Спасибо Евгений, лаконично и понятно
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв!
@zvuk33168 ай бұрын
Большое спасибо за такое полезное видео!)
@EugeneSuleimanov8 ай бұрын
Спасибо за поддержку!
@user-fz3rk8qv1dАй бұрын
спасибо за базу !
@EugeneSuleimanovАй бұрын
Спасибо за отзыв!
@Fikusiklol5 ай бұрын
Хороший пример для начала, но если посмотреть в последнем плане, то: 1) кверя выполняется дольше, вероятно изза кеша 2) фул скан таблицы, т.е убери индексы и ничего не изменится))
@EugeneSuleimanov4 ай бұрын
Спасибо за комментарий! Да, согласен, что с точки зрения реалистичности этих сценариев много вопросов. Цель видео - это познакомить зрителя с инструментарием.
@user-qx3jt8fw1v8 ай бұрын
да ты мое золото. просто лучший!
@EugeneSuleimanov8 ай бұрын
Спасибо за поддержку!
@spezdm8 ай бұрын
Блогодарю за полезное видео
@EugeneSuleimanov8 ай бұрын
Спасибо за комментарий!
@dmitriysavinov99068 ай бұрын
Супер полезное видео!
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв!
@selub105811 күн бұрын
Класс. Спасибо. ❤ Только на 14:28 в where должно быть больше ИЛИ РАВНО 1 Января
@EugeneSuleimanov11 күн бұрын
@@selub1058 большое спасибо за поддержку и за уточнение.
@bryanin8 ай бұрын
Очень круто. Супер лайк
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв!
@user-yn1pk3bz2r8 ай бұрын
Женя - топовый чувак
@EugeneSuleimanov8 ай бұрын
Спасибо за поддержку!
@cosmo_polit8 ай бұрын
thanks, that was very helpfull
@EugeneSuleimanov8 ай бұрын
Thank you for the comment!
@BGlazyrin8 ай бұрын
Урок получился симпатичный, но демонстрировать оптимизацию на 5 записях... Ну, такое. На малом кол-ве строк индексы могут мешать, а не ускорять. В Oracle'овых БД для тесткейсов часто используем генераторы строк вида "select rownum id, lpad('x',30,'x') from dual connect by level
@EugeneSuleimanov8 ай бұрын
Спасибо за комментарий! Цель - показать именно основы, потому что многие люди никогда не сталкивались с таким типом задач в принципе. А реальная оптимизация куда сложнее и коварнее.
@BGlazyrin8 ай бұрын
@@EugeneSuleimanov Да я же не агитирую Вас усложнить сам запрос и его анализ. Не хотите объяснять работу генератора строк, скажите, что не поленились и написали 10 тыс insert'ов руками. Тогда и результат оптимизации в секундах будет более существенным.
@user-ur7bn1kd1p7 ай бұрын
Если придираться, то тогда для более верного сравнения стоимости запроса лучше выполнять его на разных данных и несколько раз.
@konstantinmatushenko58318 ай бұрын
Спасибо за видео. Вы в практике часто используете функцию extract? Я вроде ни разу не использовал
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв! Нет, не использую, но несколько раз видел. Это учебный пример.
@admiralakbar19368 ай бұрын
6:38 а как получилась итоговая сложность? она где-то написана в выводе explain-а (не вижу), или вручную пришлось сложить сложности? Большое спасибо за видео, качественно и информативно. Про explain на собеседованиях уже спрашивали, теперь понятно откуда начинать)
@EugeneSuleimanov8 ай бұрын
Да, просто сложил общую сложность :)
@user-cp6zg5vp4tАй бұрын
Вы стоимость неправильно считаете и вводите людей в заблуждение. "Важно понимать, что стоимость узла верхнего уровня включает стоимость всех его потомков" цитата из документации postgresql.
@EugeneSuleimanovАй бұрын
@@user-cp6zg5vp4t да, вы абсолютно правы, большое спасибо за конструктивную критику. Я допустил ошибку.
@user-qm5hv2dc7h8 ай бұрын
Спасибо!🙂
@EugeneSuleimanov8 ай бұрын
Спасибо за комментарий!
@ManticoreRoko8 ай бұрын
Отличная подача материала, доступно и полезно. Вопрос: не вредно ли добавлять >1 индекса в одну таблицу в OLTP СУБД?
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв! Здесь нужно искать компромисс, ведь вставка замедлится. Но зависит от контекста задачи.
@svetlana45308 ай бұрын
Спасибо за видео! Для учебных целей очень хорошо, наглядно - многие начинающие просто пишут запросы лишь бы заработало. Оптимизация - это следующая ступень эволюции 😊 Есть ли бесплатный аналог инструмента, которым вы пользовались, доступный из России без всяких vpn-ухищрений?
@@EugeneSuleimanov спасибо, но, кажется там нет наглядного отображения плана запроса. Или есть?
@EugeneSuleimanov8 ай бұрын
@@svetlana4530 верно, только raw описание, к сожалению.
@chip2538 ай бұрын
Полное сканирование сразу понятно было. Странно описание таблиц не полное, где developer_id unsigned int not null (default допустим не нужно) - на ревью завалится. Потом created_at тоже not null default now... Про экспрес функцию многие забывают - важный аспект.
@EugeneSuleimanov8 ай бұрын
Спасибо за комментарий! Разумеется, это не «боевой» код.
@vladislavstepanov7591Ай бұрын
что не так с created_at not null default now?
@alfalf1593Ай бұрын
Я правилтно понимаю, что замена join на left join это не оптимизация, а испраление логической ошибки?
@aksndr618 ай бұрын
А можно ж было сделать функциональный индекс с экстрактом месяца по колонке с датой. Или виртуальную колонку, плюс партиционирование по ней.
@EugeneSuleimanov8 ай бұрын
Это уже не основы, а несколько более продвинутый подход. И спасибо за комментарий.
@vladislavstepanov7591Ай бұрын
смысла в этом нет, только раздувание данных в таблице
@rudolfsikorsky79005 ай бұрын
Спасибо. К сожалению, вся эта красота от JetBrains работает не со всеми БД. И если бы Евгений писал не свой большой и красивый монитор, а маленький - ноутбучный, то зрителям было бы видно гораздо лучше :)
@EugeneSuleimanov5 ай бұрын
Спасибо за комментарий! По размеру шрифта, постараюсь учесть и справить на будущее :)
@artemseleznev34696 ай бұрын
фактологическая ошибка.... косты не надо суммировать, их общая стоимость уже приведена в первой строке explain
@EugeneSuleimanov6 ай бұрын
Спасибо за уточнение!
@Krasnolesye8 ай бұрын
Со смартфона - ничего не могу разобрать, сильно мелко. А так материал - ОК. Спасибо
@EugeneSuleimanov8 ай бұрын
Спасибо за комментарий!
@Ellek1ng8 ай бұрын
Отличное видео, спасибо большое!
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв!
@ercefwxdx8 ай бұрын
Дякую
@EugeneSuleimanov8 ай бұрын
Дякую за коментар!
@Oldstav8 ай бұрын
Это просто отвратительно 2:30 Автор: Давайте выполним вот такой запрос Ответ: давайте мы не выполним такой запрос… Для того чтобы писать запросы а тем более их оптимизировать, нужна четко поставленная задача от заказчика. И где оно? Т.е. берем какой-то работающий запрос от балды из продакшина и без постановки начинает его «оптимизировать». Ты условие начальное видел, что убираешь один джоин и меняешь тип второго? Как можно менять extract на интервал, если там дата не за один год? Ну добавь 01-01-2022 и результат не сойдется. Про функциональный индекс на базе extract автор даже и не думал. Вопрос автору - куда ты лезешь ничего не понимая в предметной области и что ты хотел донести до аудитории? А потом все слушатели которые тут отлайкали начнут с таким подходом писать такой же говнокод и таким же подходом - читай со свиным рылом лезть в калашный ряд - продакшин
@EugeneSuleimanov8 ай бұрын
Спасибо за ваше мнение.
@user-ur7bn1kd1p7 ай бұрын
Всем икспердам желаю меньше пафоса. Ведь вы никогда не расскажете, как сами пока росли облажались не раз на коммерческих проектах.
@rustregas938 ай бұрын
И зачем суммировать стоимость костов? тебе последний шаг и так сумму выдал всех предыдущих шагов.
@user-tr7qp1dt3i8 ай бұрын
Спасибо за видео! Вопрос. А есть ли смысл в данном случае вместо двух индексов сделать один индекс на 2 поля (developer_id и created_at)? поскольку джойн по им обоим одновременно идет
@EugeneSuleimanov8 ай бұрын
Да, можно попробовать сделать такой индекс. Спасибо за отзыв!
@aazubakin8 ай бұрын
Получается индекс из таблицы из которой мы пишем forieng key не создается автоматом при указании связи (developer_id) а создается у той таблицы на которую ссылаемся developers_id?
@EugeneSuleimanov8 ай бұрын
Верно, Postgres не создает индекс для внешнего ключа автоматически. Автоматически создаются индексы для первичных ключей и уникальный полей.
@user-lv1wj5bv4t2 ай бұрын
А ты уверен, что показывает не сразу всю сумму поддерева?
@Kentatsu18 ай бұрын
В конечном итоге можно ведь сократить запрос до обычного селекта по таблице tasks, джоин лишний
@EugeneSuleimanov8 ай бұрын
Здесь был задел на то, что будут запрещены данные developer. Но и пример учебный.
@coolbrain8 ай бұрын
Jetbrains со своим Data Grip послал Россиию на 3 буквы насколкьо я знаю, или что то поменялось ? У меня все платные аккаунты заблочили в этом году
@alekseysverbeev29348 ай бұрын
Обзор инструментов интересный, но конечно оптимизация притянута за уши, потому что изначальный пример взят из книги "как писать не надо". Такие вещи и интуитивно понятны, никто же в здравом уме не будет сравнивать месяц в дате с единицей - это как минимум даст неверные данные (за все года). Интересно было бы посмотреть как оптимизировать запрос который большой, "всю жизнь" работал, но под увеличенными нагрузками устал.
@EugeneSuleimanov8 ай бұрын
Спасибо за комментарий! Пример как делать не нужно из палаты мер и весов :)
@paskonat8 ай бұрын
Когда невозможно придраться к форме, придираются к содержанию. Евгений, у Вас в конечный результат не попадает 1 января, и, соответственно, вся аналитика идет по другой борозде. ))
@EugeneSuleimanov8 ай бұрын
Справедливо :) Спасибо за комментарий!
@PurpleDaemon_8 ай бұрын
11:42 это опять внешний ключ, индекс и так был.
@EugeneSuleimanov8 ай бұрын
В Postgres внешний ключ по умолчанию не индексируется. Только первичный и unique constraint.
@user-dp6jy9qk5q8 ай бұрын
полная чушь расскажите хотя бы человеку, что бывает предварительный план выполнения, а бывает реальный
@EugeneSuleimanov8 ай бұрын
ИМХО для человека, который только знакомится с оптимизацией запросов - это уже не совсем основы. Более серьёзные подходы и теоретическая база требует большего времени.
@user-xg6so1kq3z8 ай бұрын
+
@EugeneSuleimanov8 ай бұрын
Спасибо за поддержку!
@N5O18 ай бұрын
неужели ютуб начал советовать нормальные материалы =)
@EugeneSuleimanov8 ай бұрын
Спасибо за комментарий!
@ThomasLinkzat8 ай бұрын
Очень мало обьяснения понятий. Что за начальная сложность, что за конечная сложность. Не обьяснили чем скобки помешали. Не обьяснили этапы которые почему то ушли после оптимизации. Очень сумбурное видео. Вам не хватает сценария чтоли. Но идея хорошая.
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв и вообще мнение!
@dmytromatvieiev89328 ай бұрын
Цікаво, що ваш сайт заблокований для доступу з України)
@EugeneSuleimanov8 ай бұрын
Проверю, спасибо за сигнал.
@user-fi9rw4vx2b3 ай бұрын
Столько глупостей наговорил. Может не стоит с такими поверхностными представлениями из чужой области лезть учить других?
@blindbird16195 ай бұрын
Странная оптимизация. "Уберем лишнюю таблицу из запроса"... Дак это так можно надобавлять в запрос 50 ненужных таблиц, а потом героически с ними справиться. Кто будет добавлять в свои запросы ненужные таблицы?
@sergeykovalev72768 ай бұрын
Евгений спасибо огромное! У вас есть ошибка в последнем запросе: должно быть created_at >= '2023-01-01', но на результат не влияет
@EugeneSuleimanov8 ай бұрын
Спасибо за отзыв! Да, уже подсказали об ошибке, спасибо :)