Владимир Ситников - B-tree индексы в базах данных на примере PostgreSQL

Рет қаралды 18,691

11 ай бұрын

Ближайшая конференция - Heisenbug 2024 Autumn, 10 октября (Online), 17-18 октября, Санкт-Петербург
- Ближайшая конференция: Heisenbug 2023 Autumn - 10-11 октября (online), 15-16 октября (offline)
Подробности и билеты: bit.ly/3qd3swV
- -
Доклад о том, как работают обычные™ индексы в базах данных. Будет крайне полезно как тем, кто начинает работать с базами данных, так и тем, кто работал, но подзабыл. У вас в проекте наверняка есть база данных. Наверняка изредка запросы тормозят, и довольно часто это случается либо из-за нехватки, либо из-за переизбытка индексов. На докладе мы научимся измерять производительность запросов, узнаем про то, как работают индексы, и научимся правильно их применять. Примеры будут на PostgreSQL, но знания подойдут и ко многим другим базам, ведь алгоритм b-tree изобрели в 1970 году, и его вариации используются сейчас очень часто.
Рассмотрим:
- Как индекс ускоряет поиск;
- Нужно ли индексировать условия where;
- Нужно ли индексировать условия в order by;
- Нужно ли индексировать foreign keys;
- Что делать, если критериев поиска несколько;
- В каком порядке указывать колонки в индексе;
- Случаи, когда индекс замедляет работу, и как снизить влияние индекса на приложение.
#database #postgresql

Пікірлер: 36

@user-uf8tc4vg5r 10 ай бұрын

Вот это да. 10 лет программирую, столько текстов прочитал о всякой-всячине, но конкретику нашел именно тут. Спасибо за видео

@igorseledtsov7345 3 ай бұрын

Что ж вы читали то? тутто как раз вода водой без конкретики

@pyramidhead9692 2 ай бұрын

@@igorseledtsov7345а можете подсказать где подробнее всего описана работа индексов без воды? Хочу подробнее разобраться, непонятны некоторые моменты

@adilkhanzaidulla8244 Ай бұрын

Материал, презентация, доклад, все на высшем уровне, спасибо Владимиру за работу

@gregoryrubies6045 7 ай бұрын

Очень полезный доклад. Побольше бы такого. Достаточно прикладные вещи, но мало где это подробно описано

@levorlov8788 6 ай бұрын

Познавательно. Спасибо :)

@user-cn6wu1db7w 4 ай бұрын

Владимир, спасибо огромное за доклад!

@vladglushak4306 6 ай бұрын

Отличный доклад, спасибо !

@Serj1c 2 ай бұрын

отличный доклад, спасибо

@user-hh1hf9cw8m 29 күн бұрын

Спасибо, отличный материал)

@Aleksey_P Ай бұрын

Очень доступно для новичков

@user-bz9tz1mf3r 11 ай бұрын

Отличный доклад, большое спасибо автору 🙂

@RaptorT1V 7 ай бұрын

Я только начинаю в PostgreSQL, мало что понял, но было интересно

@user-mu8wd3vn8s 2 ай бұрын

Прекрасный доклад Спасибо!

@romanlunin386 5 ай бұрын

Шикарный доклад, посмотрел с удовольствием, хотя знал это всё)

@MrVitalirapalis 2 ай бұрын

Очень интересный доклад, больше года к сожалению приходится работать только с nosql elasticsearch и там структура данных при индексирование не b-tree а inverted index (array) что оптимизировано для поиска по тексту, кайфанул от просмотра, очень детально.

@sergeng-gd5ev 3 ай бұрын

Владимир, отличный доклад, спасибо!

@TheNo0ker 7 ай бұрын

Ситников - топ

@coox4546 10 ай бұрын

Хорошее объяснение. Буду шарить всем неверующим, что юид не самый лучший вариант для айдишки )))

@nikitabukov1292 5 ай бұрын

Это не так. Есть такая штука как "последовательный uuid" и проблема со вставкой уходит.

@TheMrMagyar 2 ай бұрын

@@nikitabukov1292 дополню, сортировку поддерживают uuid v6 и v7

@vasyavasin7364 2 ай бұрын

@@nikitabukov1292 uuid v6

@aleona136 2 ай бұрын

В последнем примере про поиск по статусу и имени почему просто не создать частичный индекс куда войдут только строчки с PENDING если мы ищем только по таким строчкам?

@sergeypoprygin2670 4 ай бұрын

не понял про индекс по статусу и имени, не понял почему выгодно делать индекс статус-имя, ведь у статуса всего три значения и селективность у него будет явно хреновая, а вот у имени, особенно если именем будет какой-то никнейм, ну или даже имя человека, то там будет огромное количество разных значений у колонки и селективность будет явно больше, чем у статуса

@user-fc7ch3yx4c Ай бұрын

это только для запросов, где мы ищем сразу по обоим полям всегда. С таким индексом, будет меньше случайных обращений, потому что мы загрузим один блок, где все state будут почти всегда одинаковые и мы разом прочитаем много нужных записей. Если искать только по полю name, то такой индекс считай бесполезен. Тогда действительно стоит создавать (name, state) индекс. Ну или создать рядом ещё один индекс только по полю name

@mcolegon 7 ай бұрын

Насколько мне известно, при покрытии индекса (когда данные в таблице отсортированы) механизм индексирования не в таблицу заглядывает для определения видимости строк, а в так называемую карту видимости, в которой vacuum отмечает строки которые не менялись очень долгое время, и доступны всем транзакциям. И если идентификатор строки попадает в эту карту то видимость можно не проверять. Поправьте если не прав.

@amarazmable 5 ай бұрын

Эта штука называется Visibility Map и да она для ускорения и там целый блок помечается битом содержит он данные старые или нет.