|
21.3. Генерация систем баз данных,
ориентированных на приложения
Идея очень проста: никогда не
станет возможно создать
универсальную систему управления
базами данных, которая будет
достаточна и не избыточна для
применения в любом приложении.
Например, если посмотреть на
использование универсальных
коммерческих СУБД (например, Oracle
или Informix) в российской
действительности, то можно легко
увидеть, что по крайней мере в 90%
случаев применяется не более чем 30%
возможностей системы. Тем не менее,
приложение несет всю тяжесть
поддерживающей его СУБД,
рассчитанной на использование в
наиболее общих случаях.
Поэтому очень заманчиво
производить не законченные
универсальные СУБД, а нечто вроде
компиляторов компиляторов (сompiler
compiler), позволяющих собрать систему
баз данных, ориентированную на
конкретное приложение (или класс
приложений). Рассмотрим простые
примеры:
В системах резервирования
проездных билетов запросы обычно
настолько просты (например,
"выдать очередное место на рейс SU
645"), что нет особого смысла
производить широкомасштабную
оптимизацию запросов. С другой
стороны, информация, хранящаяся в
базе данных настолько критична (кто
из нас не сталкивался с проблемой
наличия двух или более билетов на
одно место?), что особо важным
является гарантированные
синхронизация обновлений базы
данных и ее восстановление после
любого сбоя.
С другой стороны, в
статистических системах запросы
могут быть произвольно сложными
(например, "выдать количество
холостых особей мужского пола,
проживающих в России и имеющих не
менее трех зарегистрированных
детей"), что вызывает
необходимость использования
развитых средств оптимизации
запросов. С другой стороны,
поскольку речь идет о статистике,
здесь не требуется поддержка
строгой сериализации транзакций и
точного восстановления базы данных
после сбоев. (Поскольку речь идет о
статистической информации, потеря
нескольких ее единиц обычно не
существенна.)
Поэтому желательно уметь
генерировать систему баз данных,
возможности (и соответствующие
накладные расходы) которой в
достаточной степени соответствуют
потребностям приложения. На
сегодняшний день на коммерческом
рынке такие "генерационные"
системы отсутствуют (например, при
выборе сервера системы Oracle вы не
можете отказаться от каких-либо
ненужных для вашего приложения его
свойств или потребовать наличия
некоторых дополнительных свойств).
Однако существуют как минимум два
экспериментальных прототипа - Genesis
и Exodus.
Обе эти генерационные системы
основаны прежде всего на принципах
модульности и точного соблюдения
установленных интерфейсов. По сути
дела, системы состоят из
минимального ядра (развитой
файловой системы в случае Exodus) и
технологического механизма
программирования дополнительных
модулей. В проекте Exodus этот
механизм основывается на системе
программирования E, которая
является простым расширением Си++,
поддерживающим стабильное
хранение данных во внешней памяти.
Вместо готовой СУБД
предоставляется набор
"полуфабрикатов" с
согласованными интерфейсами, из
которых можно сгенерировать
систему, максимально отвечающую
потребностям приложения.
Предыдущая
глава || Оглавление
|| Следующая глава
|
