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

Рет қаралды 16,280

10 ай бұрын

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

Пікірлер: 34

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

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

@igorseledtsov7345 Ай бұрын

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

@pyramidhead9692 Ай бұрын

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

@gregoryrubies6045 6 ай бұрын

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

@Aleksey_P 9 күн бұрын

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

@user-mu8wd3vn8s Ай бұрын

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

@levorlov8788 5 ай бұрын

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

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

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

@vladglushak4306 5 ай бұрын

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

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

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

@Serj1c Ай бұрын

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

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

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

@RaptorT1V 6 ай бұрын

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

@romanlunin386 4 ай бұрын

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

@TheNo0ker 6 ай бұрын

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

@MrVitalirapalis Ай бұрын

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

@coox4546 9 ай бұрын

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

@nikitabukov1292 4 ай бұрын

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

@TheMrMagyar Ай бұрын

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

@vasyavasin7364 Ай бұрын

@@nikitabukov1292 uuid v6

@aleona136 Ай бұрын

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

@mcolegon 6 ай бұрын

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

@amarazmable 4 ай бұрын

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

@ivanmatew568 10 ай бұрын

Отсортированный по времени UUID еще называют Ulid.

@PVBovercomes 8 ай бұрын

Это схожие, но разные виды id

@kvintnorris9828 9 ай бұрын

правильно ли я понял, что случайные uuid как индекс бесполезны и поск все равно будет перебором?

@KikkerRus 9 ай бұрын

Нет. Речь была о скорости обновления индекса.

@sergeypoprygin2670 2 ай бұрын

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

@user-fc7ch3yx4c 14 күн бұрын

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