Программирование >>  Oracle 

1 ... 108 109 110 [ 111 ] 112 113 114 ... 469


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

Индексы на основе битовых карт больше подходят для данных с небольшим количеством уникальных значений. Это данные, для которых при делении количества уникальных значений в строках на общее количество строк получается небольшое число (близкое к нулю). Например, столбец GENDER (пол) может иметь значения М, F и NULL. При наличии таблицы с 20000 записей о сотрудниках, получаем 3/20000 = 0,00015. Этот столбец отлично подходит для создания индекса на основе битовых карт. Он, определенно, не подходит для создания индекса на основе В*-дерева, поскольку для каждого значения ключа будет извлекаться существенная часть строк таблицы. В общем случае, как было показано выше, индексы на основе В*-дерева должны быть избирательными. Индексы на основе битовых карт не должны быть избирательными, наоборот, они должны быть очень неуникальными .

Индексы на основе битовых карт особенно хорошо подходят для сред с множеством произвольных запросов, особенно, если запросы эти ссылаются произвольным образом на много столбцов или выбирают агрегированные значения типа COUNT. Предположим, имеется таблица с тремя столбцами: GENDER, LOCATION и AGE GROUP. В этой таблице столбец GENDER имеет значение M или F, столбец LOCATION может иметь значения от 1 до 50, а в столбце AGE GROUP находится код, представляющий возрастные группы не старше 18 лет, 19-25 лет, 26-30 лет, 31-40 лет, 41 год и старше. Необходимо обеспечить выполнение множества произвольных запросов вида:

Select count(*) from T where gender = M

and location in (1, 10, 30)

and age group = 41 год и старше;

select * from t

where ((gender = M and location = 20)

or (gender = F and location = 22)) and age group = не старше 18 лет;

select count(*) from t where location in (11,20,30);

select count(*) from t where age group = 41 год и старше and gender = F;

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

GENDER, LOCATION, AGE GROUP. Для запросов, использующих все три столбца, столбцы GENDER и LOCATION или только столбец GENDER.



LOCATION, AGE GROUP. Для запросов, использующих столбцы LOCATION и AGE GROUP или только столбец LOCATION.

AGE GROUP, GENDER. Для запросов, использующих столбцы AGE GROUP и

GENDER или только столбец AGE GROUP.

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

Вот тут и пригодится индекс на основе битовых карт. С помощью трех небольших индексов на основе битовых карт, по одному для каждого отдельного столбца, можно эффективно находить строки, удовлетворяющие всем представленным выше условиям. Сервер Oracle будет просто объединять битовые карты трех индексов с помощью функций AND, OR и XOR, чтобы найти результирующее множество для условия, ссылающегося на любое подмножество этих трех столбцов. Он возьмет затем полученную в результате битовую карту, при необходимости преобразует биты со значением 1 в соответствующие идентификаторы строк и получит соответствующие данные (если бы требовалось выдать количество строк, удовлетворяющих условию, серверу достаточно было бы посчитать биты со значением 1).

Бывают случаи, когда индексы на основе битовых карт не подходят. Они хорошо работают в среде с интенсивным считыванием данных, но абсолютно не подходят для интенсивных изменений. Причина в том, что одна запись индекса на основе битовых карт сс1лается на множество строк. Если сеанс изменяет проиндексированные данные, все строки, на которые ссылается соответствующая запись индекса, по сути оказываются заблокированными. Сервер Oracle не может заблокировать отдельный бит в битовой карте записи индекса; он блокирует всю битовую карту. Все остальные транзакции, котор1м необходимо изменить ту же битовую карту, будут заблокированы. Это существенно снижает степень параллелизма: в процессе каждого изменения потенциально блокируются сотни строк, что предотвращает одновременное изменение их столбцов, входящих в ключ индекса. Заблокированы будут не все строки, как можно б1ло бы подумать, но многие. Битовые карты хранятся по разделам. Используя представленный выше пример с таблицей ЕМР, можно выяснить, что значение ключа индекса ANALYST появляется в индексе много раз, каждый раз указывая на сотни строк. При изменении строки, затрагивающем столбец JOB, необходимо получить исключительный доступ к двум записям индекса - для старого и нового значений ключа. Сотни строк, на которые указывают эти две записи, будут недоступны для изменения другим сеансам, пока исходное изменение не будет зафиксировано.

Если сомневаетесь - пробуйте . Добавьте индекс (или несколько индексов) на основе битовых карт для таблицы и посмотрите, что это даст. Это не займет много времени, поскольку индексы на основе битовых карт создаются намного быстрее, чем индексы на основе В*-дерева. Экспериментирование - лучший способ узнать, подходят ли эти индексы для вашей среды. Меня часто спрашивают: Как определить, что количество различных значений достаточно мало? . Простого ответа на этот вопрос нет. Иног-



Индексы 363

да это 3 значения для 100000 строк. Иногда - 10000 значений для 1000000 строк. Мало не означает обязательно не более десятка различных значений. Именно эксперименты помогут понять, подходят ли индексы на основе битовых карт для приложения. В общем случае, при наличии используемой в основном для чтения большой таблицы, к которой выполняется много запросов, набор индексов на основе битовых карт может пригодиться.

Индексы по функциям

Индексы по функциям были добавлены в версии сервера Oracle 8.1.5. Они поддерживаются сейчас в редакциях Oracle8i Enterprise и Personal Edition, но не в Standard Edition.

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

Индексы по функциям имеет смысл использовать по многим причинам. Вот только основные из них.

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

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

Важные детали реализации

Чтобы использовать индексы по функциям, необходима предварительная настройка. В отличие от описанных ранее индексов на основе В*-дерева и битовых карт, перед созданием и использованием индексов по функциям необходимо выполнить определенные действия. Чтобы обеспечить возможность их создания, надо задать ряд параметров в файле init.ora или на уровне сеанса. Кроме того, необходимы соответствующие привилегии. Для использования индексов по функциям необходимо сделать следующее.

Чтобы создать индексы по функциям для таблиц в собственной схеме, необходи-

ма системная привилегия QUERY REWRITE.

Чтобы создать индексы по функциям для таблиц в других схемах, необходима системная привилегия GLOBAL QUERY REWRITE.

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

Использовать функцию SUBSTR, чтобы ограничить размер значений типа VARCHAR2 или RAW, возвращаемых пользовательскими функциями. Можно скрыть использование SUBSTR с помощью представления (рекомендуется так и делать). Соответствующие примеры представлены ниже.



1 ... 108 109 110 [ 111 ] 112 113 114 ... 469

© 2006 - 2025 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика