Чувак, ты классный учитель. Умеешь заинтересовать) До этого видео я думал "пф, ускорение какое-то, явно ерунда" , а тут ты последовательно показал как это может работать, и на сколько колоссальное ускорение. СПАСИБО )
Супер))) Создал БД, начал смотреть ваше видео и ставить индексы. В конце видео оказалось, что они не нужны, на малом кол-во записей и убрал их :-) Было очень интересно. Узнал много нового))) спасибо за ваши старания)
Все зависит от того что называть под "малым" , как правило индексы если правильно сделаны ускоряют все с размеров в 100 записей и больше . Все советы не делайте на малых базах глупы , просто померяйте , конечно может какие нибудь 50 мс для вас значения не имеют . но для частого использования и больших систем - очень . совет основывается на том что на поддержание индекса тратятся ресурсы , но они тратятся в момент записи а не чтения . а пользователю надо чтение .
попал случайно на твой курс спустя 3 года работы в разработке, просмотрел весь и кайфанул, понял некоторые вещи по новому, спасибо, ты крутой, думаю работать с тобой в роли лида было бы круто)
наконец то нечто интересное и достаточно трудно находимое в интернете. (найти то конечно можно в документации но при этом придется перелопатить кучу лишнего)
Спасибо, в этом видео звук снимали непосредственно с рекордера, в предыдущих был петличный микрофон. К сожалению, такого звука можно добиться только на скринкастах, а наш уважаемый спикер больше любит вещать вживую у телевизора :(
Ну, учитывая что сортировка займёт не менее nlg(n), если она идёт сравнением,то это как бы не lg(n)… есть ещё кстати прошитые b-tree… чуть побыстрей работают
@@Rclass Мне просто фраза понравилась, вроде говорится об ускорении, что хорошо, но при этом применяется эпитет "катастрофически" который вроде бы имеет отрицательный оттенок
Спасибо за видео! Надо было посмотреть его до прохождения собеседования, не выглядел бы тупым в вопросах индексирования. :) Хотя собеседование все же прошел) Like + Subscribe !!!
Выполняю задания. Написал запрос из предпоследнего задания: 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 индексу. Это алгоритм индексов по умолчанию в бд или мы вручную как то устанавливаем использовать индекс в рамках данного алгоритма (берём середину, разделяем, сравниваем и тп..). Мне как новичку не совсем понятно. Откуда берётся этот алгоритм.
Спасибо за видео! А если добавить новый индекс - будут ли старые записи в таблице (которые уже там были до добавления нового индекса) проиндексированы по новому индексу? (извиняюсь за тавтологию)
Здравствуйте. Скажите подалуйста, как вы нашли количество совпадений по буквам? например для буквы Z 59 совпадений я так понимаю из суммы русского и английского алфавитов(но почему без цифр еще от 0 до 9?), а как получилось всего 14 совпадений по букве Е?
а кто-нибудь может посоветовать хорошую тестовую базу с большим количество данных и "плохими" кейсами как дублирующиеся ключи и проч? например чтобы были 10 табличек на 10млн строк?
Жаль, что про составные очень мало информации в видео. Там много особенностей. Еще, если указать после EXPLAIN, format=json будет гораздо больше информации об индексах
Изначально задумано что вы так или иначе будете работать с презентацией, благо оттуда можно быстро копировать код. Поэтому ссылки изначально там и лежат)
Я не понял как получилось всего 14 проверок. То есть да, за 14 проверок мы нашли компанию ZEUS, но ведь к этой компании может быть привязано несколько тысяч товаров, то есть количество проверок в итоге точно больше 14, или я что-то неправильно понял?
Я правильно понимаю, что у СУБД есть доступ к БД, при обращении пользователя к БД через СУБД СУБД обновляет индексы, если это необходимо? Это так +- устроено?
Хотелось бы поподробнее узнать в каких случаях индекс вредит и какие расчёты при этом делаются. Просто информации о том что при вставке и ибновлении не совсем достаточно.
Добрый день! Затраты сводятся к пересчету индексов, не более. Вот только если их много или они объемные, это может занять время и ресурсы. А если взять кейс в котором вставка в таблицы с ненужными индексами будет регулярной и объемной, то можно получить уже ощутимую просадку производительности.
@@Rclassк примеру у меня есть таблица в которую постоянно летят записи и из этой таблицы у меня так же идут постоянно выборки. Записей до несколько сотен тысяч в день. Если я создаю индексы в этой таблице, то они нагружают сервер при перестроении индекса, если индексы не вставлять, то получается полный скан таблицы в которой миллионы записей. Как поступать в этом случае?
Спасибо, это вот полезно было. А про партицирование, шардирование, реплецирование я так понял нету? Хотя партицирование и шардирование редкий кейс, но тем не менее было бы думаю интересно знать что и так можно если прям много записей. К тому же это можно совмещать.
Какое нахрен log2(n), если btree НЕ ЯВЛЯЕТСЯ ни бинарным деревом поиска, ни отсортированным массивом. Автор сам ни черта не понимает в устройстве индексов и как они работают, но лезет учить других.
Это настолько офигенное видео, что я даже оставлю комент! Спасибо Вам, мужики!
Спасибо ^_^ мы старались )
@@Rclass ахах, под таким даже захотелось оставить ответ, действительно, спасибо)) очень хорошее видео!
@@ufear2569 и вам спасибо за отклик :)
Поддерживаю! Лайк или ilike '%'
@@ShomaAbd1991 Спасибо! Мы старались :)
Спасибо большое, вы даже лучше объяснили тему чем в универе!
Спасибо за отклик, мы старались 😊
Чувак, ты классный учитель. Умеешь заинтересовать)
До этого видео я думал "пф, ускорение какое-то, явно ерунда" , а тут ты последовательно показал как это может работать,
и на сколько колоссальное ускорение.
СПАСИБО )
Спасибо, мы старались ^_^
это самое лучшее видео про индексы, которое я видела. доходчивое объяснение
Спасибо, мы старались :)
По край ней мере лучше чем в вузе!) Другие видео про индексы еще не смотрел
@@kudrity в вузе о них не было ни слова. По крайней мере в моем
Супер))) Создал БД, начал смотреть ваше видео и ставить индексы. В конце видео оказалось, что они не нужны, на малом кол-во записей и убрал их :-) Было очень интересно. Узнал много нового))) спасибо за ваши старания)
Рады, что помогли ;)
аналогично)))
Все зависит от того что называть под "малым" , как правило индексы если правильно сделаны ускоряют все с размеров в 100 записей и больше . Все советы не делайте на малых базах глупы , просто померяйте , конечно может какие нибудь 50 мс для вас значения не имеют . но для частого использования и больших систем - очень . совет основывается на том что на поддержание индекса тратятся ресурсы , но они тратятся в момент записи а не чтения . а пользователю надо чтение .
Смотрел другое видео от Антона, заочно лайк! "Отдай свежатину!"
Спасибо! :)
попал случайно на твой курс спустя 3 года работы в разработке, просмотрел весь и кайфанул, понял некоторые вещи по новому, спасибо, ты крутой, думаю работать с тобой в роли лида было бы круто)
Спасибо что смотрите ^_^
наконец то нечто интересное и достаточно трудно находимое в интернете. (найти то конечно можно в документации но при этом придется перелопатить кучу лишнего)
Спасибо, мы старались :)
Дружище, спасибо за твой труд! Очень классное видео
Спасибо что смотрите, мы старались :)
Максимально качественное видео, спасибо :)
Спасибо, стараемся ^_^
Отличный ролик, много полезной инфы доступным языком! Спасибо!
Для вас стараемся ;)
Звук в этом видео ГОРАЗДО лучше, чем в предыдущих! Качество и чистота
Спасибо, в этом видео звук снимали непосредственно с рекордера, в предыдущих был петличный микрофон. К сожалению, такого звука можно добиться только на скринкастах, а наш уважаемый спикер больше любит вещать вживую у телевизора :(
Как-то запускал explain и смотрел на него, как баран на новые ворота. Теперь все ясно. Спасибо!
О сколько нам открытий чудных готовит этот SQL...
Ну, учитывая что сортировка займёт не менее nlg(n), если она идёт сравнением,то это как бы не lg(n)… есть ещё кстати прошитые b-tree… чуть побыстрей работают
Реально лучшее объяснение по индексам, спасибо)
Стараемся для вас :)
Да ладно наконец то я нашел нормальное объяснение индексов , спасибо!
Спасибо, мы старались)
Просто красавчик, спасибо! С меня подписка и лайк)
Ай спасибо!
Огроменное спасибо за урок. Чётко, лаконично, по существу без лишней воды.
Спасибо, мы старались ^_^
5:40 - Катастрофически сильное ускорение. Так хорошо что аж плохо
Не очень понятно что имеется ввиду(
@@Rclass Мне просто фраза понравилась, вроде говорится об ускорении, что хорошо, но при этом применяется эпитет "катастрофически" который вроде бы имеет отрицательный оттенок
@@43Dipall23 а) ну, есть такое, да :)
Спасибо за видео! Надо было посмотреть его до прохождения собеседования, не выглядел бы тупым в вопросах индексирования. :) Хотя собеседование все же прошел) Like + Subscribe !!!
Спасибо, мы старались :)
Очень подробно про крайне важную тему!
Спасибо
Спасибо, мы старались :)
Лайк,подписка! Начинаю смотреть и изучать остальные видосы
Спасибо, мы старались :)
Спасибо, очень крутое объяснение! Пойду смотреть другие видео
Спасибо, мы старались :)
Очень просто и понятно объяснил, большое спасибо!
Спасибо, мы старались :)
Ну очень круто все объяснил и рассказал!
Спасибо большое, стараемся. ^_^
Спасибо! Привет всем СПшникам)
Спасибо что смотрите :)
Урок огонь! Спасибо Вам!
Для вас стараемся :)
У нас тоже не восьмерка)) ничего живем. Да explain analyse очень крутая штука и да, в любой СУБД надо следить на индексами, особенно в Postgres
Под каждым словом подписались )
Спасибо! очень полезный урок!
Спасибо, мы рады что вам понравилось!
Супер, спасибо за видео!
Так это ж! структура данных - дерево поиска.
не зря сдавал СИАОД (Структуры и алгоритмы обработки данных)
Именно так! :)
Спасибо очень крутое видео, все просто и понятно 🙏🏻🌹 Процветания каналу
Спасибо, мы старались :)
Очень крутое видео, спасибо!
Спасибо, мы старались :)
Выполняю задания.
Написал запрос из предпоследнего задания:
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 привет, видео топ
Спасибо! Мы старались)
12:00 Категория и цена
Спасибочки!!! Годное видео ❤️
Спасибо, мы старались :)
Понятно и приятно!
Спасибо 🙏
Спасибо, мы старались :)
Спасибо за видео и практику!
Вам спасибо за отклик :) Стараемся ^_^
Без воды ! Можно вынести ссылки на доп. источники в описание видео ? Также было бы удобнее расставлять time-коды по ролику
Спасибо! Да, будем работать над этим.
Спасибо! Прекрасное объяснение! 👍
Спасибо, мы старались :)
да, просто офигенно)) лайк от СЕООНЛИ - топового вебмастера и проггера
спасибо, мы старались :)
Отдельное спасибо за базу))
Вам спасибо) Мы старались ^_^
Как к ней подключиться ?
У менее уникальных колонок, выше селективность (использовать первыми) 16:02
Вы гений!
Спасибо большое, мы старались :)
А можно как то посмотреть что находится в B-tree? Запросом может каким то?
Действительно стало понятно
Спасибо, мы старались :)
на 8:29 сказано, что log2(1)=1. Это не верно - log2(1)=0
Ага, обсчитались видимо. Спасибо :)
Как понять как часто используется тот или иной индекс ?
Хорошо было бы ссылки из презентации в описании оставить👌
Спасибо, но один момент не понятен. По b-tree индексу. Это алгоритм индексов по умолчанию в бд или мы вручную как то устанавливаем использовать индекс в рамках данного алгоритма (берём середину, разделяем, сравниваем и тп..). Мне как новичку не совсем понятно. Откуда берётся этот алгоритм.
Спасибо за видео! А если добавить новый индекс - будут ли старые записи в таблице (которые уже там были до добавления нового индекса) проиндексированы по новому индексу? (извиняюсь за тавтологию)
Да, конечно. Запрос не завершится, пока не будут проиндексированы все записи. Иногда это весьма не быстрый процесс)
8:35 - вы же обещали ускорение в 428 000 (!) раз, а получили 1.8 сек / 0.037 сек - меньше чем в 50 раз. Как так?
Стоит объяснять что такое концепция и реализация и в чем их отличие?
Спасибо, все очень понятно
Спасибо за отклик, мы старались ^_^
Спасибо круто объяснил, а есть ссылка на базу которая использовалась в уроке? потому что ссылка в описании на другую базу
Пожалуйста, увы, уже нет(
Спасибо за видео
Спасибо,мы старались :)
в конце ссылки есть, что нужно почитать, а в описании их нет. где их можно найти?
Презентация приложена к каждому видео, там ссылки кликабельные :)
@@Rclass а, ого, вотета технологи на пыхе
Вынесите пожалуйста ссылки на доп. источники
Ждём стрим
Мужик, красава!
Ай спасибо :)
Как бинарный поиск работает с буквами?
Немного не поняли в чем сложность? Слова = массив чисел (грубо). А с числами проблем нет - бери и сравнивай/сортируй.
Здравствуйте. Скажите подалуйста, как вы нашли количество совпадений по буквам? например для буквы Z 59 совпадений я так понимаю из суммы русского и английского алфавитов(но почему без цифр еще от 0 до 9?), а как получилось всего 14 совпадений по букве Е?
Это касается выборок исключительно из тестовой базы. На ней именно такое количество совпадений по первой букве Z, по второй E и так далее :)
а кто-нибудь может посоветовать хорошую тестовую базу с большим количество данных и "плохими" кейсами как дублирующиеся ключи и проч? например чтобы были 10 табличек на 10млн строк?
Возможно, проще сгенерировать таковую. Займет это не так много времени, зато будет полностью отвечать вашим требованиям.
Жаль, что про составные очень мало информации в видео. Там много особенностей. Еще, если указать после EXPLAIN, format=json будет гораздо больше информации об индексах
Спасибо за комментарий :) Курс скорее вводный, поэтому много чего нет )
Оставьте ссылки из "Прочитать и изучить" в комментариях или в описании видео.
Не возможно такое набрать или скопировать.
Изначально задумано что вы так или иначе будете работать с презентацией, благо оттуда можно быстро копировать код. Поэтому ссылки изначально там и лежат)
@@Rclass да, Я так и сделал потом, но вот первая ссылка уже не работает.
Полезно. Спасибо!
Спасибо что смотрите :)
Я не понял как получилось всего 14 проверок. То есть да, за 14 проверок мы нашли компанию ZEUS, но ведь к этой компании может быть привязано несколько тысяч товаров, то есть количество проверок в итоге точно больше 14, или я что-то неправильно понял?
Я правильно понимаю, что у СУБД есть доступ к БД, при обращении пользователя к БД через СУБД СУБД обновляет индексы, если это необходимо? Это так +- устроено?
Достаточно сложно представить себе ситуацию когда вы будете обращаться к БД минуя СУБД. +- при определенном приближении да, вы правы.
Если у нас составной индекс (price+category) важен ли порядок колонок в запросе в секции where ?
mysql сам может переставлять порядок запросов в where
11:48 думаю что (цена, категория)
ееес!
еще 10 таких и мидл
Хотелось бы поподробнее узнать в каких случаях индекс вредит и какие расчёты при этом делаются. Просто информации о том что при вставке и ибновлении не совсем достаточно.
Добрый день! Затраты сводятся к пересчету индексов, не более. Вот только если их много или они объемные, это может занять время и ресурсы. А если взять кейс в котором вставка в таблицы с ненужными индексами будет регулярной и объемной, то можно получить уже ощутимую просадку производительности.
Некорректный индекс даже при выборках может чуть-чуть вредить, иногда full scan будет быстрее.
@@Rclassк примеру у меня есть таблица в которую постоянно летят записи и из этой таблицы у меня так же идут постоянно выборки. Записей до несколько сотен тысяч в день. Если я создаю индексы в этой таблице, то они нагружают сервер при перестроении индекса, если индексы не вставлять, то получается полный скан таблицы в которой миллионы записей. Как поступать в этом случае?
@@user_noname_78dgdh если польза от индексов очевидна в вашем случае - то пользоваться, как же иначе :)
класс! воды нет
Спасибо, мы старались! :)
Лойс
Спасибо, мы старались :)
шик
Разница между 0,8 мс и 0,9 смахивает на погрешность.
Хорошее замечание, это усреднённые значения после 20 прогонов. Тенденция прослеживается на самом деле :)
в UTF-8 максимальное количество байт = 4, а у вас сказано 3
Спасибо за отклик, обязательно разберемся.
в MySQL utf8 3 байтовый, урезанный, utf8mb4 - 4 байтовый, полный. Так что все верно.
Попробовал сделать как рассказано тут, скорость обработки запроса снизилась с 6с до 70мс! Как такое возможно в реальной то жизни?!
Скорость увеличилась
если база из 100 строк, то накладные расходы субд на индексы будут выше, чем перебор 100 строк)
Интересно, что есть скорости доступа менее 1 мс…
Спасибо, это вот полезно было. А про партицирование, шардирование, реплецирование я так понял нету? Хотя партицирование и шардирование редкий кейс, но тем не менее было бы думаю интересно знать что и так можно если прям много записей. К тому же это можно совмещать.
Курс скорее ознакомительный, поэтому таких кейсов нет, к сожалению.
Вроде это называетсо бинарный поезг а не B-tree индегз, или я штотапутаю?
Принцип B-tree индегза основан на бинарном поезге, всёнорм
Смотреть на скорости 1.5
Издержки онлайн-лекции, к сожалению :(
исключительно на х2 смотрю 99% обучающих видео
Какое нахрен log2(n), если btree НЕ ЯВЛЯЕТСЯ ни бинарным деревом поиска, ни отсортированным массивом. Автор сам ни черта не понимает в устройстве индексов и как они работают, но лезет учить других.
С удовольствием ознакомимся с материалами на вашем канале)
видео ни о чем, как и все у данного автора
Ух ты, Хейтеры! 😄
Базы - это не ваше ... это крайне примитивный взгляд .
Спасибо за ваше мнение, мы обязательно его учтём, без сомнения!
@@Rclass вы заводите в заблуждение подписчиков . с точки зрения человека который работает с терабайтными базами - 50% вашего видео полная дичь .
с вендором эти пример кластерного или не кластерного индекса?
"Указания покрытия, про это отдельно почитайте" 😅😅😅, где блин?
Очень полезно, спасибо!
Спасибо, мы старались :)