ИНДЕКСЫ В БАЗАХ ДАННЫХ. СОБЕС В OZON.

2024 ж. 22 Мам.
37 611 Рет қаралды

Записи реальных собесов и полезную инфу для подготовки можно найти на бусти boosty.to/vanyaio
Второе видео: Как устроен B-TREE индекс в базах данных • Как устроен B-TREE инд...
Третье видео: EXPLAIN в базах данных за 10 минут boosty.to/vanyaio/posts/1de60...
0:00 Медленный запрос
0:55 Что такое индекс, создание простого индекса
1:55 Индекс над первичным ключем
2:55 Задача на собесе в озон
4:25 Составные индексы
7:52 Индексы и ORDER BY
9:40 Подбираем индексы для задачи
11:30 Порядок колонок в индексе при равенствах
12:10 Селективность колонки
15:05 Сравниваем индексы
20:30 Выкидываем неселективную колонку
22:50 Применяем теорию
25:20 Важность природы данных
27:05 Частичные индексы
28:00 Финальное сравнение
32:53 Выводы

Пікірлер
  • Чет орнул на моменте, когда автор решил найти Лену Головач

    @Nearfulz@Nearfulz2 ай бұрын
  • Уже хз сколько времени все обещал себе поиграться с базой и разобраться в индексах, а тут Ванька все по полочкам разложил. Спасибо, родной!

    @alexmalex7689@alexmalex76893 ай бұрын
  • Классное видео! Только начал разбираться с индексами и наткнулся на это объяснение. Очень наглядно, твои эксперименты с индексами помогли мне понять материал из статей с теорией. Спасибо! )

    @alexzav1327@alexzav13273 ай бұрын
  • Хороший контент, попался в рекомендациях. Определенно подписка. Так держать!

    @user-xb4fs1ye9i@user-xb4fs1ye9i2 ай бұрын
  • Спасибо, очень классное видео!

    @sovrinfo@sovrinfo2 ай бұрын
  • Хороший материал, красавчик

    @dy0mber847@dy0mber8473 ай бұрын
  • Подписка за юмор и жизу. Круто, что такие видео попадают в реко.

    @in_ads_we_trust@in_ads_we_trustАй бұрын
  • Спасибо большое. Очень вовремя попалось выше видео

    @megaShvil@megaShvilАй бұрын
  • Хорошее видео. Лайк в поддержку!

    @user-qp3lt4ps8c@user-qp3lt4ps8c2 ай бұрын
  • чел видосы огонь, юмор тоже огонь!

    @user-lu7mm8bw1m@user-lu7mm8bw1mАй бұрын
  • Получил оффер на синьора в озоне. Вообще по БД вопросов не было...За видео спасибо, всегда интересно

    @scruper@scruper3 ай бұрын
    • Можно немного подробнее о том, что было )

      @alexzav1327@alexzav13273 ай бұрын
    • по чём нынче сеньёр-помидор?

      @neo1647@neo16472 ай бұрын
    • а что было? рассказал б в двух словах

      @EvgeniiSuvorov@EvgeniiSuvorov2 ай бұрын
    • А это на GO? Или Java

      @floydmayweather6934@floydmayweather69342 ай бұрын
  • Спасибо

    @purgalimited@purgalimited2 ай бұрын
  • информация полезная, спасибо! ​ Не было ничего сказано про сбор статистики, мне кажется после создания индекса лучше это делать принудительно ( ANALYZE employee;). В некоторых случаях планировщик не будет использовать индекс без актуальной статистики. Процесс сбора может и в фоне позже пройти

    @user-vi2qk6tm4l@user-vi2qk6tm4l2 ай бұрын
  • Из моего опыта классный повод использовать частичный индекс - это поиск по пользователям с редкой ролью (в моём случае это была dev роль, но бывают ещё всякие админы и суперпользователи).

    @vryaboshapko@vryaboshapko3 ай бұрын
  • То что нужно

    @jordenskraften8273@jordenskraften82733 ай бұрын
  • Я когда индексы объясняю, всегда привожу в аналогию бумажный индекс (который алфавитный указатель у нас называется). Ну, что по сути индекс - это просто те же данные, отсортированные по-другому, и способ быстро прыгать у нужной части. Можно эксельку взять, сортировать по-разному, и показывать. Например селективность - сортируешь по sex, и видишь что у тебя тупо по 100500 девочек и мальчиков, и дальше - перебор. Или что можно отсортировать по salary или по created date - и там будет понятно что в одном случае потом сортировать придется, а во втором - фильтровать по salary, и совместить нельзя. Опять же можно фильтры включить и сказать что можно частичные индексы сделать, скажем включить сразу людей с salary>150 и отсортировать по created_date - и будет сразу результат, но только для этого частного случая.

    @yakovzh@yakovzh3 ай бұрын
  • В последнем примере скорее подошёл бы индекс create index on employee (age) where salary > 995000;

    @alexfilus@alexfilus3 ай бұрын
  • Спасибо, хорошее видео, но думаю, нужно больше примеров и обьяснений. Например, когда ты говоришь, что у селери большая разница в кол-ве строк с 995000 и 999900, то можно было бы сделать select с этим условием и показать, думаю станет намного наглядней В остальном видео супер, спасибо

    @lellel5521@lellel5521Ай бұрын
  • После 15:58 подписался)))

    @user-dz6xu1de4b@user-dz6xu1de4bАй бұрын
  • Головачлену это гениально 😂

    @crazy_fedor@crazy_fedor3 ай бұрын
  • дякую

    @TLK3693@TLK36933 ай бұрын
    • Не за что, хохлик❤

      @sadstill@sadstill14 күн бұрын
  • ❗ВИДЕО СОДЕРЖИТ ОЧЕНЬ МНОГО СЕКСА❗

    @dy0mber847@dy0mber8473 ай бұрын
    • * сексов 🥸

      @studyingCS@studyingCS3 ай бұрын
    • Найти богатую мил** )

      @witphg@witphg2 ай бұрын
  • Возможно в видео следовало добавить пункт про primary key и то, как он взаимодействует с порядком данных в памяти P.S. я же правильно понимаю, что идея делать primary key по GUID чаще всего проигрывает идее primary key по identity (возможно в postgers по другому называется, растущий в одну сторону индекс 1, 2, 3... 700000) по той причине, что в памяти не нужно будет пересортировывать огромную таблицу при добавлении нового значения?

    @ahtohpolsky3975@ahtohpolsky39753 ай бұрын
  • В примере когда при наличии индекса по age, salary и запросе age = 18 постгрес выбрал seq scan не пробовали CREATE STATISTICS сделать?

    @alexfilus@alexfilus3 ай бұрын
    • О, нет, я вообще про такую хитрую фичу не знал. Спасибо. Не уверен правда, что помогло бы - колонки с собой никак не связаны (без этого, если правильно понял, CREATE STATISTICS не имеет смысла), генерилось все простым рандомом.

      @ivangolang@ivangolang3 ай бұрын
    • @@ivangolang Насчёт этого не уверен, но иногда даёт очень приятные результаты.

      @alexfilus@alexfilus3 ай бұрын
  • Мне нравится Головач Лена! Я думаю она хороший человек!

    @user-rv3cw6mp6i@user-rv3cw6mp6i2 ай бұрын
  • А ещё раз уж у нас в запросах часто встречается низкоселективная колонка sex можно по всем её возможным значениям построить частичные индексы.

    @alexfilus@alexfilus3 ай бұрын
    • Сможешь поподробнее пояснить идею?

      @hakooplayplay3212@hakooplayplay32123 ай бұрын
    • @@hakooplayplay3212 как в примере сделали частичный индекс на salary > 999500, так же сделать sex='female' и sex='male', но сомневаюсь что это даст профит, при селективности 50% время на обращение к индексу может не окупить пользу, которую он принесет

      @ahtohpolsky3975@ahtohpolsky39753 ай бұрын
    • А что это даст? Поиск по более селективному индексу почти всегда будет предпочтительнее, только зря место под индекс потратим.

      @vryaboshapko@vryaboshapko3 ай бұрын
  • Постре не кэширует план запроса после первого выполнения? Возможно, что частичное ускорение поиска Лены связано еще и с этим, а лишь потом добавляется эффект от индекса.

    @temnikoff@temnikoff3 ай бұрын
    • так он же с индексом новый план строит и юзает, как ему закэшированнный старый план помогает в этом?

      @ivangolang@ivangolang3 ай бұрын
    • ​@@ivangolang энивей я бы в любом случае указывал постгре не использовать кеш, но даже это не помогло бы в полной степени. результаты одного и того же запроса будут разными даже если постгря не будет юзать кеш

      @xionnnn719@xionnnn7193 ай бұрын
  • +rep за мемы в видосе

    @psylo1841@psylo18412 ай бұрын
  • Привет, а как ты загенерил 70 млн записей, что за инструмент?

    @sadstill@sadstill14 күн бұрын
  • где можно скачать тестовый бд?

    @user-lu7mm8bw1m@user-lu7mm8bw1mАй бұрын
  • Однажды подробный разбор блокировок в бд стал для меня "базой", той самой вэХаЭс с главным фильмом, что ставили на полку, а не таскали из проката. Лену головач даже записывали в список присутствующих студенты первых курсов, на первых занятиях, когда преподаватель не вёл перекличку группы, а направлял лист по партам - звучала эта учащаяся в тишине аудитории необычно, серьёзно и глупо одновременно) Автору просьба - не пропадать в вечность, подобные видео или любого кастома очень важны и полезны, это настоящий опыт, а не писанина по примерам в гайде итп

    @user-ge6pt5lp9u@user-ge6pt5lp9u2 ай бұрын
  • Очень полезная инфа, спасибо. хоть я и не разраб, а сис анал, но мне тоже полезно знать

    @user-yx5mj6sm9t@user-yx5mj6sm9tАй бұрын
  • Данные методики создания индексов актуальны и для других СУБД или только для постгреса?,

    @uglycarl7661@uglycarl76613 ай бұрын
    • Самый надёжный ответ лежит в документации к той СУБД, которая вас интересует, потому что в каждой СУБД свой планировщик запросов, и у него может быть своё мнение о том, что такое оптимальный запрос. Но вообще да, общие принципы вытекают из особенностей той структуры данных, которая используется для хранения индексов. В видео говорится только о B-дереве, деревья - это «основная» структура для индексов, её по умолчанию используют PostgresSQL, MySQL, SQLite и, наверняка, многие другие. В некоторых СУБД есть ещё хэш-мапа, и вот для неё большая часть информации из видео не актуальна.

      @vryaboshapko@vryaboshapko3 ай бұрын
  • Еще не смотрел но прям пааахнет годнотой же. гляну обязательно)

    @user-ir4vd5yk4x@user-ir4vd5yk4x3 ай бұрын
  • это дают написать такой запрос sql или составить индексы? просто не понял в чем сложность запроса

    @andreyko_o9014@andreyko_o90143 ай бұрын
    • составить индекс на данный запрос

      @ivangolang@ivangolang3 ай бұрын
  • лайк за то, что люблю находить Голова Члену сразу

    @user-nl7fw3yp8p@user-nl7fw3yp8p9 күн бұрын
  • Суперматериал!!! Ток вот не понятно в одном месте, Было сказано про влияние индекса на скорость вставки данных в таблицу уже после создания индекса, и типа на нее будем обращать внимание, но в финале не было такого критерия, был критерий время создания индекса, или время создания индекса соответствует времени вставки в БД. Или это совсем другая единица и ее просто не рассмотрели

    @boulevardgaidena.k.a3555@boulevardgaidena.k.a35553 ай бұрын
    • Ее хорошо бы рассмотреть отдельно, не хотел просто этим грузить. В первом приближении время создания индекса вроде коррелирует со вставкой/апдейтом.

      @ivangolang@ivangolang3 ай бұрын
    • @@ivangolang понял, спасибо, материал пушка, долго про индексы серфил разную инфу, в основном везде все базовое общее. Да и в целом другие видосы заинтересовали. Хотя если в масштабах канала смотреть, у тебя больше Golang, а я на питонячем стеке, но все равно полезно

      @boulevardgaidena.k.a3555@boulevardgaidena.k.a35553 ай бұрын
    • Это время прямопрапорционально увеличению объма базы при добавлении индекса. Точные значения могут различаться на порядки в зависимости от сложноотслеживаемых параметров

      @ahtohpolsky3975@ahtohpolsky39753 ай бұрын
  • 15:46 Ну очень уж задумчивое «эээммм» 😅

    @vryaboshapko@vryaboshapko3 ай бұрын
  • как ты проверил алокацию памяти при добавлении индексов

    @karmraks@karmraks3 ай бұрын
    • В докере смотрел на размер вольюма

      @ivangolang@ivangolang3 ай бұрын
  • Лайк коммент

    @user-dz6xu1de4b@user-dz6xu1de4bАй бұрын
  • А если на собесе, вместо конкретного решения, начать в размышление, типо «ну это зависит от того какие данные, надо взять и посмотреть, надо изучить как добавление индекса заафектит другие запросы и тд и тп», а конкретного решения так и не предложить…такое прокатит, как думаешь?

    @SlavaCh@SlavaCh2 ай бұрын
    • Что такое конкретное решение в задаче, у которой его нет? Именно на задаче из видео в рамках собеса я бы навалил варианты по правилу составления сложных индексов, а дальше бы в сжатой форме объяснил, что надо понимать про данные и другие запросы в системе. Если захотят углубиться - углубился бы.

      @ivangolang@ivangolang2 ай бұрын
    • ну дальше сразу вопрос "так на какие параметры смотреть. и как зависит?" - если ничего внятного - то ответ не засчитывается

      @ivani3237@ivani32372 ай бұрын
    • @@ivani3237 я не понимаю к чему коммент. Ну да, собесы работают так, что когда ты не можешь ответить внятно на вопрос - ответ не засчитывается.

      @ivangolang@ivangolang2 ай бұрын
    • @@ivangolang ну вот автор вопроса почему-то об этом не знал

      @ivani3237@ivani32372 ай бұрын
  • С набранной статой лучшим вариантом был бы sex, age, created_at Или age, created_at (для уменьшения размера) Ультра быстрым был бы еще Sex, age, created_at include salary Дело в том, что вы сортируете очень много данных, и для этого всего надо очень много оперативной памяти. Последний индекс по по сортировке позволяет бд ничего не сортировать в памяти, тупо можно идти подряд по листьям индекса. Также на практике запросы будут с лимитом скорее всего, и тут бесплатная сортировка вообще топ. Вам надо в своих выводах исходить из внутренней структуры индекса, а не из эфимерных правил, тогда и самому станет понятнее.

    @user-zw9jh8te9c@user-zw9jh8te9c2 ай бұрын
    • Так показываю же бенчмарком, что age,sex,created_at (понятно, что порядок sex и age конкретно здесь не важен) нерабочий вариант. Объяснение почему так в видео есть. Про include не знал, спасибо, почитаю.

      @ivangolang@ivangolang2 ай бұрын
    • Про include почитал - спасибо за наводку. Здесь он, конечно, не поможет. По той же самой причине, почему не помогает индекс без инклюда.

      @ivangolang@ivangolang2 ай бұрын
    • @@ivangolangсоздай статистику, сделай измерения. Потом добавь limit 10, сделай измерения. А ещё ты не меняешь пиковое потребление оперативной памяти. А ещё у тебя данные могу не влезть в буфер сортировки.

      @user-zw9jh8te9c@user-zw9jh8te9c2 ай бұрын
    • *не измеряешь потребление памяти

      @user-zw9jh8te9c@user-zw9jh8te9c2 ай бұрын
    • @@ivangolang include тут поможет тем, что не надо будет в таблицу обращаться для отбора, а можно будет прямо из индекса брать.. Зависит ещё от того, используешь ли * или нет.

      @user-zw9jh8te9c@user-zw9jh8te9c2 ай бұрын
  • И все же не понятно почему count(id) from employee where sex = 'frmale' отработал на 4 секунды дольше после создания индекса по полю sex??? explain показывает seq scan в обоих случаях что без индекса, что с индексом. Но без индекса быстрее. ПОЧЕМУ? ЗЫ: я бы понял если в случае с индексом в explain был бы индекс (а не seq scan), тогда можно было предположить что увеличение по времени произошло из-за неселективной колонки sex. Но даже если бы индекс затормозил поиск из-за неселективности, подсчет бы все равно выполнился по индексу (т.к. он корректный - т.е. указан на верную колонку и не составной) и в explain были бы следы использования индекса. Можно было бы понять если бы индекс был составной с неправильным порядком колонок - тогда поиск по индексу не дал бы результатов и выполнился seq scan по итогу и как следствие увеличение времени из-за неэффективного индекса. НО ПОЧЕМУ ПРАВИЛЬНЫЙ НЕ СОСТАВНОЙ ИНДЕКС (пусть и на неселективной колонке) ТОРМОЗИТ ПРОЦЕСС, А ПОСЛЕ EXPLAIN выдает seq scan ВООБЩЕ НЕ ПОНЯТНО. По итогу метод поиска один и тот же, но индекс дал +4 сек.

    @zicksu2142@zicksu21422 ай бұрын
  • все узрели лену, ни все узрели "к своим"

    @TheDavBag@TheDavBag2 ай бұрын
  • Почему не так, допустим есть неравенство допустим > 100, почему не проиндексировать это как 3 единицы условно символов, это уже ведь ускорить проверку, и тоже самое по имени, зачем мне искать по всем ленам, и так далее, если можно было бы создать отдельную как структуру или папку бдшку, где сортировка будет идти по первой букве, внутри этой таблицы первой буквы, уже будут другие таблицы отсортированные по количеству символв в той строке, такая структура разве не улучшит саму бдшку, само собой это идёт какой-то глобальный индекс который уже делает раза в2-4 раза быстре отклик, и потом уже такую сортировку если это не равенство в случае с интом или стрингой с кол-во внутри символом, это ведь тоже ускорит запрос, такое можно делать, посмотрел только до 9:34 Структура которую я имею ввиду: 1) Юзер 1.2)А 1.3)Б 1.2.1) 1 символ и так далее. Есть такие бдшки?

    @ThePirateHistory@ThePirateHistory3 ай бұрын
    • база индексирует в любом случае уникальные значения, допустим ты хочешь сделать индекс по первым 3 символам "Але", смысла в этом в итоге мало, так как если сделать полностью индекс по имени, выйдет 2 уникальных значения "Алена" и "Алексей", в итоге профита мало

      @ahtohpolsky3975@ahtohpolsky39753 ай бұрын
    • @@ahtohpolsky3975 я описал о индексировании, первое по первой букве, а потом по кол-во символов, можно сделать наоборот

      @ThePirateHistory@ThePirateHistory3 ай бұрын
  • Лена Головач, Головач Лена...

    @user-zm7uq3um7x@user-zm7uq3um7x2 ай бұрын
  • Капец как подробно)) можно море контента сделать только на тему постгри

    @vvops2540@vvops25403 ай бұрын
  • любая Лена Головач наверное всегда произносит сналала свое имя, а потом уже фамилию 🤣🤣🤣 👍

    @something-like-that@something-like-that2 ай бұрын
  • Лена Головач - да автор тот ещё троль )

    @ForeverNils@ForeverNilsАй бұрын
  • очень селективное видео

    @TheIamFly@TheIamFly3 ай бұрын
  • Смотря на тенденции этого мира скоро sex будет не низко селективным)))

    @the_ower514@the_ower51424 күн бұрын
  • Я вообще херачу индексы на все уолонки которые используются в поиске, и похер

    @LeXX_009@LeXX_0093 ай бұрын
  • Само поле sex нужно было делать не текстовым, а числовым типа 0 и 1 + таблица справочник с ключем на эти значения и тогда индекс будет работать лучше по этому полю (память жрать меньше как минимум). Так же ещё можно было упомянуть про частоту запросов пользователей и их тип (select, update и т.д.) к полям таблицы и порядок создания индексов из этого расчета. Сам я давно уже не работаю с базами данных (1,5 года), так что сори, если написал как-то не так.

    @irustv7674@irustv76743 ай бұрын
    • Спасибо за содержательный коммент:) Про пол согласен. Про частоту тоже, отчасти это было и по ходу дела, и в финальном выводе, что надо понимать какие еще есть запросы/какие у нас на них требования, про частоту явно забыл упомянуть.

      @ivangolang@ivangolang3 ай бұрын
    • Вообще про пол такой момент, что оригинальная задача с собеса была именно так дана. Но лишнем сумничать не было бы в любом случае по этому поводу

      @ivangolang@ivangolang3 ай бұрын
    • Лучше тогда enum. Для пользователя выглядит как строка, а под капотом целое число 4 байта.

      @alexfilus@alexfilus3 ай бұрын
    • В современных реалиях лучше оставить это поле текстовым чтобы можно было записать всё что нужно🤣

      @viacheslav90@viacheslav903 ай бұрын
    • @@viacheslav90 как раз с учетом современных реалий его лучше числовым делать чтобы по этому полю быстрее поиск шел. Можно хоть миллиард гендеров записать, главное описание приделать, как чел выше заметил.

      @iamsteroid@iamsteroid3 ай бұрын
  • Что тут такого, Гена Цидармян?

    @myddl2643@myddl26433 ай бұрын
  • Не знаю какие цыгане тебя принесли в нашу семью, но они явно с какими-то умными корнями))) моему мозгу сложно воспринимать все, что после слов собеседование ))))

    @olgababoshina-rj4us@olgababoshina-rj4us3 ай бұрын
  • После того, как услышал про Елену, сразу понял что эти 30 минут я проведу с гениальным человеком. Спасибо за урок, с меня продвижение репостиком)

    @demo_ni_ma@demo_ni_ma2 ай бұрын
  • автор вкурсе что такое "Лена Головач"? это типа такой юмор?

    @MrSmallChe@MrSmallChe2 ай бұрын
    • В курсе, это имя и фамилия.

      @ivangolang@ivangolang2 ай бұрын
  • у Лены Головач Нужно сначала фамилию искать а потом имя такие правила ничего не пделаешь

    @MikhailHubarau-mr2fu@MikhailHubarau-mr2fu2 ай бұрын
  • То чувство, когда у тебя есть знакомая по имени "Лена Головач", и ты знаешь, почему у неё всегда имя впереди фамилии 😂

    @ekzotech@ekzotech2 ай бұрын
  • age = 50 это уже совсем не milf (

    @user-zy7gc7ms3x@user-zy7gc7ms3x3 ай бұрын
    • Ну че ты, не согласился если бы она богатой была?

      @ivangolang@ivangolang3 ай бұрын
    • больше 50 - это уже GILF

      @psylo1841@psylo18412 ай бұрын
  • name: Лена Головач, sex: male 🗿

    @studyingCS@studyingCS3 ай бұрын
    • кто понял - тот понял

      @Alexey-gp7vc@Alexey-gp7vc3 ай бұрын
    • Поменяла и зарплата сразу стала уменьшаться. Сексизм, однако

      @jeffgorh979@jeffgorh9793 ай бұрын
    • Сиега Головач

      @RodshotOfficial@RodshotOfficial3 ай бұрын
KZhead