Реплицированные таблицы

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

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

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

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

Рассмотрим проблему обновления данных. Если обновления происходят сразу на двух серверах, их нужно согласовывать. Чтобы не возникали неразрешимые ситуации, необходимо позволить вносить изменения только на одном сервере. Тогда синхронизация будет заключаться в дублировании содержимого сервера, доступного для записи, на все остальные серверы. Их полезность зависит от того, насколько важна актуальность данных. Во многих случаях база данных, содержащая все записи, кроме тех, которые были созданы за последние 24 часа, вполне приемлема. Отложенная синхронизацияудобна там, где пользователям не нужны отчеты в реальном времени.

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

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

Независимость от сети. Если система в состоянии поддерживать несколько узлов с разным аппаратным обеспечением и разными операционными системами, то желательно, чтобы в ней поддерживались разные типы сетей.

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

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

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

Ни одна из существующих распределенных СУБД по своим возможностям не соответствует этому идеалу. Имеются препятствия, из-за которых с трудом реализуются даже простые формы управления распределенными базами данных. К ним относятся:

Низкая производительность. В централизованной базе данных время доступа к данным составляет несколько миллисекунд, а скорость их передачи — несколько миллионов символов в секунду. Даже в высокоскоростной локальной сети время доступа увеличивается до десятых долей секунды, а скорость передачи данных падает до 100000 символов в секунду или даже еще ниже. Время доступа к данным по телефонной линии с модемом, имеющим скорость 9600 бод, может занимать секунды или минуты, а максимальная пропускная способность может быть всего 500 символов в секунду. Эта огромная разница в быстродействии может резко замедлять доступ к удаленным данным.

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

Проблема, связанная с планом выполнения статического SQL. Встроенный статический оператор SQL компилируется и сохраняется в базе данных в виде плана выполнения. Когда запрос объединяет данные из двух или более баз данных, в какой из них следует хранить план выполнения? Может, необходимо иметь два или более согласованных плана? А если изменяется структура одной базы данных, то как можно изменить план выполнения в другой базе данных?

Проблема совместимости данных. В различных вычислительных системах существуют различные типы данных, и даже когда в двух системах присутствуют данные одного и того же типа, он может иметь разные форматы. Например, в компьютерах VAX и Macintosh 16-разрядные целые числа представляются по-разному. Для представления символов в больших ЭВМ компании IBM используется кодировка EBCDIC, а в мини-ЭВМ и персональных компьютерах — кодировка ASCII. В распределенной СУБД эти различия должны быть незаметны.

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

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

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

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

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

Резюме

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

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

Компания IBM определила четыре уровня доступа к распределенным данным: удаленные запросы, удаленные транзакции, распределенные транзакции и распределенные запросы; каждый последующий уровень обеспечивает более широкие возможности, чем предыдущий.

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

Реализация распределенных баз данных связана с серьезными трудностями для поставщиков СУБД, особенно в таких областях, как оптимизация операторов SQL, блокировка данных и управление транзакциями. Чтобы преодолеть их, СУБД должна использовать для доступа к распределенным данным специальные методы, такие как двухфазное выполнение.