Лента

Кризис баз данных и проблема выбора:
повестка дня до 2001 года^*)

Дэвид Васкевич

Проблемы Баз Данных

Повестка дня на десятилетие

2001 : Одиссея Баз Данных

Литература

Данная статья в общих чертах обрисовывает некоторые важные проблемы, с которыми столкнулось сообщество баз данных, и предлагает подход к решению некоторых из них. Эти предложения в настоящее время разрабатываются в Enterprise Group корпорации Microsoft. Статья завершается сценарием 2001 года, отражающим представление Microsoft об "Информации на кончиках ваших пальцев".

Проблемы Баз Данных

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

Очевидно, с одной стороны, базы данных и технологии баз данных - одни из основных столпов современного компьютерного мира. Банки, производственные компании, авиалинии и организации всех размеров зависят от своих СУБД каждый день и в любом виде деятельности. Продукты баз данных, такие как DB2, Oracle, SQL Server, IMS и их кланы, например CICS, достигают миллиардов долларов продаж ежегодно. И наконец, ни одно компьютерное подразделение, большая исследовательская группа, серьезная консалтинговая фирма, или поставщик систем не могут считаться таковыми без наличия по крайней мере одной специализированной группы баз данных.

В то же время, индустрия баз данных часто выглядит идущей не в ногу с изменениями остального мира; общество попало в своего рода временную петлю типа "назад в будущее". Например, большинство организаций, поддерживающих наибольшие реляционные и нереляционные системы баз данных, сейчас хранят больше данных на десктопах, чем в своих БД. Этими данными на десктопах, часто хорошо структурированными по своей природе, управляет все, что угодно, но не системы управления базами данных. В действительности, по любым объективным оценкам, база данных номер один в Западном Мире - не DB2, не Oracle, даже не IMS, но скорее 1-2-3, с идущим за ним по пятам Excel. И где же здесь академическая, т.е. явно описывающая интеграцию хранилищ данных в современную объединенную систему, архитектура базы данных?

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

Двигаясь ближе к центру вселенной баз данных, мы придем, в конечном счете, к модели данных. Здесь и академическая литература, и поставщики коммерческих систем более или менее в одинаковой степени далеки от реальности. В одном углу ринга - поставщики реляционных систем, представляющие процветающую индустрию c оборотом в два миллиарда долларов в год и убежденные, что их продукты владеют миром. Посещение семинара по технологии клиент/сервер - путь к потере убеждения, что SQL и РСУБД являются основой доступа ко всем промышленным данным в прошлом, в настоящем и в будущем. В другом углу ринга - готовящееся к бою с господствующим большинством сообщество ООСУБД, стойко преданное идеям персистентных языков, сложной структуры данных и изощренной навигации. Мы должны выбирать? Являемся ли мы свидетелями процесса смены поколений? Возможно. Но что же с двумя другими соперниками, молча сидящими в двух других углах ринга? В каких углах, вы спросите? Пожалуйста, слева - наши старые друзья IMS, IDMS и их партия. По данным Gartner Group, эти старые приятели до сих пор ответственны почти за половину всех мировых производственных данных. И это еще не все... В том же углу с IMS находятся VSAM, RMS и более современный Btrieve. Вместе с ними ISAM и предреляционные базы данных, оказывается, содержат около 75% данных, действительно использующихся в организациях. Ощущаем ли мы теперь реалии? Если нет, нам остается только взглянуть на четвертый угол ринга и увидеть там ждущие нашего внимания, уже упомянутые электронные таблицы и другие средства хранения баз данных на декстопах. В то время пока все спорят, где хранятся реальные или наиболее важные производственные данные, десктопы выросли в размерах и значимости до того уровня, когда они содержат по меньшей мере столько же данных, сколько все серверы, мэйнфреймы и мини вместе взятые.

Вопрос, который нужно задать о всех этих обработчиках данных, следующий: останутся ли действительные, истинные базы данных? Сообщество баз данных будет настойчиво утверждать, что реляционные базы данных - настоящее, а объекты в какой-либо форме - будущее. Означает ли это, что сетевые и иерархические базы данных вообще не являются базами данных? И если ни одна из баз данных, достойных этого имени, не предлагает простоты и функциональности ISAM, электронной таблицы или paradox, то что это означает? Согласятся ли пользователи электронной таблицы, что их данные не являются на самом деле данными и их база данных - не база данных вообще?

