Будущие направления исследований в области баз данных: десять лет спустя

Сергей Кузнецов

В феврале 1988 г. 16 ведущих исследователей из США и Германии провели двухдневный симпозиум, посвященный обсуждений основных тем исследований в области баз данных в будущем. Симпозиум был организован университетом Беркли (Калифорния, США) и немецкой организацией GMD (Gesellschaft fur Mathematik und Datanvarebeitung) и проходил в Лагуна Бич недалеко от Лос-Анжелеса. После симпозиума в журнале SIGMOD Record (V. 18, No. 1, 1988) был опубликован отчет, который официально назывался Furure Directions in DBMS Research, но получил народное название Laguna Beach Report (к сожалению, до сих пор этот текст недоступен в Internet). Нам кажется, что спустя десять (с лишним) лет интересно вспомнить прогнозы и оценить их правильность (особенно в связи с новым отчетом, содержащем прогнозы на следующие десять лет). Комментарии и оценки выделяются курсивом. Далее мы будем следовать структуре отчета, кратко его пересказывая и давая свои оценки (конечно, полностью субъективные).

1. Будущие приложения

В этом разделе отчета приводится сводка мнений участников относительно наиболее важных приложений баз данных.

1.1 CASE

Область CASE обсуждалась с точки зрения требований таких систем к поддерживающим их базам данных. Отмечались такие потребности как версионность, поддержка сложных объектов, наследование и т.д.

Насколько мне известно, в последние десять лет производители CASE-средств в основном продолжали использовать чисто реляционные базы данных, хотя и стали обеспечивать в последнее время возможности проектирования информационных систем, основанных на объектно-ориентированных и объектно-реляционных базах данных.

1.2 CIM

Небольшая часть участников отмечала важность области Computer Integrated Manufacturing (CIM). Указывалась потребность таких приложений во встроенных в базу данных правилах и триггерах.

По-моему, прогноз оправдался.

1.3 Графические образы

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

Естественно, такая возможность появилась.

1.4 Пространственные базы данных

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

И были правы, поскольку сегодня все развитые системы (например, Oracle, Informix, DB2 и т.д.) поддерживают управление пространственной информацией.

1.5 IR (Information Retrieval)

Один участник думал, что важно поддерживать приложения, связанные c информационным поиском (то, что сейчас принято называть приложениями полнотекстовых баз данных).

И действительно, универсальные расширяемые СУБД теперь имеют средства, поддерживающие информационно-поисковые системы, хотя о качестве этих средств можно спорить.

2. Будущая аппаратная среда

2.1 Революция

По отношению к технологии процессоров считалось, что будущее за RISC-технологией. Ожидалось, что к 1991 году компьютер с производительностью в 50 MIPS и основной памятью размером с гигабайт будет стоить меньше 100000 долларов.

Как мы видим, этот прогноз не сбылся. Во-первых, большая часть рынка процессоров занята суперскалярными микропроцессорами Intel. Во-вторых, уменьшение соотношения цена-производительность происходило гораздо быстрее, и по моим понятиям сегодня машину с такими показателями можно купить раз в десять дешевле.

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

Да, и это привело к появлению таких промышленных технологий, как параллельные sharing-nothing системы баз данных.

Отмечалась возможность широкого внедрения систем поддержки принятия решений по мере снижения цен аппаратуры.

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

Считалось, что объемы требуемых баз данных будут возрастать быстрее снижения цен на дисковую и основную память и поэтому по-прежнему потребуются исследования, направленные на повышение эффективности баз данных.

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

2.2 Машины баз данных

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

И были совершенно правы.

3. Будущая программная среда

3.1 Операционные системы

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

Я не уверен, что это предсказание сбылось. Большая часть работ в области операционных систем за последние десять лет была связана с переходом на 64-х разрядные архитектуры.

Будут поддерживаться коммуникационные протоколы стека ISO и специализированные протоколы типа NFS.

Конечно, NFS поддерживается во всех вариантах ОС UNIX. Но что касается ISO/OSI, то поддержка этого стека так и не стала повсеместной практикой.

Реструктуризация ОС к виду, имеющему малое ядро с набором сервисов поверх его.

Условно можно считать, что так выглядит Windows NT, хотя далеко не все с этим согласны. Что же касается мира UNIX, то переход на микроядерную архитектуру в широких масштабах так и не произошел.

Существуют потребности встраивания поддержки транзакций в ядро ОС.

Пока примеров таких реализаций нет.

Сохранятся интерфейсы существующих ОС (например, MVS).

Так и случилось.

3.2 Интерфейсы языков программирования

Некоторые участники считали важным улучшить существующий ужасный интерфейс SQL для встроенных и динамических запросов.

Похоже, что этот ужасный интерфейс будет существовать до смерти SQL.

В течение многих лет не появится стандарт интерфейса 4GL.

Пока не видно даже движений в этом направлении.

