Владимир Ситников - B-tree индексы в базах данных на примере PostgreSQL
HTML-код
- Опубликовано: 13 июн 2023
- Ближайшая конференция - Heisenbug 2024 Autumn, 10 октября (Online), 17-18 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Tq0vcu
- Ближайшая конференция: Heisenbug 2023 Autumn - 10-11 октября (online), 15-16 октября (offline)
Подробности и билеты: bit.ly/3qd3swV
- -
Доклад о том, как работают обычные™ индексы в базах данных. Будет крайне полезно как тем, кто начинает работать с базами данных, так и тем, кто работал, но подзабыл. У вас в проекте наверняка есть база данных. Наверняка изредка запросы тормозят, и довольно часто это случается либо из-за нехватки, либо из-за переизбытка индексов. На докладе мы научимся измерять производительность запросов, узнаем про то, как работают индексы, и научимся правильно их применять. Примеры будут на PostgreSQL, но знания подойдут и ко многим другим базам, ведь алгоритм b-tree изобрели в 1970 году, и его вариации используются сейчас очень часто.
Рассмотрим:
- Как индекс ускоряет поиск;
- Нужно ли индексировать условия where;
- Нужно ли индексировать условия в order by;
- Нужно ли индексировать foreign keys;
- Что делать, если критериев поиска несколько;
- В каком порядке указывать колонки в индексе;
- Случаи, когда индекс замедляет работу, и как снизить влияние индекса на приложение.
#database #postgresql
Вот это да. 10 лет программирую, столько текстов прочитал о всякой-всячине, но конкретику нашел именно тут. Спасибо за видео
Что ж вы читали то? тутто как раз вода водой без конкретики
@@igorseledtsov7345а можете подсказать где подробнее всего описана работа индексов без воды? Хочу подробнее разобраться, непонятны некоторые моменты
Очень полезный доклад. Побольше бы такого. Достаточно прикладные вещи, но мало где это подробно описано
Материал, презентация, доклад, все на высшем уровне, спасибо Владимиру за работу
Владимир, спасибо огромное за доклад!
Отличный доклад, спасибо !
Познавательно. Спасибо :)
Спасибо, отличный материал)
отличный доклад, спасибо
Владимир, отличный доклад, спасибо!
Прекрасный доклад
Спасибо!
Отличный доклад, большое спасибо автору 🙂
Шикарный доклад, посмотрел с удовольствием, хотя знал это всё)
Я только начинаю в PostgreSQL, мало что понял, но было интересно
Очень доступно для новичков
Очень интересный доклад, больше года к сожалению приходится работать только с nosql elasticsearch и там структура данных при индексирование не b-tree а inverted index (array) что оптимизировано для поиска по тексту, кайфанул от просмотра, очень детально.
Ситников - топ
Хорошее объяснение. Буду шарить всем неверующим, что юид не самый лучший вариант для айдишки )))
Это не так. Есть такая штука как "последовательный uuid" и проблема со вставкой уходит.
@@nikitabukov1292 дополню, сортировку поддерживают uuid v6 и v7
@@nikitabukov1292 uuid v6
В последнем примере про поиск по статусу и имени почему просто не создать частичный индекс куда войдут только строчки с PENDING если мы ищем только по таким строчкам?
Насколько мне известно, при покрытии индекса (когда данные в таблице отсортированы) механизм индексирования не в таблицу заглядывает для определения видимости строк, а в так называемую карту видимости, в которой vacuum отмечает строки которые не менялись очень долгое время, и доступны всем транзакциям. И если идентификатор строки попадает в эту карту то видимость можно не проверять. Поправьте если не прав.
Эта штука называется Visibility Map и да она для ускорения и там целый блок помечается битом содержит он данные старые или нет.
не понял про индекс по статусу и имени, не понял почему выгодно делать индекс статус-имя, ведь у статуса всего три значения и селективность у него будет явно хреновая, а вот у имени, особенно если именем будет какой-то никнейм, ну или даже имя человека, то там будет огромное количество разных значений у колонки и селективность будет явно больше, чем у статуса
это только для запросов, где мы ищем сразу по обоим полям всегда. С таким индексом, будет меньше случайных обращений, потому что мы загрузим один блок, где все state будут почти всегда одинаковые и мы разом прочитаем много нужных записей.
Если искать только по полю name, то такой индекс считай бесполезен. Тогда действительно стоит создавать (name, state) индекс. Ну или создать рядом ещё один индекс только по полю name
правильно ли я понял, что случайные uuid как индекс бесполезны и поск все равно будет перебором?
Нет. Речь была о скорости обновления индекса.
Отсортированный по времени UUID еще называют Ulid.
Это схожие, но разные виды id
Упал на последней минуте от вопроса "например вот как-бы вот это самое".
Девочка просто хотела понравиться докладчику, показав свою широту знаний)
Но получилось наоборот😢
Ни о чем, если честно.
Очень корявая речь, как-будто к выступлению докладчик не готовился совсем. Местами утверждения некорректные из-за этого
Спасибо, отличный доклад. Штук 5 видео про индексы я посмотрела на ютубе, и только в этом услышала то, что помогло мне осознать суть происходящего.