Чтобы увидеть дилемму, с которой мы столкнулись в ее истинной перспективе, давайте рассмотрим одну из последних запутанных загадок действительности. Для большинства профессионалов баз данных распределенные данные и двухфазная фиксация (2PC) идут рука об руку. Характерной чертой больших систем, построенных на основе протокола двухфазной фиксации, является то, что отказы могут легко привести к остановке всей системы. То есть, если существует много взаимоблокирующих транзакций и набор межузловых зависимостей, при выходе из строя узлов и коммуникационных линков большинство частей сети остановится до восстановления узлов/линков. Конечно же, 2PC гарантирует, что система в целом выработает в итоге верные результаты, но, все-таки, система может показаться очень хрупкой. Различные попытки индустрии обеспечить лучшую обработку отказов в подобных ситуациях не являются общепринятыми. Очевидное утверждение состоит в том, что централизованная система с продублированной аппаратурой должна иметь большее время готовности. Существует ли что-то сильно противоречащее интуитивной идее о том, что распределенное решение может быть менее надежно, чем централизованное? Конечно же, должны существовать способы построения распределенных систем, более, а не менее надежных, чем централизованные.

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

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

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

Повестка дня на десятилетие

В Microsoft мы работаем сейчас над переосмыслением самого значения термина база данных. В процессе этого переосмысления мы столкнулись с рядом важных проблем, требующих решения либо нами, либо нашими партнерами. Некоторые из этих проблем описаны ниже. Читатель может обратиться к статье IEEE в [ONETAL] для получения более подробного изложения технического подхода Microsoft к этим проблемам. Многие из них не имеют в настоящий момент общепринятого подхода, и, кроме того, будучи важными проблемами самими по себе, они являются также своего рода вызовом сообществу баз данных в целом.

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

- Интероперабельные Базы Данных. Составные базы данных с открытыми интерфейсами являются, по определению, интероперабельными базами данных. Процессор запросов может извлекать данные от поставщиков записей любого вида. Может быть разработано множество типов поставщиков запросов. Электронная таблица может выдавать себя за базу данных, действуя как соответствующий компонент. Географический процессор запросов может извлекать данные из нижележащего уровня хранения, также легко, как и реляционный процессор запросов.

В среде интероперабельной базы данных пользователь может создавать и работать с финансовыми данными в электронной таблице, работающей как электронная таблица. В то же время, Финансовый Директор (CFO) может консолидировать данные из многих электронных таблиц (и менеджеров проектов и баз данных), используя классический реляционный механизм запросов и рассматривая всю систему как истинную базу данных, функционирующую как база данных.

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

- Распределенные базы данных. Сколько баз данных будут существовать к 2001 году? Сколько компьютеров? Многие миллионы. В действительности, сотни миллионов. Из этого следует, что базы данных должны быть в высокой степени распределенными. Что, в свою очередь, означает, во-первых, - базы данных должны быть полностью самоустанавливающимися и самоуправляемыми. Во-вторых, это означает, что взаимодействие между базами данных должно быть автоматическим и высоконадежным. Но прежде всего это означает, что такая распределенная инфраструктура должна быть очень хорошо сбалансирована.

- Процессы, а не задачи. Классические базы данных и мониторы обработки транзакций (TP Monitors) обрабатывают транзакции и задачи в реальном времени. По определению, транзакция рассматривается как атомарное действие, одиночное событие, которое либо происходит целиком, либо не выполняется вообще. Реальный мир, однако, состоит из последовательностей задач, выполняющихся в течение очень больших интервалов времени. (См., например, [GARSAL].) Базы данных и окружающая их инфраструктура должны быть разработаны так, чтобы обрабатывать длительные последовательности транзакций.

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

