Оптимизация запросов, управляемых правилами

Генерация систем баз данных, ориентированных на приложения

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

Следовательно, очень заманчиво производить не законченные универсальные СУБД, а нечто вроде компиляторов (compiler compiler), позволяющих собрать систему баз данных, ориентиро­ванную на конкретное приложение (или класс приложений). Рас­смотрим простые примеры.

Так, в системах резервирования проездных билетов запросы обычно настолько просты (например: «выдать очередное место на рейс № 645»), что нет смысла производить широкомасштабную оптимизацию запросов. Однако информация, хранящаяся в базе данных, настолько критична (кто из нас не сталкивался с про­блемой наличия двух или более билетов на одно место?), что осо­бенно важны гарантированные синхронизация обновлений базы данных и ее восстановление после любого сбоя.

В статистических системах запросы могут быть произвольно сложными (например: «выдать число холостых мужчин, прожива­ющих в России и имеющих не менее трех зарегистрированных детей»), что вызывает необходимость использования развитых средств их оптимизации. Однако поскольку речь идет о статисти­ке, здесь не требуется поддержка строгой сериализации транзак­ций и точного восстановления базы данных после сбоев. (Когда речь идет о статистической информации, потеря нескольких ее единиц обычно не существенна.)

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

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

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

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

Решают эту проблему с помощью компромиссных решений, не выходящих за пределы традиционной технологии производ­ства компиляторов. В основном все они связаны с применением тех или иных инструментальных средств, обеспечивающих авто­матизацию построения компиляторов. Такие инструментальные средства имеются, например, в системах DB2, Oracle, Informix.

Дата добавления: 2014-01-07