Performance and Indexes

Performance and Indexes

memorize.aimemorize.ai (lvl 286)
Section 1

Preview this deck

Если индексы так хороши, то почему их нельзя применить ко всем атрибутам таблицы?

Front

Star 0%
Star 0%
Star 0%
Star 0%
Star 0%

0.0

0 reviews

5
0
4
0
3
0
2
0
1
0

Active users

0

All-time users

1

Favorites

0

Last updated

6 years ago

Date created

Mar 1, 2020

Cards (49)

Section 1

(49 cards)

Если индексы так хороши, то почему их нельзя применить ко всем атрибутам таблицы?

Front

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

Back

Почему БД не всегда использует Index Scan, а использует Seq Scan?

Front

СУБД может использовать индекс или нет в зависимости от тех значений, которые пришли в запрос. Если в таблице не очень много значений, то для любой операции ее проще прочитать целиком, чем использовать индексы.

Back

Почему запрос может работать медленно даже при наличии индексов?

Front

Малая селективность запроса. Например, если в таблице хранятся данные о мужчинах и женщинах и мы будем индексировать по полу, то обычно данных поровну, поэтому индекс использоваться не будет.

Back

Когда БД может решить не использовать индекс?

Front

1. Плохая селективность запроса (нужно выбрать маленькое количество данных из небольшого массива или наоборот выдать большую часть данных массива) 2. Когда используем какую-то функцию, например, upper на проиндексированный элемент.

Back

Btree

Front

Индекс btree, он же B-дерево, пригоден для данных, которые можно отсортировать и в проверках диапазонов. Иными словами, для типа данных должны быть определены операторы «больше», «больше или равно», «меньше», «меньше или равно» и «равно».

Back

GiST index

Front

GiST stands for Generalized Search Tree. GiST indexes allow a building of general tree structures. GiST indexes are useful in indexing geometric data types and full-text search. GiST-индексы также могут оптимизировать поиск «ближайшего соседа»

Back

VACUUM

Front

сборщик мусора в Postgres.

Back

Когда используется Hash Join?

Front

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

Back

SP-GiST

Front

Индексы SP-GiST, как и GiST, предоставляют инфраструктуру, поддерживающие различные типы поиска. SP-GiST позволяет организовывать на диске самые разные несбалансированные структуры данных, такие как деревья квадрантов, k-мерные и префиксные деревья.

Back

BRIN

Front

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

Back

Будет ли использоваться индекс в этом запросе: SELECT * id, date, event FROM events ORDER date ASC LIMIT 10?

Front

Нет, индекс не будет использоваться, потому что он используется, когда есть условие выборки WHERE.

Back

Когда стоит использовать составной индекс?

Front

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

Back

GIN index

Front

GIN stands for generalized inverted indexes. It is commonly referred to as GIN like a drink. GIN indexes are most useful when you have multiple values stored in a single column, for example, hstore, array, jsonb, and range types; and full-text search.

Back

HASH

Front

Хеш-индексы работают только с простыми условиями равенства. Планировщик запросов может применить хеш-индекс, только если индексируемый столбец участвует в сравнении с оператором =

Back

Как выбрать атрибут для индексирования? Например, есть уникальный адрес и уникальный телефон, то для какой атрибут лучше использовать в качестве первичного ключа?

Front

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

Back

Селективность запроса

Front

СУБД собирает статистику о значениях атрибутов. Статистика используется для оценки селективности запроса: отношение количества строк в результате к количеству строк в таблице. Если селективность плохая (мало записей в маленькой таблице или нужно выбрать бОльшую часть таблицы), то дешевле выполнить Seq Scan, чем использовать индекс.

Back

Nested Loop

Front

Суть способа «вложенный цикл» в том, что перебираются строки из «внешнего» набора и для каждой из них выполняется поиск соответствующих строк во «внутреннем» наборе. Если соответствующие строки найдены, то выполняется их соединение со строкой из «внешнего» набора.

Back

Каким образом добавление индексов ускоряет выполнение запроса?

Front

Если мы выполняем запрос по выборке точного значения атрибута из таблицы без индекса для этого атрибута, то мы будем выполнять запрос с помощью Sequential Scan - последовательный сканированием всех строк таблицы. Если атрибут проиндексирован, то тогда поиск будет выполнятся с помощью Index Scan - поиск искомого значения ключа в индексе и обращаемся по ссылкам к значениям.

Back

Влияют ли на скорость выполнения запроса коррелирующие запросы в where?

Front

Да, их нужно стараться избегать.

Back

Что является ключом и значением в индексе?

Front

Ключ - значения, проиндексированного атрибута таблицы. Значения - указатели на записи в таблице.

Back

Влияют ли на скорость выполнения запроса количество запрашиваемых строк?

Front

Выбирать стоит только то, что нужно, особенно в подзапросах. Чем меньше колонок, что мы выбираем, тем больше шансов, что оптимизатор применит более эфективный алгоритм.

Back

Что, если индекс уже содержит все необходимые для запроса данные?

Front

Такой индекс называется покрывающим (covering), и в этом случае оптимизатор может применить исключительно индексное сканирование (Index Only Scan)

