Улучшение работы с Data Warehouse
В этой области все улучшения можно разбить на 2 группы:
- улучшение алгоритмов оптимизации специфичных для Data Warehouse
запросов;
- ускорение выполнения запросов к большим таблицам.
Задачи, связанные с использованием Data Warehouse породили группу специфических запросов,
для которых не годятся стандартные методы оптимизации. Кроме того, успешное выполнение
запросов к большим таблицам невозможно без распараллеливания работы. И оптимизатор должен
учитывать при выборе плана выполнения запроса такие факторы, как степень распараллеливания,
количество процессоров, распределение данных таблицы по дискам, распределение таблиц по
узлам распределенной БД, близость тех или иных процессоров и дисков в МРР архитектурах. Не
учитывание этих факторов может значительно замедлить выполнение SQL операций. Например, в
некоторых случаях параллельное сканирование таблицы выгоднее, чем выборка из нее по индексу.
Cost based оптимизатор Oracle 7.3 учитывает все эти факторы. Кроме того, для правильного
построения плана выполнения SQL оператора желательно учитывать распределение данных в
столбцах таблицы. Поэтому Oracle 7.3 позволяет собирать такую информацию и строит на ее
основе гистограммы распределения данных в столбце, а оптимизатор использует эти
гистограммы при принятии решения.
Для Data Warehouse часто используются звездные запросы (star query). В них извлекается
информация из одной огромной центральной таблицы и множества мелких таблиц -
справочников. Oracle 7.3 выделяет и оптимизирует такие запросы. При этом сначала соединяются
справочники, а затем эта небольшая сводная справочная таблица соединяется с центральной
таблицей. При работе с центральной таблицей используются индексы.
В задачах Data Warehouse часто используются представления (View ), полученные за счет
объединения (Union) множества мелких таблиц однотипной структуры. Например, продажи за год
- объединение продаж за месяц. Операции выборки из таких больших VIEW будут ускорены, если
быстро будут исключены из рассмотрения те мелкие таблицы, которые не удовлетворяют
условиям запроса. Например, если нас интересуют продажи за первые 10 месяцев, то не следует
учитывать продажи за ноябрь и декабрь. Оптимизатор Oracle 7.3 учитывает это при работе.
Ускоряется и выполнение запросов с условием NOT IN (анти JOIN ). Оптимизатор также
учитывает новые алгоритмы Oracle, ускоряющие выполнение SQL операторов. Среди них следует
отметить следующие:
Новый алгоритм соединения таблиц с использованием хэширования (hash join). Этот
алгоритм исключает необходимость сортировки и слияния участвующих в соединении таблиц. Он
дает ускорение в 10 - 100 раз. Он очень удобен и для параллельной обработки. Основная идея
заключается в том, что меньшая из таблиц (или меньшая часть двух соединяемых фрагментов
таблиц) хэшируются в оперативной памяти. А вторая таблица (фрагмент) сканируется и для
каждой ее строки по хэш функции находится в оперативной памяти соответствующая запись
первой таблицы. Разделение таблиц на фрагменты также выполняется с учетом хэш функций.
Битовые индексы. Для индексирования столбцов с низкой кардинальностью ( т. е.
содержащих небольшое число значений, например: пол - М или Ж, цвет - красный, желтый, синий)
удобно использовать битовые (bit map) индексы. Для каждого значения столбца строится битовая
линейка, в которой число битов равно числу значений в столбце и биты, соответствующие
позиции данного значения в столбце, установлены в 1. Например, для столбца "пол" будет
построено 2 битовых линейки. Операции поиска по этому столбцу сведутся для Oracle к
выполнению логического И/ИЛИ над этими линейками. Кроме того, битовые линейки хранятся в
упакованном виде. Oracle умеет одновременно работать как с битовыми (т.е. более компактными,
чем обычные индексы) так и с обычными индексами. Тип индекса прозрачен для приложения, но
скорость выборок из больших таблиц с битовыми индексами возрастает значительно. Ранее
битовые индексы использовались в SQL*Textretrieval для работы с текстовыми БД.
Усиление распараллеливания выполнения операций.
В Oracle 7.3 распараллеливаются такие
подэтапы выполнения SQL запроса, как SCAN, JOIN, AGREGATE, DUBLICATE
ELIMINATION, UNION, UNION ALL, HASH JOIN. Поэтому выборки, построения и
перестройки индекса, копирования таблиц реализуются быстрее.
Асинхронное оптимистичное чтение. При сканировании таблиц Oracle может не
ограничиваться считыванием с диска необходимой в данный момент информации, а совместить
обработку этой информации со считыванием последующих блоков. Считывание выполняется в
параллельном режиме и время выполнения запроса снижается за счет уменьшения влияния
ввода/вывода.
Выделенные временные табличные пространства. В предыдущих версиях Oracle оператор
SQL, выполняющий сортировку, создавал, использовал, а затем удалял временные области в БД.
Это требовало времени на управление выделением пространства. Кроме того, в том же Tablespace
могли находиться и другие объекты БД. Создание выделенных tablespace только для сортировки
позволит избежать этих накладных расходов.
Перестройка индекса на базе существующего индекса. Использование при перестройки
индекса информации о старом индексе ускоряет выполнение этой операции. В больших БД
перестройка индекса позволяет освободить неиспользуемое индексом пространство БД.
