Стратегические направления в системах баз данных

2009 г.

Стратегические направления в системах баз данных

А.Зильбершац, С.Здоник
Перевод: М.Р. Когаловский

Источник: журнал Системы Управления Базами Данных # 4/1997, издательский дом «Открытые системы»
Новая редакция: Сергей Кузнецов, 2009 г.

Оригинал: Avi Silberschatz, Stan Zdonik. Database Systems Breaking Out of the Box. ACM Computing Surveys, v.28, no.4, December 1996. Текст доступен здесь.

Содержание

4.1. "Мгновенное" виртуальное предприятие
4.2. Персональные информационные системы

5. Препятствия

5.1. Накладные расходы
5.2. Масштаб
5.3. Организация схемы
5.4. Качество данных
5.5. Неоднородность
5.6. Сложность запросов
5.7. Простота использования
5.8. Безопасность
5.9. Гарантирование допустимых последствий
5.10. Внедрение технологий

1. Введение

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

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

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

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

Если теперь посмотреть на ту информацию, которую используют люди, то можно встретить много примеров, в которых бросается в глаза отсутствие систем баз данных. Одним из наиболее впечатляющих примеров является World Wide Web. Хотя справедливо утверждать, что поставщики СУБД делают свои продукты применимыми в среде Web (Web-enable), из подход состоит в том, чтобы обеспечить улучшенные Web-серверы. Такая возможность представляет собой лишь весьма небольшой шаг в направлении развития управления огромными объемами нестандартных данных, существующих в Web. Сомнительно, чтобы этот шаг заставил сотни тысяч Web-узлов перейти к использованию функционально полных систем баз данных, ориентированных на рынок обработки бизнес-данных.

К числу других примеров приложений, в рамках которых можно было бы извлечь пользу из технологий управления данными, но которые обычно в полной мере не используют программных продуктов, предназначенных для систем баз данных, относятся персональные информационные системы, службы новостей и научные приложения. В случае персональных информационных систем можно мыслить лишь об информации, которая хранится в обычной персональной ЭВМ. Электронная почта имеет огромное личное значение для многих пользователей, но когда сохраняются сообщения, они запоминаются чаще всего в файловой системе. Было бы чрезвычайно полезно иметь такие средства СУБД, как индексирование и обработка запросов, доступными для использования в электронной почте. Хотя появляется некоторая поддержка более организованного подхода к хранению и выборке электронной почты (например, в Lotus Notes), более утонченные средства запросов пока еще хорошо не проработаны.

В других недавних отчетах [Gray95, SSU91, SSU95] были охарактеризованы направления исследований в области баз данных, а также великолепно проведена работа по определению приоритетов текущих исследовательских проблем и по установлению новых факторов, связанных с их влиянием на индустрию систем баз данных. В этом отчете¹ решается несколько иная задача – показать, что исследования в области баз данных должны быть посвящены проблемам управления данными, независимо от того, где и в какой форме данные могут находиться. Мы не должны строго ограничиваться сформировавшимся пространством продуктов или широко поддерживаемым мнением о том, что наша работа заключается в управлении очень большими совокупностями структурированных записей в управляемой среде. Вместо этого мы должны использовать наши профессиональные знания для новых сред управления данными, которые потенциально требуют радикально новых подходов к архитектурам программного обеспечения.

2. Предпосылки

Технология баз данных возникла в конце 60-х годов с реализацией IMS, программного продукта компании IBM, который обеспечивал управление данными, организованными в форме иерархий². Хотя позднее оказалось, что иерархии слишком ограничены, важным вкладом IMS стало широко признанное открытие, констатирующее, что данные имеют самостоятельную ценность, и что они должны управляться независимо от какого-либо отдельного приложения. До этого приложения обладали собственными файлами данных, в которых часто дублировались данные из других файлов. При использовании СУБД данные не должны логически реплицироваться, что облегчает их поддержку. Для создания совместно используемых баз данных потребовались анализ и проектирование, балансирующие требования нескольких приложений и, тем самым, улучшающие бы общее управление ресурсами данных.

Модели данных как IMS, так и ее весьма широко известного преемника – CODASYL³, основывались на графовых структурах данных. Хотя идея навигационных связей была интуитивно привлекательной, при ее использовании было трудно выражать взаимодействие с базой данных независимо от существующих алгоритмов, которые были необходимы для реализации таких связей.

