Индексные кластеры

В предыдущем разделе мы упоминали о кластерах (поскольку для хеширования необходимо, чтобы таблица находилась в кластере), но так и не объяснили, что же это такое. Кластеризация — это попытка разместить рядом, в одном блоке данных, строки, доступ к которым осуществляется при помощи одинакового значения ключа. Ключ может быть либо хеш-ключом, либо индексным. Если это хеш-ключ, то физическое размещение строк определяется хеширующей функцией. Если это индексный ключ, то для идентификации адреса блока данных (как всегда) используется индекс, имеющий структуру В*-дерева, но строки с одинаковым ключевым значением размещаются в одном блоке или нескольких связанных блоках. Строки, которые хранятся в индексном кластере, не обязательно должны принадлежать одной таблице. Индексные кластеры можно использовать для хранения дочерних строк с родительской, что должно существенно повысить производительность при выполнении соединения этих таблиц.

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

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

Мы рекомендуем применять кластеры только в следующих, очень специфических случаях:

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

• На кластерный ключ всегда приходится более одной строки (поскольку в противном случае сгодится и обычная индексированная таблица).

• Все данные для заданного кластерного ключа необходимы при каждом доступе по кластерному ключу (поскольку в противном случае сгодятся и обычные индексированные таблицы).

• Частота DML-обращений к данным мала (поскольку в противном случае плохая производительность DML-операций в кластеризованных таблицах повлияет на всю систему).

Даже в этих случаях выигрыш в производительности, как правило, не очень высок. В то же время плохо построенный кластер может существенно снизить производительность приложения. Поэтому будьте осторожны! Однако несмотря на это, Oracle интенсивно использует индексные кластеры в оперативном словаре данных. Если хотите посмотреть, насколько интенсивно, — найдите файл sql.bsq, который на Unix-платформах находится в каталоге $ORACLE_HOME/dbs, и просмотрите его.

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

CREATE CLUSTER cust_comments_cluster (cust_id_ VARCHAR2(8))
STORAGE...
INDEX;
CREATE INDEX cust_comments_cust_id ON CLUSTER cust_comments_cluster
STORAGE...

CREATE TABLE cust_comments
(cust_id VARCHAR2(8) NOT NULL REFERENCES customers
, enrty# NUMBER NOT NULL
, date_entered DATE NOT NULL
, entered_by VARCHAR2(8) NOT NULL REFERENCES operators
, comment_text VARCHAR2(80) NOT NULL
, PRIMARY KEY (cust_id, entry#)
) CLUSTER cust_comments_cluster (cust_id);

Эта таблица кластеризована по столбцу CUST_ID, и все комментарии для любого данного клиента будут расположены либо в одном блоке, либо (если их много) в связанных блоках, и их можно выбрать за одну операцию поиска по индексу с помощью следующего запроса:

SELECT date_entere
, entered_by
, comment text
FROM cust_comments
WHERE cust_id =:this_cust
ORDER BY entry# DESC;

Обратите внимание, что ограничение PRIMARY KEY в операторе CREAТЕ TABLE закомментировано, чтобы избежать создания второго индекса. Этот прием следует применять очень осторожно: он заметно снижает затраты при вставке строк в таблицу, но оставляет эту структуру уязвимой для ошибок приложений. Такая форма однотабличного кластера для очень больших таблиц обычно не используется, но может быть полезна в приложении, где:

• очень немногие записи о клиентах имеют комментарии;

• снабженные комментарием записи имеют, как правило, более одного комментария;

• при выборке комментариев для данного клиента выбираются все комментарии.

Дата добавления: 2015-08-09