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