В 1970 году Тэд Кодд опубликовал свою историческую статью [Codd70], в которой была показана возможность управления данными на существенно более высоком уровне благодаря их концептуализации в терминах математической теории отношений. Эта статья вызвала большой интерес в научном сообществе в 70-е годы и стремление практически воплотить такой подход. В настоящее время реляционная модель имеет наиболее широкую поддержку среди поставщиков коммерческих СУБД. Благодаря простоте и ясным концептуальным основам реляционной модели вокруг нее развернулись активные теоретические исследования. Исследователями было получено много важных результатов, в том числе, были разработаны теория проектирования баз данных, теория выразимости и сложности языков запросов, а также расширение реляционных языков, названное Datalog. Теоретические разработки продолжаются во многих направлениях, включая, например, исследования ограничений в базах данных и запросов с использованием неполной информации.

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

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

3. Что мы умеем?

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

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

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

Хорошая модель данных должна быть достаточно выразительна для того, чтобы охватывать широкий класс приложений, и, кроме того, должна допускать эффективную реализацию. Несмотря на то, что реляционная модель была доминирующей на протяжении последнего десятилетия, имеются явные признаки потребности в более мощных и гибких моделях. Разработка и использование моделей данных являются важными темами исследований в сообществе специалистов по базам данных, а расширение этих моделей с целью включения в них более сложных типов данных, таких как электронные таблицы и потоки видеоданных, является важным направлением исследований для построения будущих реализациий.
Языки запросов. Запрос представляет собой программу, которая записывается на языке высокого уровня и обеспечивает выборку данных из базы данных. Структура запроса к базе данных относительно проста, что позволяет легко его понимать, автоматически генерировать и оптимизировать. Многие современные языки запросов (например, SQL) являются декларативными, поскольку они выражают, что должно быть возвращено из базы данных, без каких-либо ссылок на структуры хранения или алгоритмы доступа к этим структурам. Поскольку на уровне запроса не может указываться какой-либо способ его реализации, процессор запросов свободен в выборе стратегии обработки. Более того, отделение запроса от реализации означает, что структуры хранения могут изменяться, не приводя к недействительности существующих выражений запросов.
Оптимизация и обработка запросов. Реляционные базы данных стали коммерческой реальностью благодаря хорошо продуманным оптимизаторам реляционных языков запросов и разработке эффективных алгоритмов обработки запросов. Способность компилировать запросы в планы исполнения на основе форм запросов, а также текущих структур хранения на диске, является важной составной частью разработки систем баз данных. Технология оптимизации является особенно важной для выборки данных и манипулирования ими в тех случаях, когда степень риска выбора неэффективной стратегии является высокой, и всякий раз, когда могут изменяться условия среды, на которых основан план исполнения.
Представления, основанные на состоянии. C использованием языка запросов можно определять ограниченные и, может быть, реорганизованные представления базы данных. Такие представления, основанные на состоянии, часто используются для ограничения доступа к данным. Мы можем, например, ограничить использование базы данных представлением, содержащим средние значения зарплаты по отделам, исключив из него отделы, в которых работает менее трех служащих. В файловых системах авторизация доступа обычно основывается на привилегиях доступа, ассоцируемыми с каждым файлом, независимо от его содержимого.
Управление данными. В системах баз данных всегда уделялось особое внимание автоматической поддержке структур данных, подобных индексам, и эффективному перемещению данных в системные буфера и из них. Обычно эти средства управления данными хорошо настраиваются на конкретные используемые запоминающие устройства. Такой подход к бережному использованию ресурсов может быть расширен на другие области, в которых в состав устройств включают, например, линии связи и третичная память.
Транзакции. Сообщество баз данных разработало концепцию транзакции в ответ на возникновение проблем корректности, связанных с параллельным доступом и обновлением. Принятие критерия корректности, основанного на атомарности транзакций, упростило программирование, поскольку программист больше не должен беспокоиться относительно помех, порождаемых другими программами.

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

В последнее время исследуются также и другие, ослабленные концепции транзакций. Обычно они основываются на понятии корректности, задаваемом пользователями.
Распределенные системы. Системы баз данных должны иметь дело с проблемами, возникающими в связи с наличием данных, которые распределены между несколькими машинами. Протокол двухфазной фиксации (two-phase commit) позволяет системе сохранять преимущества атомарных транзакций при наличии распределенных и, возможно, ненадежных активностей. К числу других областей, исследовавшихся в распределенном контексте, относятся обработка запросов, обнаружение тупиковых ситуаций, а также интеграция неоднородных данных.
Масштабируемые системы. Базы данных всегда имели дело с очень большими наборами данных. Системы баз данных настраивались, по большей части, на эффективное и надежное управление такими объемами данных, которые превышают размер физической памяти на несколько порядков. Такой подход использовался, главным образом, по той причине, что системы баз данных с успехом находили применение в реальных коммерческих средах.

