Распределенные
базы данных
(глава
из книги)
Управление
распределенными базами данных
Одной
из главных тенденций в вычислительной
технике в течение последних
десяти лет был переход от больших ЭВМ,
представляющих собой централизованные
системы, к распределенным компьютерным
системам, объединенным в вычислительные
сети. С появлением мини-ЭВМ такие задачи
обработки данных, как учет товарных запасов
и обработка заказов, были перенесены
с больших корпоративных ЭВМ на небольшие
вычислительные системы, обслуживающие
отдельные подразделения, входящие в состав
предприятия. Стремительный рост популярности
персональных компьютеров в восьмидесятые
годы привел к их появлению на рабочих
столах у миллионов людей.
С
увеличением числа компьютеров
в организациях и появлением компьютерных
сетей данные перестали размещать в одной
вычислительной системе, работающей под
управлением одной СУБД. Вместо этого
информацию начали распределять по различным
системам, каждая из которых имеет собственную
СУБД. Зачастую такие вычислительные системы
и СУБД поставляются различными изготовителями.
Описанная
тенденция привела к тому, что
в компьютерной промышленности внимание
специалистов по обработке данных сосредоточилось
на проблемах управления распределенными
базами данных. В настоящей главе рассматриваются
задачи, возникающие при работе с распределенными
данными, а также программные продукты,
предлагаемые для решения этих задач основными
поставщиками СУБД.
Проблемы
управления распределенными данными
На
рис. 20.1 схематически показана часть
компьютерной сети, которую можно встретить
на производственном предприятии или
фирме, специализирующейся на оптовой
торговле. Данные хранятся в разнообразных
вычислительных системах, объединенных
в сеть:
- Большие
ЭВМ. Основные приложения по обработке
данных на этом предприятии, такие как
программы бухгалтерского учета и начисления
зарплаты, выполняются на большой ЭВМ
производства компании IBM. Разработанные
в течение последних 20 лет приложения
работают с базами данных IMS; новое приложение,
которое начнет эксплуатироваться в этом
году, будет использовать базу данных
DB2.
- Мини-ЭВМ.
Технические службы предприятия использует
для своих нужд мини-ЭВМ VAX, базу данных
Ingres и приложения, работающие в режиме
разделения времени. Результаты технических
испытаний хранятся в базе данных Ingres.
На шести оптовых складах предприятия
находятся мини-ЭВМ с базами данных Oracle,
которые используются для приема заказов
и учета товарных запасов.
- Серверы
ЛВС. Несколько отделов предприятия
организовали локальные вычислительные
сети (ЛВС) на основе персональных компьютеров
для совместного использования файлов
и принтеров. Отдел кадров недавно автоматизировал
систему учета кадров, используя для этого
СУБД SQL Server и операционную систему Windows
NT. В плановом отделе группой по обработке
данных создается программа планирования.
Разработчики считают, что наилучшим выбором
для данного приложения будет СУБД DB2/2,
работающая под управлением операционной
системы OS/2.
- Персональные
компьютеры. Многие служащие на предприятии
пользуются персональными компьютерами
и хранят на них свои личные базы данных,
такие как Access и Paradox, а также электронные
таблицы Excel и Lotus 1-2-3. В ряде случаев с базами
данных совместно работают несколько
пользователей, используя для этого сетевые
возможности упомянутых выше программ.
В
связи с тем что данные распределены
по различным системам, нетрудно (представить
себе потребности пользователей, связанные
с обращением сразу к нескольким базам
данных:
- Персоналу
технических служб необходимо объединять
результаты лабораторных испытаний (хранящиеся
на мини-ЭВМ VAX) с производственными планами-прогнозами
(хранящимися на большой ЭВМ), чтобы выбрать
одну из трех альтернативных технологий.
- Сотрудникам
планового отдела необходимо связывать
финансовые планы-прогнозы (хранящиеся
в базе данных DB2) с финансовыми отчетами
за прошедшие периоды (хранящимися на
большой ЭВМ).
- Управляющему
компании необходимо знать запасы каждого
изделия на каждом оптовом складе (данные
хранятся на шести мини-ЭВМ VAX), чтобы планировать
их производство.
- Ежедневно
с большой ЭВМ необходимо загружать данные
о текущих ценах на мини-ЭВМ VAX, находящиеся
на оптовых складах.
- Для корректировки
производственного плана необходимо ежедневно
с оптовых складов (мини-ЭВМ VAX) загружать
данные о принятых заказах на большую
ЭВМ.
- Руководителям
подразделений предприятия требуется
с персональных компьютеров на своих рабочих
столах выполнять запросы на чтение информации
из различных совместно используемых
баз данных.
Из
этих примеров следует, что потребность
в доступе к распределенным данным
существует и может стать наиболее важной,
так как тенденция к использованию распределенных
вычислительных систем продолжает развиваться.
Все ведущие поставщики СУБД взяли обязательство
выпустить распределенные СУБД, и некоторые
из них уже предлагают такие системы, правда,
с ограниченными возможностями. Ведущие,
да и прочие специалисты написали достаточно
много о тех особенностях, которыми должна
обладать распределенная СУБД, и к настоящему
времени достигнуто общее согласие в отношении
этих "идеальных" характеристик.
- Прозрачность
относительно местоположения.
Пользователь не должен беспокоиться
о том, где физически располагаются данные.
СУБД должна представлять все данные так,
как если бы они были локальными, и отвечать
за сохранение этой "иллюзии".
- Разнородные
системы. СУБД должна работать с данными,
которые хранятся на различных системах
с различной архитектурой и производительностью,
включая персональные компьютеры, рабочие
станции, серверы ЛВС, мини-ЭВМ и большие
ЭВМ.
- Прозрачность
относительно сети.
За исключением различий в производительности,
СУБД должна работать одинаково в различных
сетях, от высокоскоростных ЛВС до низкоскоростных,
использующих телефонные линии.
- Распределенные
запросы. Пользователь должен иметь
возможность объединять данные из любых
таблиц распределенной базы данных, даже
если эти таблицы физически расположены
в различных вычислительных системах.
- Распределенные
изменения. Пользователь должен иметь
возможность изменять данные в любой таблице,
на доступ к которой у него есть необходимые
привилегии, независимо от того, находится
ли эта таблица в локальной или удаленной
системе.
- Распределенные
транзакции. СУБД должна выполнять транзакции
(используя операторы commit
и rollback), выходящие за границы одной вычислительной
системы, и сохранять целостность распределенной
базы данных даже при возникновении отказов
как в отдельных системах, так и в сети
в целом.
- Безопасность.
Система безопасности СУБД должна обеспечивать
защиту всей распределенной базы данных
от несанкционированного доступа.
- Универсальный
доступ. СУБД должна обеспечивать одинаковую
"технологию доступа" ко всем данным
предприятия.
Ни
одна из существующих распределенных
СУБД по своим возможностям не соответствует
этому идеалу. Имеются препятствия,
из-за которых с трудом реализуются даже
простые формы управления распределенными
базами данных. К ним относятся:
- Низкая
производительность.
В централизованной базе данных время
доступа к данным составляет несколько
миллисекунд, а скорость их передачи —
несколько миллионов символов в секунду.
Даже в высокоскоростной локальной сети
время доступа увеличивается до десятых
долей секунды, а скорость передачи данных
падает до 100000 символов в секунду или даже
еще ниже. Время доступа к данным по телефонной
линии с модемом, имеющим скорость 9600 бод,
может занимать секунды или минуты, а максимальная
пропускная способность может быть всего
500 символов в секунду. Эта огромная разница
в быстродействии может резко замедлять
доступ к удаленным данным.
- Проблема
сохранения целостности
данных. Чтобы при выполнении распределенных
транзакций соблюдался принцип "все
или ничего", необходимо активное взаимодействие
двух или более независимых СУБД, работающих
в различных вычислительных системах.
При этом должны использоваться специальные
протоколы двухфазного выполнения транзакций.
- Проблема,
связанная с планом
выполнения статического
SQL. Встроенный статический оператор
SQL компилируется и сохраняется в базе
данных в виде плана выполнения. Когда
запрос объединяет данные из двух или
более баз данных, в какой из них следует
хранить план выполнения? Может, необходимо
иметь два или более согласованных плана?
А если изменяется структура одной базы
данных, то как можно изменить план выполнения
в другой базе данных?
- Проблема
оптимизации. Когда доступ к данным
осуществляется по сети, обычные правила
оптимизации операторов SQL применять нельзя.
Например, полное сканирование локальной
таблицы может оказаться более оптимальным,
чем поиск по индексу в удаленной таблице.
Программа оптимизации должна знать параметры
сети и, в частности, ее быстродействие.
Если говорить в общем, роль оптимизации
становится более важной, а ее осуществление
более трудным.
- Проблема
совместимости данных.
В различных вычислительных системах
существуют различные типы данных, и даже
когда в двух системах присутствуют данные
одного и того же типа, он может иметь разные
форматы. Например, в компьютерах VAX и Macintosh
16-разрядные целые числа представляются
по-разному. Для представления символов
в больших ЭВМ компании IBM используется
кодировка EBCDIC, а в мини-ЭВМ и персональных
компьютерах — кодировка ASCII. В распределенной
СУБД эти различия должны быть незаметны.
- Проблема
хранения системных
каталогов. Во время работы СУБД часто
обращается к своим системным каталогам.
Где в распределенной базе данных следует
хранить каталог? Если он будет храниться
в одной системе, то удаленный доступ к
каталогу будет медленным, что может парализовать
работу СУБД. Если разместить его в нескольких
различных системах, то изменения в каталоге
придется распространять по сети и синхронизировать.
- Оборудование
от разных поставщиков.
Вряд ли управление всеми данными на предприятии
будет осуществляться с помощью СУБД одного
типа; как правило, в распределенной базе
данных используется несколько СУБД, что
требует активной совместной работы СУБД,
поставляемых конкурирующими компаниями.
Но такое маловероятно.
- Распределенные
тупиковые ситуации.
Когда в двух системах одновременно выполняются
транзакции, которые пытаются осуществить
доступ к заблокированным данным в другой
системе, в распределенной базе данных
может возникнуть тупик, хотя в каждой
из двух систем тупика не будет. СУБД должна
обеспечивать обнаружение глобальных
тупиков в распределенной базе данных.
- Проблема
восстановления. Если в одной из систем,
входящих в распределенную базу данных,
произойдет отказ, то администратор этой
системы должен иметь возможность запускать
процедуру восстановления независимо
от других вычислительных систем в сети,
и восстановленная система должна быть
синхронизирована с другими системами.
Из-за
указанных препятствий все ведущие
поставщики СУБД вводят управление распределенными
данными последовательно, шаг за
шагом. Первоначально СУБД может позволять
пользователю одной системы делать запросы
к базе данных, размещенной в другой системе.
В последующих версиях СУБД возможности
управления распределенными данными могут
расширяться, приближаясь к поставленной
цели: обеспечению универсального и прозрачного
доступа к данным.
Уровни
доступа к распределенным
данным
В
1989 году компания IBM объявила о своих планах
постепенного обеспечения доступа к распределенным
данным в своих СУБД. Эта компания не была
первой, предложившей своим пользователям
возможность доступа к распределенным
данным, и в настоящее время не является
поставщиком наиболее современных СУБД,
обеспечивающих доступ к распределенным
данным. Однако четыре уровня доступа,
предложенные компанией IBM и приведенные
в табл. 20.1, являются прекрасной основой
для понимания принципов управления распределенными
данными, используемых компанией IBM и другими
поставщиками в своих СУБД. Естественно,
что возможности всех СУБД компании IBM
четко соответствуют уровням, описанным
в этой таблице.
Модель
компании IBM, состоящая из четырех уровней
доступа, основана на простой формулировке
задачи доступа к распределенным данным:
пользователю, находящемуся в одной вычислительной
системе, требуется получить доступ к
данным, хранящимся в других вычислительных
системах (одной или нескольких). Сложность
распределенного доступа увеличивается
на каждом последующем уровне. Таким образом,
возможности СУБД можно охарактеризовать
тем, какого уровня она достигла. Кроме
того, на каждом уровне можно различать
доступ только для чтения данных (посредством
оператора select) и доступ для изменения
данных (посредством операторов insert,
delete и update). Часто в СУБД для некоторого
уровня сначала вводится возможность
только чтения данных и лишь впоследствии
вводится полноценная возможность как
чтения, так и изменения данных.
Удаленные
запросы
Первым
уровнем доступа к распределенным
данным, по определению IBM, является удаленный
запрос, схема выполнения которого изображена
на рис. 20.2. На этом уровне пользователь
персонального компьютера может выполнить
оператор SQL, который считывает или изменяет
данные в одной удаленной базе данных.
Каждый индивидуальный оператор SQL является
транзакцией, что аналогично режиму "автозавершения",
существующему во многих интерактивных
SQL-программах. Пользователь может выполнять
последовательно несколько операторов
SQL, обращающихся к разным базам данных,
но СУБД не поддерживает транзакции, состоящие
из нескольких операторов.
Удаленные
запросы полезны в тех случаях,
когда пользователю персонального
компьютера необходимо получить информацию
из корпоративной базы данных. Как правило,
все запрашиваемые данные находятся в
одной базе данных, такой как база данных
для обработки заказов или база производственных
данных. Выполняя удаленный запрос, программа,
работающая на персональном компьютере,
может извлекать удаленные данные для
последующей их обработки "у себя"
—- в электронных таблицах, графических
программах или настольных издательских
системах.
Однако
возможностей удаленного запроса недостаточно
для большинства приложений, работающих
в режиме транзакций. Например, рассмотрим
приложение, обеспечивающее ввод заказов,
которое находится на персональном компьютере
и работает с корпоративной базой данных.
Чтобы обработать новый заказ, приложение
должно проверить имеющееся в наличии
количество товара, добавить заказ в базу
данных, уменьшить имеющееся количество
и откорректировать сумму заказов для
клиента и объем продаж. Для этого потребуется
с полдюжины различных операторов SQL. Если
не выполнить эти операторы в виде одной
транзакции, то целостность базы данных
может быть нарушена. Однако на уровне
удаленных запросов транзакции, состоящие
из нескольких операторов, выполняться
не могут, и, следовательно, данное приложение
работать не будет.
Удаленные
транзакции
Вторым
уровнем доступа к распределенным
данным, по определению компании IBM,
является удаленная
транзакция ("удаленная единица работы",
выражаясь языком IBM), схематически представленная
на рис. 20.3. На этом уровне поддерживаются
транзакции, состоящие из нескольких операторов
SQL. Пользователь персонального компьютера
может передать в СУБД последовательность
операторов SQL, осуществляющих выборку
или обновление информации в удаленной
базе данных, а затем выполнить или отменить
всю последовательность как одну транзакцию.
СУБД гарантирует, что вся транзакция
будет выполнена как единое целое — либо
успешно, либо нет, так же как это происходит
в локальной базе данных. Все операторы
SQL, составляющие транзакцию, должны быть
адресованы к одной удаленной базе данных.
Удаленные
транзакции "открывают дорогу"
для приложений, работающих с распределенными
данными в режиме транзакций. Например,
на данном уровне доступа программа ввода
заказов для обработки нового заказа может
выполнить последовательность запросов
на выборку и обновление информации из
базы данных товарных запасов, а также
на добавление информации. Программа завершает
эту последовательность операторов, образующих
транзакцию, оператором commit
или rollback.