Если в распределенной БД предусмотрено тиражирование (репликация) данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены тиражируемые потоки. Проблема состоит в том, что изменения в данных могут инициироваться как локально — на данном узле, так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать.
Это качество можно трактовать как возможность непрерывного доступа (формат 24x7 — доступ 24 часа в сутки 7 дней в неделю) в рамках распределенной БД к данным вне зависимости от их расположения и операций, выполняемых на локальных узлах. Одним словом, данные доступны всегда, а операции над ними могут выполняться непрерывно.
Это свойство означает полную прозрачность расположения данных. Пользователь, обращающийся к распределенной БД, ничего не должен знать о реальном (физическом) размещении данных в узлах информационной системы. Все операции над данными выполняются без учета их местонахождения. Передача и обработка запросов к базам данных осуществляется встроенными системными средствами.
Прозрачность расположения в реальных продуктах должна поддерживаться соответствующими механизмами, реализованными в рамках конкретной СУБД или проекта в целом. При этом разработчики СУБД придерживаются различных подходов. Типичным решением данной задачи является использование так называемых синонимов (Alias) баз данных.
Это свойство трактуется как возможность распределенного (т. Е. на различных узлах, а не в одном месте) размещения данных, логически представляющих собой единое целое. Существует фрагментация двух типов: горизонтальная и вертикальная. Первая означает хранение строк одной таблицы на различных узлах (фактически, хранение строк одной логической таблицы в нескольких идентичных физических таблицах на различных узлах). Вторая означает распределение столбцов логической таблицы по нескольким узлам (типичный пример реализации — SQL-запрос из нескольких физически обособленных таблиц).
Тиражирование данных — это асинхронный (в общем случае) процесс переноса изменений объектов исходной базы данных в базы, расположенные на других узлах распределенной системы. В данном контексте независимость тиражирования означает возможность переноса изменений между базами данных средствами, невидимыми пользователю распределенной системы. Данное свойство означает, что тиражирование возможно и достигается внутрисистемными средствами.
Принципиальная характеристика тиражирования данных (Data Replication — DR) заключается в отказе от физического распределения, привязки данных. Суть репликации состоит в том, что любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально.
Тиражирование данных — это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащие различным узлам распределенной системы. Функции тиражирования выполняет, как правило, специальный модуль СУБД — сервер тиражирования данных, называемый репликатором (СУБД CA-Openlngres и Sybase). В других СУБД (Informix-OnLine Dynamic Server) регашкатор встроен в сервер или поставляется опционально (Oracle). Специфика механизмов репликации данных зависит от используемой СУБД. Один из простейших вариантов репликации — использование так называемых «моментальных снимков» (Snapshot) — сохранение на разных узлах копий той или иной таблицы в определенный момент времени; данные копии периодически (раз в неделю, например) подлежат обновлению.
Детали тиражирования данных полностью скрыты от прикладной программы; ее функционирование никак не зависит от работы репликатора, который целиком находится в ведении администратора базы данных. Следовательно, для переноса программы в распределенную среду с тиражируемыми данными не требуется ее модификация.
Синхронное обновление распределенных БД и технология репликации данных — в определенном смысле, антиподы. Краеугольный камень первой — синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, т. Е. синхронная фиксация изменений в распределенной БД. Ее «ахиллесова пята» — жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна.
Технология репликации данных не требует синхронной фиксации изменений, что является, несомненно, ее сильной стороной. В действительности далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные критические моменты времени (генерация суточного, недельного, месячного, годового отчета). Можно накапливать изменения в данных в виде транзакций в одном узле и периодически копировать эти изменения на другие узлы.
Налицо преимущества распределенной технологии. Во-первых, данные всегда расположены там, где они обрабатываются — следовательно, скорость доступа к ним существенно увеличивается. Во-вторых, передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным), да еще к тому же в асинхронном режиме позволяет значительно уменьшить трафик. В-третьих, со стороны исходной базы для принимающих баз репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом. Наконец, в-четвертых, никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); поэтому после восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано.
В то же время технология репликации данных не лишена недостатков. Например, невозможно полностью исключить конфликты между двумя версиями одной и той же записи. Такой конфликт может возникнуть, когда, вследствие все той же асинхронности, два пользователя на разных узлах исправят одну и ту же запись в тот момент, пока изменения в данных из первой базы еще не были перенесены во вторую. При проектировании распределенной среды с использованием репликации данных необходимо предусмотреть возможность возникновения конфликтных ситуаций и запрограммировать репликатор на какой-либо вариант их разрешения. В этом смысле применение DR-технологии — наиболее сильная угроза целостности распределенных баз данных.
При использовании механизмов репликации данных также остро стоит вопрос совместимости разнородных локальных баз данных, составляющих исходную БД. Зачастую штатные средства тиражирования в составе данной конкретной БД позволяют переносить данные в однородную базу. Ответом стало появление продуктов, выполняющих тиражирование между разнородными базами данных. Здесь развитие технологий пошло по двум путям. Первый — создание средств унифицированного доступа к данным (стандарт ODBC — Open DataBase Connectivity). Очевидный недостаток ODBC — недоступность для приложения многих полезных механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения SQL в диалекте языка данной СУБД, но в стандарте ODBC эти расширения могут не поддерживаться. Другой подход – это создание шлюзов, позволяющих приложениям оперировать над базами данных в ином формате так, как будто это собственные базы данных. Задача шлюза — организация доступа к унаследованным БД и служит для решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Шлюзы можно рассматривать как средство, облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной системе. Вообще, универсального рецепта решения задачи межоперабельности в этом контексте не существует — все определяется конкретной ситуацией, историей информационной системы и массой других факторов.
Это свойство распределенной БД трактуется как возможность выполнения операций выборки, сформулированных в рамках обычного запроса на языке SQL. To есть операцию выборки из распределенной базы данных можно сформулировать с помощью тех же языковых средств, что и операцию над локальной базой данных.