69.1. Обзор#

69.1. Обзор

69.1. Обзор #

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

Хеш-индексы поддерживают только индексы с одним столбцом и не позволяют проверять уникальность.

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

Каждый кортеж хеш-индекса хранит только 4-байтовое значение хеша, а не фактическое значение столбца. В результате хеш-индексы могут быть значительно меньше, чем B-деревья, при индексации более длинных данных, таких как UUID, URL и т. д. Отсутствие значения столбца также делает все сканирования хеш-индекса потерянными. Хеш-индексы могут участвовать в сканировании индекса битовой карты и обратных сканированиях.

Хеш-индексы оптимально оптимизированы для рабочих нагрузок SELECT и UPDATE, которые используют равенственные сканирования на больших таблицах. В B-дереве индекса поиск должен спускаться по дереву до того, как будет найдена листовая страница. В таблицах с миллионами строк этот спуск может увеличить время доступа к данным. Эквивалентом листовой страницы в хеш-индексе является страница ведра. В отличие от этого, хеш-индекс позволяет напрямую получать доступ к страницам ведра, что потенциально сокращает время доступа к индексу в больших таблицах. Это сокращение "логического I/O" становится еще более заметным на индексах/данных, превышающих shared_buffers/RAM.

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

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

Как и B-деревья, хеш-индексы выполняют простое удаление кортежей индекса. Это операция отложенного обслуживания, которая удаляет кортежи индекса, которые точно можно безопасно удалить (те, у которых бит LP_DEAD идентификатора элемента уже установлен). Если вставка обнаруживает, что на странице нет доступного места, то во избежание создания новой переполненной страницы, происходит попытка удаления мертвых кортежей индекса. Удаление не может произойти, если страница при этом закреплена . Удаление мертвых указателей индекса также происходит во время операции VACUUM.

Если это возможно, VACUUM также попытается уплотнить кортежи индекса на как можно меньшем количестве переполненных страниц, минимизируя цепочку переполнения. Если переполненная страница становится пустой, переполненные страницы могут быть переработаны для повторного использования в других блоках, но они никогда не возвращаются в операционную систему. В настоящее время нет возможности уменьшить размер хеш-индекса, кроме как перестроить его с помощью REINDEX. Также нет возможности уменьшить количество блоков.

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

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