1. Сравнение методов индексирования

Сравнивая рассмотренные выше принципы организации В+ дерева индексов и хеш индекса, можно сделать следующий основной вывод:

B+ деревья используют индексы, которые существуют как объекты базы данных, занимают дисковое пространство и содержат в себе указатели на реальные строки таблицы. В общем случае, B+ дерево не изменяет способ хранения самой таблицы и может быть создано для таблицы, в которую включены строки данных (т.е. это некоторая надстройка над таблицей).

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

В соответствии с этим, можно сформулировать следующие важные отличия хэш индексов от индексов B+ дерева.

1. B+ дерево имеет реальные объекты – индексы. С хэш таблицей реальные объекты – индексы не связаны.

2. B+ дерево не влияет на структуру таблицы, особенности ее отображения в памяти; доступ к строкам таблицы осуществляется через дерево индексов. Хэш таблица имеет специальную организацию, влияющую на доступ к ее строкам.

3. В B+ дереве строки таблицы упорядочены (на уровне листьев) по ключу. В хэш таблице никакой речи об упорядоченности строк не может быть, поэтому выборки, требующие упорядоченности (ORDER BY), очень не эффективны.

4. При поиске в B+ дереве определены понятия < и > для ключей (выбирается соответствующее поддерево или индекс B+ дерева). Для хэш таблиц такие понятия отсутствуют, эффективный поиск осуществляется только по условию =. Поиск по условиям < и > реализуется с помощью полного сканирования таблицы.

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

Отсюда, можно дать следующие рекомендации:

• если размер таблицы сильно изменяется – не хэш таблица;

• если часто организуется поиск по критериям < > – не хэш таблица;

• если используются справочники (мало изменяемые таблицы, поиск в них по =) – хэш таблицы.

Надо отметить, что если B+ дерево индексов используется всеми реляционными СУБД, то организация хеш таблиц реализована далеко не всеми СУБД. Так, в DD2® хеш таблицы не используются, а, например, в Oracle – используются. Пример задания хэш таблицы в СУБД Oracle.

Сначала задаются свойства кластерного хэш индекса:

CREATE CLUSTER HD(

DID NUMBER (5,0) SIZE 1K

HASH IS DID

HASHKEYS 200)

Указывается, что строки с одним и тем же значением хеш индекса будут иметь средний размер 1 Кбайт. Число различных значений хеш индекса равно 200 (дополнительный объем памяти распределяется автоматически).

Теперь можно создать хэш таблицу:

CREATE TABLE T(

MDID NUMBER (5) NOT NULL PRIMARY KEY,

. . .

) CLUSTER HD(MDID)