3.3 Пролог

Был выражен пессимизм в отношении связывания Пролога с СУБД. Многие участники считали, что следует прекратить финансировать соответствующие проекты.

Пессимизм, возможно, оправдан, но проекты существуют и в настоящее время.

4. Расширяемые менеджеры данных

Обсуждение разбилось на два направления - расширяемые архитектуры и объектно-ориентированные базы данных.

4.1 Расширяемые архитектуры

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

Как мы видим сейчас, в большей степени сработал первый подход. На основе POSTGRES через Illustra возник Informix Universal Server, а Starburst явился основой DB2 Universal Database. Вместе с тем, второй подход тоже остается перспективным, и в этом направлении движется, например, компания Sybase.

4.2 Объектно-ориентированные базы данных

Обсуждение затрудняло то обстоятельство, что в области ООБД отсутствовал общепринятый набор терминов и определений (эта ситуация сохраняется и сегодня). Сторонники ООБД выдвигали два основных аргумента. Во-первых, они утверждали, что ООБД представляют хорошую основу расширяемых СУБД. Во-вторых, идея наследования может быть упрощена до уровня, понимаемого разработчикам приложений. У противников тоже имелись два аргумента. (1) ООБД по своей природе не слишком пригодны для непредвиденных запросов и поэтому не подходят для систем поддержки принятия решений. (2) Типичный для ООБД навигационный интерфейс доступа возвращает нас во времена CODASYL. Однако реальной проблемой являлось то, что термин "объектная ориентированность" относился к слишком большому числу различных вещей.

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

5. Активные базы данных и системы правил

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

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

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

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

6. Интерфейсы конечного пользователя

Отмечалось, что в исследовательском сообществе баз данных уделялось слишком мало внимания пользовательским интерфейсам. Некоторые участники говорили, что лучшим интерфейсом является такой, для использования которого не требуется руководства.

Мне кажется, что за прошедшие десять лет ситуация радикально не изменилась. Конечно, прочно вошли в практику оконные системы, появились развитые интерфейсы OLAP и администраторов баз данных, но революции не произошло.

7. Технология централизованных СУБД (Single Site DBMS)

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

Пожалуй, в прошедшие десять лет больше внимания компании-производители СУБД уделяли именно параллельным симметричным архитектурам. Достигнуты очень существенные (возможно, предельные) результаты. Что же касается основной и дисковой памяти, то рост объемов и снижение стоимости оказались не столь значительными, и соответствующие изменения в технологии теперь ожидаются в следующем десятилетии.

Существует потребность в более высокой доступности баз данных и в более развитых возможностях обработки сбоев.

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

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

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

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

Эта область почти полностью перешла в промышленность. Компании сделали очень много за десять лет, и направления были угаданы почти точно. Единственное, что угадать не удалось, - это появление битовых индексов (Bit-Map Indexes), активно применяемых теперь в хранилищах данных.

8. Распределенные СУБД

Полагалось, что компании-производители потратят много усилий на развитие области неоднородных (федеративных) распределенных систем баз данных. Увеличение масштабности распределенных баз данных потребует переосмысления алгоритмов обработки запросов, копирования и восстановления после сбоев.

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

9. Разнородные темы

9.1 Физическое проектирование баз данных

Участники пришли к согласию, что требуется построения средств автоматического проектирования физической схемы баз данных, включая добавление и уничтожение индексов, балансировку загрузки дисков и т.д.

Как мы видим, предсказание частично сбылось только к концу 1998 г., когда в Microsoft SQL Server 7.0 появились средства автоматизированной поддержки набора индексов. Автоматизированная балансировка загрузки дисков пока остается на будущее.

9.2 Средства проектирования

Средства проектирования в то время представляли собой всего лишь графические рисовальные системы. Некоторые участники считали, что требуется их развитие, хотя и не знали, в каком направлении.

Конечно же, ситуация значительно изменилась.

9.3 Базы данных реального времени

Отмечалась важность этого направления и необходимость поддержки соответствующих исследований.

Направление по-прежнему существует, но нельзя сказать, что достигнуты значительные результаты.

9.4 Модели данных

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

Работ в этой области было действительно мало, а стандартную модель многие хотели бы видеть, но пока шансов немного.

9.5 Трансляция данных

Один участник отмечал важность проблемы трансляции данных в неоднородных компьютерных средах. Большинство участников выразило уверенность, что эта проблема уже решена.

В принципе, они были правы, потому что уже существовал протокол XDR (External Data Representation). Однако, насколько мне известно, позже к этой проблеме вернулись при разработке протокола IIOP (Internet Inter-ORB Protocol).

9.6 Обмен информацией через базы данных

Некоторые участники отмечали потребность на наличии стандартного общего представления данных. Для этого требуются более сложные справочники данных.

Видимо, стандартизация метаинформации все еще остается проблемой.