xBB – бесплатные скрипты PHP и доки для вебмастеров

4.5. Построение индексов

Индексы делают возможным использование пространственной базы данных для больших наборов данных. Без индексации, любой поиск приводил бы к "последовательному сканированию" каждой записи в базе данных. Индексация организовывает данные в поисковое дерево, по которому можно быстро перемещаться, чтобы быстро найти конкретную запись. PostgreSQL по умолчанию поддерживает три вида и индексов: индексы B-Tree, индексы R-Tree и индексы GiST.

• B-деревья (B-Tree) используются, когда данные могут быть отсортированы вдоль одной оси; например, числа, символы, даты. Данные ГИС не могут быть рациональным способом отсортированы вдоль одной оси (какую выбрать: (0,0) или (0,1) или (1,0)?), а потому для их индексирования не используются B-деревья.

• R-деревья разбивают данные на прямоугольники, под-прямоугольники, под-под-прямоугольники и т.д. R-деревья используются в некоторых пространственных базах данных для индексации данных ГИС, но в PostgreSQL реализация R-деревьев не столь надежна, как реализация GiST.

• Индексы GiST (Generalized Search Trees - Обобщенные деревья поиска) разделяют данные на "рядом расположенные вещи" ("things to one side"), "совпадающие вещи" ("things which overlap"), "внутри расположенные вещи" ("things which are inside") и могут быть использованы на широком диапазоне типов данных, включая данные ГИС. PostGIS использует реализацию R-деревьев на вершине GiST для индексации данных ГИС.

4.5.1. Индексы GiST

GiST означает "Обобщенное поисковое дерево" ("Generalized Search Tree") и является общей формой индексации. Кроме индексации ГИС, GiST используется для ускорения поиска на всех видах нерегулярных структур данных (целочисленные массивы, спектральные данные и т.д.), к которым неприменимо обычное индексирование B-Tree.

Когда таблица данных ГИС вырастает до нескольких тысяч записей, вы нуждаетесь в создании индексов для ускорения поиска пространственных данных (кроме случаев, когда весь ваш поиск основывается атрибутах. Тогда вам достаточно обычных индексов на полях атрибутов).

Ниже описан синтаксис запроса для создания GiST-индекса на столбце "geometry":

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometryfield] );

Создание пространственного индекса требует интенсивных вычислений: на таблице в 1 миллион строк на машине Солярис 300MHz создание индекса заняло у нас около 1 часа. После создания индекса важно заставить PostgreSQL собрать табличную статистику, которая используется для оптимизации планов запросов:

VACUUM ANALYZE [table_name] [column_name];
-- Это необходимо только для PostgreSQL 7.4 и более старых
SELECT UPDATE_GEOMETRY_STATS([table_name], [column_name]);

В PostgreSQL индексы GiST имеют два преимущества перед R-деревьями. Во-первых, индексы GiST являются "null-безопасными" ("null safe"). Это означает, что они могут индексировать столбцы, содержащие значения null. Во-вторых, индексы GiST поддерживают концепцию "неоднозначности" ("lossiness"), которая имеет значение, когда объекты ГИС зханимают больше 8К (размер страницы PostgreSQL). Неоднозначность позволяет PostgreSQL сохранять в индексе только "значимую" часть объекта. В случае объектов ГИС, это есть границы. Объекты ГИС, занимающие болше 8K, вызывают провал попыток создать идекс на основе R-дерева.

4.5.2. Использование индексов

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

Если вы находите, что ваши пространственные индексы не используются (впрочем, как и индексы атрбутов), есть пара вещей, которые вы можете сделать:

• Во-первых, убедитесь, что собрана статистика о числе и распределении значений в таблице, для предоставления планировщику запросов лучшей информации при принятии решений об использовании индекса. Для PostgreSQL 7.4 и более ранних это делается запуском update_geometry_stats([table_name, column_name]) (подсчет распределения) и VACUUM ANALYZE [table_name] [column_name] (подсчет числа значений). В PostgreSQL 8.0 запуск VACUUM ANALYZE выполнит обе операции. Вам следует регулярно производить вакуумизацию базы данных. Большинство DBA PostgreSQL позволяют регулярно выполнять VACUUM, как задачу крона.

• Если вакуумизация не работает, вы можете заставить планировщик использовать индекс с помощью команды SET ENABLE_SEQSCAN=OFF. Вам следует осторожно использовать эту команду, и только для запросов с пространственными индексами: как правило, планировщик лучше вас знает, когда следует использовать B-деревья. После выполнения запроса, вам следует восстановить прежнее значение ENABLE_SEQSCAN, чтобы другие запросы обрабатывались планировщиком как обычно.

  Замечание

  Начиная с версии 0,6 нет необходимости заставлять планировщик использовать индекс с ENABLE_SEQSCAN.

• Если вы считаете, что планировщик неправильно оценивает расходы на последовательное сканирование по сравнению с использованием индекса, можете уменьшить величину random_page_cost в postgresql.conf или использовать SET random_page_cost=#. По умолчанию этот параметр равен 4. Попробуйте установить его в 1 или 2. Уменьшение значения сделает планировщик более склонным к использованию индексов.

Последнее редактирование: 2008-04-07 14:48:53

Метки материала: PostGIS, индексы, GiST, база данных, PostgreSQL, B-Tree, R-Tree, ГИС

Оставьте свой комментарий:

Представиться как

Антибот:

Просьба не постить мусор. Если вы хотите потестить xBB, воспользуйтесь кнопкой предварительного просмотра на панели инструментов xBBEditor-а.