Возможности улучшений физической структуры базы данных на основе статистической информации о потоке запросов зависят от специфики конкретной СУБД. Вообще говоря, в число этих возможностей входят и изменения способа хранения отношений (если, как в СУБД INGRES, система поддерживает более одного способа хранения), и заведение новых копий отношения в распределенной базе данных (если в системе обеспечивается поддержка копий), и порождение новых разделов отношения (если система поддерживает разделенное хранение отношение) и т.д. Но если система, подобно System R, допускает сохранение ранее откомпилированных запросов и их повторное многократное выполнение, то естественным ограничением автоматических преобразований физической структуры базы данных является следующее: каковы бы не были эти преобразования, ранее откомпилированные запросы должны оставаться выполняемыми.
Поэтому в таких системах автоматическое изменение, например, структуры хранения отношения недопустимо. Можно допустить только наличие автоматизированных подсказок администратору базы данных о желательности таких радикальных перемен.
Однако, что касается вспомогательных управляющих структур, подобных индексам, обеспечивающих дополнительные возможности доступа к хранимым данным, то их автоматическое добавление в принципе допустимо в любой системе. При этом все ранее откомпилированные запросы продолжают оставаться выполняемыми, а запросы, поступающие после образования новых индексов, возможно, будут выполняться эффективнее. Конечно, автоматическое удаление индексов, даже если оно оправдано статистикой их применения, недопустимо, поскольку может повлечь необходимость перекомпиляции запомненных в системе запросов. Такие действия должен выполнять администратор (подсказки возможны).
Примером компонента СУБД, поддерживающего оптимальный набор индексов в реляционной базе данных, может служить средство DBDSGN [119], разработанное в рамках СУБД System R. (Как отмечается в [119], на основе этого средства впоследствии был создан коммерческий продукт RDT, используемый в коммерчески доступных СУБД фирмы IBM SQL/DS и DB2.)
DBDSGN обладает двумя основными особенностями. Первой особенностью является то, что это средство не интегрировано с внутренними компонентами System R, в частности, с оптимизатором запросов. В DBDSGN используется информация, которую можно получить от системы через ее стандартный интерфейс. Язык SQL, обеспечивающий этот интерфейс, включает специальный оператор EXPLAIN, позволяющий получить информацию о типе запроса, его структуре, выбранном для выполнения плане и оценках стоимости плана целиком и его составляющих. На основе этой информации в DBDSGN принимаются решения о необходимости создания дополнительных индексов, и индексы создаются также на основе обычного интерфейса SQL (используется динамически выполняемый оператор CREATE IMAGE; подробности о возможностях System R по части динамически выполняемых операторов можно найти в [129]).
Принципиальное отделение DBDSGN от оптимизатора запросов позволяет увеличить гибкость этого средства и, в частности, обеспечивает его независимость от применяемых в оптимизаторе стратегий порождения планов и их оценок. При этом, конечно, структура данных, поставляемых оператором EXPLAIN, должна быть унифицированной и однозначно понимаемой.
Вторая особенность связана с тем, что задача выбора оптимального набора индексов является NP-полной, и, следовательно, ее точное решение может оказаться слишком накладным. Поэтому для решения применяется набор эвристических правил. Мы не будем описывать применяемые в DBDSGN эвристики, поскольку достаточно сложны и специфичны. Как отмечается в [119], эти эвристики позволяют получить решение, близкое к оптимальному.
Заметим, что средство DBDSGN обеспечивает не автоматическое, а лишь автоматизизировнное улучшение физической структуры базы данных. Это средство является диалоговым и использует наряду с информацией от СУБД информацию, поставляемую администратором. В частности, под контролем администратора, производится и поиск решения задачи оптимального набора индексов. Каждый раз эта задача решается для одного указанного запроса, но в процессе последовательного применения DBDSGN образуется оптимальный набор индексов, соответствующий потоку запросов.
Возможно, конечно, построение более автоматизированных средств, но пока практика, видимо, не требует этого. По крайней мере, в литературе подобные системы не описываются.
Назад | Содержание | Вперед