Мы не считаем приведенный список исчерпывающим. Скорее, он иллюстрирует некоторые важные технологии, которые были созданы специалистами, занимающимися исследованиями и разработками в области баз данных. Исследовались также и другие области, в частности, активные базы данных и интеллектуальный анализ данных (data mining).

¹ В июне 1996 года Лаборатория информатики Массачусетского технологического института (США) при поддержке ACM, National Science Foundation и ряда других организаций провела симпозиум "Strategic Directions in Computing Research". На симпозиуме были представлены обзорные доклады о стратегических направлениях развития практически по всем крупным разделам информатики. Для подготовки докладов было создано более двух десятков рабочих групп, в состав которых вошли известные специалисты в соответствующей области. Предлагаемая читателю статья представляет собой отчет, подготовленный рабочей группой по базам данных под редакцией авторов. От этой рабочей группы в симпозиуме участвовали Х.Блейкли (Jose Blakeley), П.Бунеман (Peter Buneman), У.Дайал (Umesh Dayal), Т.Имилинский (Tomasz Imielinski), С.Джаджодиа (Sushil Jajodia), Х.Корт (Hank Korth), Г.Лохман (Guy Lohman), Д.Ломе (Dave Lomet), Д.Майер (Dave Maier), Ф.Манола (Frank Manola), Т.Озу (Tamer Ozsu), Р.Рамакришнан (Raghu Ramakrishnan), К.Рамамритан (Krithi Ramamritham), Х.Шек (Hans Scheck), А.Зильбершац (Avi Silberschatz, сопредседатель), Р.Снодграсс (Rick Snodgrass), Д.Ульман (Jeff Ullman), Д.Вайдом (Jennifer Widom) и С.Здоник (Stan Zdonik, сопредседатель). Материалы симпозиума были опубликованы в специальном выпуске журнала ACM Computing Surveys, v.28, no.4, December 1996. – Прим. пер.

²⁾ Вряд ли можно согласиться с этим мнением авторов. Хотя создание системы IMS (1969 год) действительно было значительным событием в становлении технологии баз данных, однако, еще до появления этой системы был осуществлен ряд других весьма значимых разработок в этой области. В частности, примерно за шесть лет до выпуска IMS была реализована система IDS (Integrated Data Storage), ставшая прототипом подхода CODASYL, оставившего не менее глубокий след в технологии баз данных, чем создание системы IMS. Руководитель этой разработки – Ч.Бахман - стал впоследствии лауреатом премии Тьюринга за работы в области систем баз данных, основанных на подходе CODASYL. Описание возможностей системы IDS и ряда других ранних СУБД можно найти в изданном в русском переводе техническом отчете Системного комитета CODASYL 1971 года "Feature Analysis of Generalized Data Base Management Systems" (см. Информационные системы общего назначения. Пер. с англ. – М.: Статистика, 1975). Нужно упомянуть также, что еще в 1963 и в 1965 годах компания System Development Corporation (США) провела два симпозиума по управлению базами данных, где были представлены конкретные реализованные проекты систем баз данных. Таким образом, технология баз данных возникла еще задолго до появления системы IMS. – Прим. пер.

³⁾ Здесь мы снова вынуждены возразить авторам. Подход CODASYL вовсе не является преемником IMS. В идейном плане он, как уже мы указывали, скорее, последователь идей системы IDS (см. предыдущую сноску). Кроме того, авторы противоречат и хронологии событий. Первая версия системы IMS была выпущена компанией IBM в 1969 году. Первый отчет CODASYL DBTG, содержащий не только основные концепции предложенного DBTG подхода (кстати говоря, существенно более продвинутого, с архитектурной точки зрения, по сравнению с IMS), но и начальный вариант спецификаций языка определения данными схемы, а также языка манипулирования данными и языка определения данных подсхемы для включающего языка COBOL, был опубликован также в 1969 году. Таким образом, эти работы проводились, по крайней мере, одновременно. – Прим. пер.

Содержание Вперёд