Чувак, ты классный учитель. Умеешь заинтересовать) До этого видео я думал "пф, ускорение какое-то, явно ерунда" , а тут ты последовательно показал как это может работать, и на сколько колоссальное ускорение. СПАСИБО )
Супер))) Создал БД, начал смотреть ваше видео и ставить индексы. В конце видео оказалось, что они не нужны, на малом кол-во записей и убрал их :-) Было очень интересно. Узнал много нового))) спасибо за ваши старания)
Все зависит от того что называть под "малым" , как правило индексы если правильно сделаны ускоряют все с размеров в 100 записей и больше . Все советы не делайте на малых базах глупы , просто померяйте , конечно может какие нибудь 50 мс для вас значения не имеют . но для частого использования и больших систем - очень . совет основывается на том что на поддержание индекса тратятся ресурсы , но они тратятся в момент записи а не чтения . а пользователю надо чтение .
попал случайно на твой курс спустя 3 года работы в разработке, просмотрел весь и кайфанул, понял некоторые вещи по новому, спасибо, ты крутой, думаю работать с тобой в роли лида было бы круто)
Спасибо, в этом видео звук снимали непосредственно с рекордера, в предыдущих был петличный микрофон. К сожалению, такого звука можно добиться только на скринкастах, а наш уважаемый спикер больше любит вещать вживую у телевизора :(
наконец то нечто интересное и достаточно трудно находимое в интернете. (найти то конечно можно в документации но при этом придется перелопатить кучу лишнего)
Ну, учитывая что сортировка займёт не менее nlg(n), если она идёт сравнением,то это как бы не lg(n)… есть ещё кстати прошитые b-tree… чуть побыстрей работают
Спасибо за видео! Надо было посмотреть его до прохождения собеседования, не выглядел бы тупым в вопросах индексирования. :) Хотя собеседование все же прошел) Like + Subscribe !!!
@@Rclass Мне просто фраза понравилась, вроде говорится об ускорении, что хорошо, но при этом применяется эпитет "катастрофически" который вроде бы имеет отрицательный оттенок
Выполняю задания. Написал запрос из предпоследнего задания: select * from workers where role ='инженер' and birthday between '1979-12-01' and '1980-02-01' order by first_name, last_name; Проверка показала, роли имеют в среднем по 10к записей на роль, даты - по 100. Из чего получается логично сделать индекс birthday, role. Однако на деле индекс birthday, role дает результат (cost=6349.76 rows=14110) (actual time=6.038..6.097 rows=71 loops=1) , в то время как role, birthday (cost=32.21 rows=71) (actual time=0.749..0.805 rows=71 loops=1). Правильно понимаю, что это связано с between, а точнее с тем, что он собирает большое кол-во дат, а после по ним производит поиск и находит еще тучу ролей, в время как при role, birthday роли сокращают список возможных дат и идет проверка уже среди набора дат?
Первое , использовать строки это означает снизить скорость в разы . пропорционально размеру ключа . потому лучше иметь отдельную таблицу под роли , а в основной таблице использовать только int значение ,. теперь второй вопрос - почему так с индексом случилось - тебе дяди что видео сделали врядли ответят , потому что в postgres поле по которому выбирается range , т.е. between или A > 100 and A < 300 , должно идти последним в индексе . только в этом случае будет задействован индекс как index scan , в противном случае это или seq scan или bitmap scan . но этого дяди не знают , это не ихнее .
Спасибо, но один момент не понятен. По b-tree индексу. Это алгоритм индексов по умолчанию в бд или мы вручную как то устанавливаем использовать индекс в рамках данного алгоритма (берём середину, разделяем, сравниваем и тп..). Мне как новичку не совсем понятно. Откуда берётся этот алгоритм.
Жаль, что про составные очень мало информации в видео. Там много особенностей. Еще, если указать после EXPLAIN, format=json будет гораздо больше информации об индексах
Спасибо за видео! А если добавить новый индекс - будут ли старые записи в таблице (которые уже там были до добавления нового индекса) проиндексированы по новому индексу? (извиняюсь за тавтологию)
Здравствуйте. Скажите подалуйста, как вы нашли количество совпадений по буквам? например для буквы Z 59 совпадений я так понимаю из суммы русского и английского алфавитов(но почему без цифр еще от 0 до 9?), а как получилось всего 14 совпадений по букве Е?
Я не понял как получилось всего 14 проверок. То есть да, за 14 проверок мы нашли компанию ZEUS, но ведь к этой компании может быть привязано несколько тысяч товаров, то есть количество проверок в итоге точно больше 14, или я что-то неправильно понял?
Я правильно понимаю, что у СУБД есть доступ к БД, при обращении пользователя к БД через СУБД СУБД обновляет индексы, если это необходимо? Это так +- устроено?
Изначально задумано что вы так или иначе будете работать с презентацией, благо оттуда можно быстро копировать код. Поэтому ссылки изначально там и лежат)
а кто-нибудь может посоветовать хорошую тестовую базу с большим количество данных и "плохими" кейсами как дублирующиеся ключи и проч? например чтобы были 10 табличек на 10млн строк?
Хотелось бы поподробнее узнать в каких случаях индекс вредит и какие расчёты при этом делаются. Просто информации о том что при вставке и ибновлении не совсем достаточно.
Добрый день! Затраты сводятся к пересчету индексов, не более. Вот только если их много или они объемные, это может занять время и ресурсы. А если взять кейс в котором вставка в таблицы с ненужными индексами будет регулярной и объемной, то можно получить уже ощутимую просадку производительности.
@@Rclassк примеру у меня есть таблица в которую постоянно летят записи и из этой таблицы у меня так же идут постоянно выборки. Записей до несколько сотен тысяч в день. Если я создаю индексы в этой таблице, то они нагружают сервер при перестроении индекса, если индексы не вставлять, то получается полный скан таблицы в которой миллионы записей. Как поступать в этом случае?
Спасибо, это вот полезно было. А про партицирование, шардирование, реплецирование я так понял нету? Хотя партицирование и шардирование редкий кейс, но тем не менее было бы думаю интересно знать что и так можно если прям много записей. К тому же это можно совмещать.
Какое нахрен log2(n), если btree НЕ ЯВЛЯЕТСЯ ни бинарным деревом поиска, ни отсортированным массивом. Автор сам ни черта не понимает в устройстве индексов и как они работают, но лезет учить других.
Это настолько офигенное видео, что я даже оставлю комент! Спасибо Вам, мужики!
Спасибо ^_^ мы старались )
@@Rclass ахах, под таким даже захотелось оставить ответ, действительно, спасибо)) очень хорошее видео!
@@ufear2569 и вам спасибо за отклик :)
Поддерживаю! Лайк или ilike '%'
@@ShomaAbd1991 Спасибо! Мы старались :)
Чувак, ты классный учитель. Умеешь заинтересовать)
До этого видео я думал "пф, ускорение какое-то, явно ерунда" , а тут ты последовательно показал как это может работать,
и на сколько колоссальное ускорение.
СПАСИБО )
Спасибо, мы старались ^_^
это самое лучшее видео про индексы, которое я видела. доходчивое объяснение
Спасибо, мы старались :)
По край ней мере лучше чем в вузе!) Другие видео про индексы еще не смотрел
@@kudrity в вузе о них не было ни слова. По крайней мере в моем
Супер))) Создал БД, начал смотреть ваше видео и ставить индексы. В конце видео оказалось, что они не нужны, на малом кол-во записей и убрал их :-) Было очень интересно. Узнал много нового))) спасибо за ваши старания)
Рады, что помогли ;)
аналогично)))
Все зависит от того что называть под "малым" , как правило индексы если правильно сделаны ускоряют все с размеров в 100 записей и больше . Все советы не делайте на малых базах глупы , просто померяйте , конечно может какие нибудь 50 мс для вас значения не имеют . но для частого использования и больших систем - очень . совет основывается на том что на поддержание индекса тратятся ресурсы , но они тратятся в момент записи а не чтения . а пользователю надо чтение .
Дружище, спасибо за твой труд! Очень классное видео
Спасибо что смотрите, мы старались :)
Максимально качественное видео, спасибо :)
Спасибо, стараемся ^_^
попал случайно на твой курс спустя 3 года работы в разработке, просмотрел весь и кайфанул, понял некоторые вещи по новому, спасибо, ты крутой, думаю работать с тобой в роли лида было бы круто)
Спасибо что смотрите ^_^
Смотрел другое видео от Антона, заочно лайк! "Отдай свежатину!"
Спасибо! :)
Звук в этом видео ГОРАЗДО лучше, чем в предыдущих! Качество и чистота
Спасибо, в этом видео звук снимали непосредственно с рекордера, в предыдущих был петличный микрофон. К сожалению, такого звука можно добиться только на скринкастах, а наш уважаемый спикер больше любит вещать вживую у телевизора :(
наконец то нечто интересное и достаточно трудно находимое в интернете. (найти то конечно можно в документации но при этом придется перелопатить кучу лишнего)
Спасибо, мы старались :)
Реально лучшее объяснение по индексам, спасибо)
Стараемся для вас :)
Как-то запускал explain и смотрел на него, как баран на новые ворота. Теперь все ясно. Спасибо!
О сколько нам открытий чудных готовит этот SQL...
Отличный ролик, много полезной инфы доступным языком! Спасибо!
Для вас стараемся ;)
Ну, учитывая что сортировка займёт не менее nlg(n), если она идёт сравнением,то это как бы не lg(n)… есть ещё кстати прошитые b-tree… чуть побыстрей работают
Огроменное спасибо за урок. Чётко, лаконично, по существу без лишней воды.
Спасибо, мы старались ^_^
Просто красавчик, спасибо! С меня подписка и лайк)
Ай спасибо!
Да ладно наконец то я нашел нормальное объяснение индексов , спасибо!
Спасибо, мы старались)
Очень подробно про крайне важную тему!
Спасибо
Спасибо, мы старались :)
Очень просто и понятно объяснил, большое спасибо!
Спасибо, мы старались :)
Урок огонь! Спасибо Вам!
Для вас стараемся :)
Так это ж! структура данных - дерево поиска.
не зря сдавал СИАОД (Структуры и алгоритмы обработки данных)
Именно так! :)
Спасибо, очень крутое объяснение! Пойду смотреть другие видео
Спасибо, мы старались :)
Спасибо за видео! Надо было посмотреть его до прохождения собеседования, не выглядел бы тупым в вопросах индексирования. :) Хотя собеседование все же прошел) Like + Subscribe !!!
Спасибо, мы старались :)
Ну очень круто все объяснил и рассказал!
Спасибо большое, стараемся. ^_^
У нас тоже не восьмерка)) ничего живем. Да explain analyse очень крутая штука и да, в любой СУБД надо следить на индексами, особенно в Postgres
Под каждым словом подписались )
Лайк,подписка! Начинаю смотреть и изучать остальные видосы
Спасибо, мы старались :)
Супер, спасибо за видео!
Спасибо! Привет всем СПшникам)
Спасибо что смотрите :)
Без воды ! Можно вынести ссылки на доп. источники в описание видео ? Также было бы удобнее расставлять time-коды по ролику
Спасибо! Да, будем работать над этим.
Хорошо было бы ссылки из презентации в описании оставить👌
5:40 - Катастрофически сильное ускорение. Так хорошо что аж плохо
Не очень понятно что имеется ввиду(
@@Rclass Мне просто фраза понравилась, вроде говорится об ускорении, что хорошо, но при этом применяется эпитет "катастрофически" который вроде бы имеет отрицательный оттенок
@@43Dipall23 а) ну, есть такое, да :)
Спасибо за отличное объяснение!
Всегда пожалуйста :)
Спасибочки!!! Годное видео ❤️
Спасибо, мы старались :)
да, просто офигенно)) лайк от СЕООНЛИ - топового вебмастера и проггера
спасибо, мы старались :)
Спасибо очень крутое видео, все просто и понятно 🙏🏻🌹 Процветания каналу
Спасибо, мы старались :)
Очень крутое видео, спасибо!
Спасибо, мы старались :)
Выполняю задания.
Написал запрос из предпоследнего задания:
select * from workers
where role ='инженер' and birthday between '1979-12-01' and '1980-02-01' order by first_name, last_name;
Проверка показала, роли имеют в среднем по 10к записей на роль, даты - по 100.
Из чего получается логично сделать индекс birthday, role.
Однако на деле индекс birthday, role дает результат (cost=6349.76 rows=14110) (actual time=6.038..6.097 rows=71 loops=1) , в то время как role, birthday (cost=32.21 rows=71) (actual time=0.749..0.805 rows=71 loops=1).
Правильно понимаю, что это связано с between, а точнее с тем, что он собирает большое кол-во дат, а после по ним производит поиск и находит еще тучу ролей, в время как при role, birthday роли сокращают список возможных дат и идет проверка уже среди набора дат?
Первое , использовать строки это означает снизить скорость в разы . пропорционально размеру ключа . потому лучше иметь отдельную таблицу под роли , а в основной таблице использовать только int значение ,. теперь второй вопрос - почему так с индексом случилось - тебе дяди что видео сделали врядли ответят , потому что в postgres поле по которому выбирается range , т.е. between или A > 100 and A < 300 , должно идти последним в индексе . только в этом случае будет задействован индекс как index scan , в противном случае это или seq scan или bitmap scan . но этого дяди не знают , это не ихнее .
Понятно и приятно!
Спасибо 🙏
Спасибо, мы старались :)
Огромное спасибо! Однозначно ЛАЙК.
Спасибо, мы старались!
Вы гений!
Спасибо большое, мы старались :)
Спасибо! очень полезный урок!
Спасибо, мы рады что вам понравилось!
Мужик, красава!
Ай спасибо :)
Отдельное спасибо за базу))
Вам спасибо) Мы старались ^_^
Как к ней подключиться ?
Спасибо за видео и практику!
Вам спасибо за отклик :) Стараемся ^_^
из 2021 привет, видео топ
Спасибо! Мы старались)
Спасибо за видео, очень доступно и понятно
Благодарим за сей приятный отзыв!
А можно как то посмотреть что находится в B-tree? Запросом может каким то?
Как понять как часто используется тот или иной индекс ?
Спасибо, но один момент не понятен. По b-tree индексу. Это алгоритм индексов по умолчанию в бд или мы вручную как то устанавливаем использовать индекс в рамках данного алгоритма (берём середину, разделяем, сравниваем и тп..). Мне как новичку не совсем понятно. Откуда берётся этот алгоритм.
Спасибо! Прекрасное объяснение! 👍
Спасибо, мы старались :)
Действительно стало понятно
Спасибо, мы старались :)
Спасибо за видео
Спасибо,мы старались :)
Жаль, что про составные очень мало информации в видео. Там много особенностей. Еще, если указать после EXPLAIN, format=json будет гораздо больше информации об индексах
Спасибо за комментарий :) Курс скорее вводный, поэтому много чего нет )
Спасибо за видео! А если добавить новый индекс - будут ли старые записи в таблице (которые уже там были до добавления нового индекса) проиндексированы по новому индексу? (извиняюсь за тавтологию)
Да, конечно. Запрос не завершится, пока не будут проиндексированы все записи. Иногда это весьма не быстрый процесс)
Полезно. Спасибо!
Спасибо что смотрите :)
Спасибо, все очень понятно
Спасибо за отклик, мы старались ^_^
в конце ссылки есть, что нужно почитать, а в описании их нет. где их можно найти?
Презентация приложена к каждому видео, там ссылки кликабельные :)
@@Rclass а, ого, вотета технологи на пыхе
Спасибо круто объяснил, а есть ссылка на базу которая использовалась в уроке? потому что ссылка в описании на другую базу
Пожалуйста, увы, уже нет(
Ждём стрим
Вынесите пожалуйста ссылки на доп. источники
Как бинарный поиск работает с буквами?
Немного не поняли в чем сложность? Слова = массив чисел (грубо). А с числами проблем нет - бери и сравнивай/сортируй.
Здравствуйте. Скажите подалуйста, как вы нашли количество совпадений по буквам? например для буквы Z 59 совпадений я так понимаю из суммы русского и английского алфавитов(но почему без цифр еще от 0 до 9?), а как получилось всего 14 совпадений по букве Е?
Это касается выборок исключительно из тестовой базы. На ней именно такое количество совпадений по первой букве Z, по второй E и так далее :)
Я не понял как получилось всего 14 проверок. То есть да, за 14 проверок мы нашли компанию ZEUS, но ведь к этой компании может быть привязано несколько тысяч товаров, то есть количество проверок в итоге точно больше 14, или я что-то неправильно понял?
на 8:29 сказано, что log2(1)=1. Это не верно - log2(1)=0
Ага, обсчитались видимо. Спасибо :)
Я правильно понимаю, что у СУБД есть доступ к БД, при обращении пользователя к БД через СУБД СУБД обновляет индексы, если это необходимо? Это так +- устроено?
Достаточно сложно представить себе ситуацию когда вы будете обращаться к БД минуя СУБД. +- при определенном приближении да, вы правы.
Лойс
Спасибо, мы старались :)
У менее уникальных колонок, выше селективность (использовать первыми) 16:02
Если у нас составной индекс (price+category) важен ли порядок колонок в запросе в секции where ?
mysql сам может переставлять порядок запросов в where
8:35 - вы же обещали ускорение в 428 000 (!) раз, а получили 1.8 сек / 0.037 сек - меньше чем в 50 раз. Как так?
Стоит объяснять что такое концепция и реализация и в чем их отличие?
Оставьте ссылки из "Прочитать и изучить" в комментариях или в описании видео.
Не возможно такое набрать или скопировать.
Изначально задумано что вы так или иначе будете работать с презентацией, благо оттуда можно быстро копировать код. Поэтому ссылки изначально там и лежат)
@@Rclass да, Я так и сделал потом, но вот первая ссылка уже не работает.
а кто-нибудь может посоветовать хорошую тестовую базу с большим количество данных и "плохими" кейсами как дублирующиеся ключи и проч? например чтобы были 10 табличек на 10млн строк?
Возможно, проще сгенерировать таковую. Займет это не так много времени, зато будет полностью отвечать вашим требованиям.
еще 10 таких и мидл
Хотелось бы поподробнее узнать в каких случаях индекс вредит и какие расчёты при этом делаются. Просто информации о том что при вставке и ибновлении не совсем достаточно.
Добрый день! Затраты сводятся к пересчету индексов, не более. Вот только если их много или они объемные, это может занять время и ресурсы. А если взять кейс в котором вставка в таблицы с ненужными индексами будет регулярной и объемной, то можно получить уже ощутимую просадку производительности.
Некорректный индекс даже при выборках может чуть-чуть вредить, иногда full scan будет быстрее.
@@Rclassк примеру у меня есть таблица в которую постоянно летят записи и из этой таблицы у меня так же идут постоянно выборки. Записей до несколько сотен тысяч в день. Если я создаю индексы в этой таблице, то они нагружают сервер при перестроении индекса, если индексы не вставлять, то получается полный скан таблицы в которой миллионы записей. Как поступать в этом случае?
@@user_noname_78dgdh если польза от индексов очевидна в вашем случае - то пользоваться, как же иначе :)
класс! воды нет
Спасибо, мы старались! :)
12:00 Категория и цена
Разница между 0,8 мс и 0,9 смахивает на погрешность.
Хорошее замечание, это усреднённые значения после 20 прогонов. Тенденция прослеживается на самом деле :)
Попробовал сделать как рассказано тут, скорость обработки запроса снизилась с 6с до 70мс! Как такое возможно в реальной то жизни?!
Скорость увеличилась
если база из 100 строк, то накладные расходы субд на индексы будут выше, чем перебор 100 строк)
Интересно, что есть скорости доступа менее 1 мс…
11:48 думаю что (цена, категория)
ееес!
Спасибо, это вот полезно было. А про партицирование, шардирование, реплецирование я так понял нету? Хотя партицирование и шардирование редкий кейс, но тем не менее было бы думаю интересно знать что и так можно если прям много записей. К тому же это можно совмещать.
Курс скорее ознакомительный, поэтому таких кейсов нет, к сожалению.
в UTF-8 максимальное количество байт = 4, а у вас сказано 3
Спасибо за отклик, обязательно разберемся.
в MySQL utf8 3 байтовый, урезанный, utf8mb4 - 4 байтовый, полный. Так что все верно.
Смотреть на скорости 1.5
Издержки онлайн-лекции, к сожалению :(
исключительно на х2 смотрю 99% обучающих видео
Вроде это называетсо бинарный поезг а не B-tree индегз, или я штотапутаю?
Принцип B-tree индегза основан на бинарном поезге, всёнорм
видео ни о чем, как и все у данного автора
Ух ты, Хейтеры! 😄
Какое нахрен log2(n), если btree НЕ ЯВЛЯЕТСЯ ни бинарным деревом поиска, ни отсортированным массивом. Автор сам ни черта не понимает в устройстве индексов и как они работают, но лезет учить других.
С удовольствием ознакомимся с материалами на вашем канале)
Базы - это не ваше ... это крайне примитивный взгляд .
Спасибо за ваше мнение, мы обязательно его учтём, без сомнения!
@@Rclass вы заводите в заблуждение подписчиков . с точки зрения человека который работает с терабайтными базами - 50% вашего видео полная дичь .
с вендором эти пример кластерного или не кластерного индекса?
"Указания покрытия, про это отдельно почитайте" 😅😅😅, где блин?
Очень полезно, спасибо!
Спасибо, мы старались :)