Back

Какие бывают способы соединения таблиц?

Front

1. Nested Loop. 2. Hash Join. 3. Merge Join.

Back

Bitmap scan

Front

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

Back

Будет ли использоваться индекс, если мы применим функцию на проиндексированный атрибут?

Front

Индекс в этом случае, скорее всего, использоваться не будет.

Back

Для каких атрибутов таблицы БД сама создает индексы?

Front

Часто БД создает индексы по-умолчанию для первичных ключей таблицы, потому что предполагает, что по значению первичных ключей обязательно будут искать.

Back

RUM

Front

Хоть авторы и утверждают, что джин — могущественный дух, но тема напитков все-таки победила: GIN следующего поколения назвали RUM. Этот метод доступа развивает идею, заложенную в GIN, и позволяет выполнять полнотекстовый поиск еще быстрее.

Back

Как можно ускорить выполнения запроса без использования индекса?

Front

Если у нас в БД хранятся данные read-only, много данных и запросы выполняются очень долго и сложные, то можно использовать materialized view.

Back

Merge Join

Front

Соединение методом слияния производится аналогично сортировке слиянием. В этом случае оба набора строк должны быть предварительно отсортированы по тем столбцам, по которым производится соединение. Затем параллельно читаются строки из обоих наборов и сравниваются значения столбцов, по которым производится соединение. При совпадении значений формируется результирующая строка. Этот процесс продолжается до исчерпания строк в обоих наборах.

Back

Влияют ли на скорость выполнения запроса сортировка в подзапросе?

Front

Да, сортировка значений снижает производительность. Чаще всего данные нужно сортировать при выдаче их клиенту, а не в подзапросе.

Back

В каком случае индекс работает для LIKE?

Front

Для LIKE индекс работает по префиксу - LIKE 'str%'. Не работает для LIKE '%str'.

Back

Bloom

Front

Структура данных, позволяющая быстро проверить принадлежность элемента множеству.

Back

О чем говорит cost в EXPLAIN?

Front

1 значение - это предполагаемое время получение 1 строки, а 2 - последней.

Back

Когда лучше создавать индексы во время вставки данных или после?

Front

Хорошо известный, но от этого не менее важный факт: загрузку в таблицу большого объема данных лучше выполнять без индексов, а необходимые индексы создавать уже после. Это не только быстрее, но и сам индекс скорее всего получится меньшего размера. Дело в том, что при создании btree-индекса используется более эффективная процедура, чем построчная вставка значений в дерево.

Back

Когда используется Merge Join?

Front

Он используется, если объединяемые наборы данных отсортированы (или могут быть отсортированы с небольшими затратами) с помощью ключа join и работает только при выполнении эквисоединений.

Back

Когда эффективен Hash Join?

Front

Метод эффективен для больших выборок.

Back

В чем отличие b-tree от GiST?

Front

GiST - это сбалансированное дерево поиска, точно так же, как и рассмотренный ранее b-tree. Индекс b-tree жестко привязан к семантике сравнения: поддержка операторов «больше», «меньше», «равно» — это все, на что он способен (зато способен очень хорошо!). Но в современных базах хранятся и такие типы данных, для которых эти операторы просто не имеют смысла: геоданные, текстовые документы, картинки.

Back

Нужно ли всегда думать о том, как написан запрос?

Front

Не всегда, довольно часто сама СУБД без участия программиста способна понять как лучше выполнить тот или иной запрос.

Back

Hash Join

Front

При соединении хешированием строки одного набора помещаются в хеш-таблицу, содержащуюся в памяти, а строки из второго набора перебираются, и для каждой из них проверяется наличие соответствующих строк в хеш-таблице. Как правило, число строк в том наборе, на основе которого строится хеш-таблица, меньше, чем во втором наборе.

Back

EXPLAIN

Front

Оператор EXPLAIN возвращает план выполнения, который планировщик PostgreSQL генерирует для данного оператора.

Back

Что происходит с запросом после того, как БД получила его от клиента?

Front

1. Проверка плана. 2. Построение плана запроса. 3. Оптимизация запроса. 4. Выполнения запроса.

Back

Когда индекс будет полезен?

Front

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

Back

Какой тип индекса используется по-умолчанию в БД?

Front

B-tree

Back

Какой тип JOIN'a будет использоваться в этом запросе: JOIN aircrafts a ON s.aircraft_code = a.aircraft_code WHERE a.model ~ '^Air'?

Front

Nested Loop

Back

Влияют ли на скорость выполнения запроса при заворачивании его в функцию?

Front

Код, завернутый в функцию становится более читаемым, но для оптимизатора он станет более загадочным.

Back

Как понять, что запрос написан плохо?

Front

Мы читаем одни и те же данные много раз. С помощью EXPLAIN ANALYZE смотрим на количество loops.

Back

Когда эффективен Nested Loop?

Front

Метод эффективен для небольших выборок.

Back

Индексы

Front

Структура данных предназначенная для ускорения некоторых запросов. B-tree или хеш-таблица.

Back

Какое правило работы с большими данными?

Front

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

Back