6.2. Повышение производительности с помощью оптимизации

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

Многие современные СУБД обладают встроенными система­ми автоматической оптимизации: в частности, это выражается в том, что конечному пользователю уже не нужно задумываться над оптимальным выражением запросов - в этом случае сама СУБД построит запрос наилучшим образом.

Говоря про оптимизацию запросов в реляционных СУБД, обыч­но имеют в виду такой способ обработки запросов, когда по началь­ному представлению запроса, путем его преобразования, вырабаты­вается некий план его выполнения, наиболее приемлемый при суще­ствующих в БД управляющих структурах. Соответствующие преоб­разования начального представления запроса выполняются специ­альным компонентом СУБД - оптимизатором, и оптимальность про­изводимого им плана запроса носит условный характер: план опти­мален в соответствии с критериями, заложенными в оптимизатор. Можно представить, что обработка поступившего в систему запроса состоит из фаз, изображенных на рис.6.7.

На первом этапе запрос, заданный на языке запросов, подверга­ется лексическому и синтаксическому анализу. При этом вырабаты­вается его внутреннее представление, отражающее структуру запро­са и содержащее информацию, которая характеризует объекты БД, упомянутые в запросе (отношения, атрибуты и константы). Инфор­мация о хранимых в БД объектах выбирается из соответствующих каталогов. Внутреннее представление запроса используется и пре­образуется на следующих стадиях обработки запроса, так как форма внутреннего представления должна быть достаточно удобной для последующих оптимизационных преобразований.

На втором этапе запрос во внутреннем представлении подвер­гается логической оптимизации. Могут применяться различные преобразования, "улучшающие" начальное представление запро­са. Среди преобразований могут быть эквивалентные, после про­ведения которых получается внутреннее представление, семанти­чески эквивалентные начальному, например, приведение запроса к некоторой канонической форме. Преобразования могут быть и семантическими: получаемое представление не является семан­тически эквивалентным начальному, но гарантируется, что ре­зультат выполнения преобразованного запроса совпадает с ре­зультатом запроса в начальной форме при соблюдении ограниче­ний целостности, существующих в БД. После выполнения второ­го этапа обработки запроса его внутреннее представление стано­вится более эффективным, чем начальное.

Рис.6.7. Структура обработки запроса в СУБД

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

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

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

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

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

арифметическое_выражение1 OPERATOR

арифметическое_выражение2

где OPERATOR - некая операция сравнения;

арифметическое_выражение1 и арифметиче-ское_выражение2 - выражения, содержащие имена атрибутов отношений и константы.

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

имя_атрибута OPERATOR константа

Эта форма предиката очень полезна при выполнении следую­щего этапа оптимизации.

Если предикат включает два имени атрибутов разных отно­шений, то его каноническое представление имеет вид

имя_атрибута OPERATOR арифметическое_выражение

где арифметическое_выражение - включает только константы и имя второго атрибута.

И, наконец, для рассматриваемых предикатов более общего вида имеет смысл приведение предиката к каноническому пред­ставлению вида

арифметическое_выражение OPERATOR константное_ арифметическое выражение

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

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

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

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

При этом могут возникнуть проблемы, связанные с приведе­нием запросов с вложенными запросами. Основным отличием языка SQL от языка реляционной алгебры является возможность использовать в логическом условии выборки предикаты, содер­жащие вложенные подзапросы. Глубина вложенности не ограни­чивается языком, т.е. может быть произвольной.

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

Поэтому в общем случае каноническим представлением за­проса на n отношениях называется запрос, содержащий n-1 пре­дикат соединения и не содержащий предикатов со вложенными подзапросами. Для пояснения этого предлагаем следующий при­мер, основанный на отношениях, приведенных на рис.6.1:

ВЫБРАТЬ SPO.OCENKA ИЗ SPO ДЛЯ SPO.SN(ВЫБРАТЬ SPP.PN ИЗ SPP ДЛЯ SPP.PN="Физика")

преобразуется в эквивалент

ВЫБРАТЬ SPO.OCENKA ИЗ SPO, SPP ДЛЯ SPO.SN = SPP.PN И SPP.PN="Физика"

Важность таких преобразований обосновывается тем, что оп­тимизатор получает возможность выбора из большего числа спо­собов выполнения запросов и способы их выполнения более эф­фективны. При использовании в оптимизаторе запросов подобно­го подхода не обязательно производить формальные преобразо­вания запросов - оптимизатор должен в большей степени исполь­зовать семантику обрабатываемого запроса, а каким образом она будет распознаваться - это вопрос самой СУБД.

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

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

Напомним уже рассмотренное выше ограничение целостности для отношения SP, приведенного на рис. 4.1, которое сформули­ровано как:

СОЗДАТЬ ОГРАНИЧЕНИЕ ЦЕЛОСТНОСТИ RULE ДЛЯ ВСЕХ SP(SP.OCENKA>0 И SP.OCENKA<6)

Если, например, в отношении SP определены эти ограничения целостности и обрабатывается запрос с условием выборки

PN=2101, то есть ВЫБРАТЬ SP.OCENKA ИЗ SP ДЛЯ SP.PN=2101

то в ходе семантической оптимизации будут получены внутрен­ние представления, эквивалентные запросам с условиями, и за­прос примет вид:

ВЫБРАТЬ SP.OCENKA ИЗ SP ДЛЯ SP.PN=2101 И (SP.OCENKA>0 И SP.OCENKA<6)

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

Таким образом, одной из сторон повышения производитель­ности БД есть оптимизация запросов, выполняемая самой СУБД путем их декомпозиции и преобразования во внутреннее пред­ставление в несколько этапов с оценкой скорости выполнения.