Оптимизация запросов

Для реляционных систем оптимизация является как проблемой, так и возможностью повышения производительности.

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

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

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

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

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

2. Если с течением времени статистика базы данных значительно изменится, например, в результате ее реорганизации, то для реализации запроса может потребоваться совершенно иная стратегия, чем до реорганизации. Другими словами, может понадобиться повторная оптимизация. В реляционных системах процесс повторной оптимизации достаточно тривиален. Это просто повторная обработка исходного запроса системным оптимизатором. В нереляционных системах повторная оптимизация требует переписывания программы, а в некоторых случаях вообще не выполнима.

3. Оптимизатор способен рассматривать сотни различных стратегий реализации запроса, в то время как программист, как правило, изучает всего три–четыре. Назначение оптимизатора состоит в выборе эффективной стратегии реализации запросов. На практике оптимизированной стратегией обычно считается та, которая является некоторым улучшением исходной стратегии выполнения запроса.

Стадии процесса оптимизации запросов

1. Преобразование запроса во внутреннюю форму.

2. Преобразование запроса в каноническую форму.

3. Выбор потенциальных низкоуровневых процедур.

4. Генерация планов выполнения запроса и выбор плана с минимальными затратами.

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

Кроме того, выбранный способ оптимизации должен быть достаточно нейтральным, чтобы не предопределять дальнейших оптимизационных решений.

Обычно внутреннее представление запроса является определенной модификацией дерева запросов.

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

Все запросы, за исключением простейших, реляционные языки обычно позволяют выразить несколькими разными способами.

Производительность вычисления запроса не должна зависеть от формы записи, которую выбрал пользователь.

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

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

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

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

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

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

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

Каждый план выполнения строится как сочетание набора процедур реализации. При этом каждой низкоуровневой операции в запросе соответствует одна процедура.

Для выбора плана с наименьшей стоимостью рекомендуется использовать эвристические алгоритмы на достаточно ограниченном наборе планов запроса.

Понятие достаточно ограниченного набора означает, что необходимо уменьшить пространство поиска до диапазона, поддающегося анализу и управлению.