- Богатые модели данных. Нормализованные данные - это прекрасно, когда нормализация обусловлена проектированием. Часто, однако, более сложные структуры данных являются и более естественными, и более эффективными (как это видно из объектно-ориентированных реляционных моделей баз данных, и продуктов, которые производят, например, UniSQL и Montage). Таким же образом, представление связей "многие-ко-многим" часто бывает рискованным, но часто и предоставляет преимущества. Двадцать лет практики обучили нас, что иногда нормализованные таблицы это правильно, а иногда нет; базы данных будущего должны предоставлять такой выбор.

- Базы данных, а не языки. Одним из следствий модели составной базы данных является то, что нижележащая база данных становится независимым и отдельным компонентом от любой высокоуровневой языковой среды. Сегодня большинство современных баз данных тесно ограничены либо SQL, либо некоторым объектно-ориентированным языком типа C++/Smalltalk. Такое связывание имеет сильные преимущества для многих приложений, но существуют случаи, когда разработчик хочет использовать только менеджер базы данных, не желая выбирать определенный язык, объектную модель или дисциплину разработки. В составном мире будущего такое разделение станет возможным и естественным. Одно из следствий - возможность создания нового класса поставщиков записей, каждый из которых унаследует всю среду более высоких уровней. Таким образом, разработчик нового менеджера проекта, например, используя соответствующие методы, может создать компонент, поставляющий записи. Среда языка высокого уровня, базирующаяся на SQL или на объектно-ориентированном подходе, может обращаться к этому поставщику записей так же, как и к любому другому.

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

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

- Сервер, Десктоп, Лаптоп. Сотни миллионов серверов представляют только небольшую часть распределенной модели будущего. Каждый из многочисленных серверов будет поддерживать дюжины десктопов. И, многие из этих десктопов часто будут превращаться в ноутбуки или лаптопы. Даже сегодня, на десктопах, лаптопах и "на руках" содержится столько же данных, сколько и на серверах; в будущем это соотношение изменится еще больше, и не в пользу серверов. В мире с миллиардами баз данных как мы мыслим репликацию, распределенные транзакции, процессы и тому подобное? На что должна быть похожа административная модель, и как она будет функционировать в полностью децентрализованной среде?

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

- Память. Представьте себе действительно большой сервер, поддерживающий несколько сотен настольных компьютеров. Допустим, этот сервер имеет 500 Мбайт памяти. Сколько памяти имеет каждая рабочая станция? Если ответ - 25-50 Мбайт, то сколько памяти имеют все рабочие станции в целом? В нашей ситуации совместная память персональных компьютеров составляющая, скажем, 5000 Мбайт, значительно превышает память сервера. Как нам разрабатывать системы баз данных, чтобы извлечь выгоды из такой ситуации? ООБД выполняют что-то подобное, и довольно хорошо в настоящий момент, но насколько хорошо они будут функционировать при обработке больших запросов, где работа может быть разделена между несколькими компьютерами? И касаясь реляционных баз данных, как много преимуществ из двухуровневой архитектуры памяти они извлекают?

Эту проблему можно рассматривать по другому, пытаясь ответить на вопрос : где приложения хранят свои частные структуры данных? Конечно же, не в классических базах данных: слишком медленно и негибко. Возможно, в ООБД. Цель девяностых годов должна состоять в том, чтобы все приложения переместили большую часть своих частных структур данных под управление менеджеров баз данных. Почему об этом нужно думать? Чтобы упростить запросы, управление параллельностью, предоставить возможность восстановления данных и т.д.

Более подробное изложение некоторых из этих проблем дано в [VASK1,VASK2].

2001 : Одиссея Баз Данных

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

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

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

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

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

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

Литература

[GARSAL] H.Garcia-Molina and K.Salem, "Sagas," ACM SIGMOD proceedings,1987.
[ONETAL] patrick E. O"Neil, Mohsen Al-Ghosein, David Vaskevitch, Rick Vicik, Laura Yedwab, "Transaction processing at Microsoft: present and Future," IEEE Bulletin on Data Engineering, March 1994
[VASK1] David Vaskevitch, position paper for Workshop on High performance Transaction Systems, Sept. 1993, Asilomar CA.
[VASK2] David Vaskevitch, "Microsoft"s Vision for the Transaction Environment," OTM Spectrum Reports, v.8, no. 1, February 1994. Spectrum Reports Ltd., MCI Mail: 3138708