Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Принципиальная характеристика тиражирования данных (Data Replication — DR) заключается в отказе от физического распределения, привязки данных. Суть репликации состоит в том, что любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально.

Тиражирование данных — это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащие различным узлам распределенной системы. Функции тиражирования выполняет, как правило, специальный модуль СУБД — сервер тиражирования данных, называемый репликатором (СУБД CA-Openlngres и Sybase). В других СУБД (Informix-OnLine Dynamic Server) регашкатор встроен в сервер или поставляется опционально (Oracle). Специфика механизмов репликации данных зависит от используемой СУБД. Один из простейших вариантов репликации — использование так называемых «моментальных снимков» (Snapshot) — сохранение на разных узлах копий той или иной таблицы в определенный момент времени; данные копии периодически (раз в неделю, например) подлежат обновлению.

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

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

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

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

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

При использовании механизмов репликации данных также остро стоит вопрос совместимости разнородных локальных баз данных, составляющих исходную БД. Зачастую штатные средства тиражирования в составе данной конкретной БД позволяют переносить данные в однородную базу. Ответом стало появление продуктов, выполняющих тиражирование между разнородными базами данных. Здесь развитие технологий пошло по двум путям. Первый — создание средств унифицированного доступа к данным (стандарт ODBC — Open DataBase Connectivity). Очевидный недостаток ODBC — недоступность для приложения многих полезных механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения SQL в диалекте языка данной СУБД, но в стандарте ODBC эти расширения могут не поддерживаться. Другой подход – это создание шлюзов, позволяющих приложениям оперировать над базами данных в ином формате так, как будто это собственные базы данных. Задача шлюза — организация доступа к унаследованным БД и служит для решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Шлюзы можно рассматривать как средство, облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной системе. Вообще, универсального рецепта решения задачи межоперабельности в этом контексте не существует — все определяется конкретной ситуацией, историей информационной системы и массой других факторов.

1. Обработка распределенных запросов

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

Обработка распределенных запросов — задача, более сложная, нежели обработка локальных запросов, и она требует интеллектуального решения с помощью особого компонента — оптимизатора распределенных запросов. Предположим, у нас имеется распределенная база данных, размещенная на двух узлах. Пусть, таблица detail хранится на одном узле, а таблица main — на другом. Размер первой таблицы — 2000 строк, размер второй — 200 строк (множество товаров поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:

SELECT detail_name, main_name, main _address

FROM detail, main WHERE detail, main _number = main, main _number ;

Тогда результирующая таблица представляет собой объединение таблиц

detail и main, выполненное по столбцу detail.main_number (внешний ключ) И main.main _number (первичный ключ).

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

Обработка распределенных транзакций

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

1. Независимость от оборудования

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

1. Независимость от операционных систем

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

1. Прозрачность сети

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

1. Независимость от баз данных

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

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

2. 1 Целостность данных

В DDB поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой сложную проблему. Ее решение – синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих DDB – достигается применением протокола двухфазной фиксации транзакций. Если DDB однородна – то есть на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для обеспечения согласованных изменений в нескольких базах данных используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции – СУБД, функционирующие на узлах системы, поддерживают XA-интерфейс, определенный в спецификации DTP консорциума X/Open. В настоящее время XA-интерфейс имеют CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.
Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально – на данном узле – так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать.

1. 2 Обработка распределенных запросов

Выше уже упоминалось это качество DDB. Обработка распределенных запросов (Distributed Query –DQ) – задача, более сложная, нежели обработка локальных и она требует интеллектуального решения с помощью особого компонента – оптимизатора DQ. Обратимся к базе данных, распределенной по двум узлам сети. Таблица detail хранится на одном узле, таблица supplier – на другом. Размер первой таблицы – 10000 строк, размер второй – 100 строк (множество деталей поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:

SELECT detail_name, supplier_name, supplier_address FROM detail, supplier WHERE detail.supplier_number = supplier.supplier_number;

Результирующая таблица представляет собой объединение таблиц detail и supplier, выполненное по столбцу detail.supplier_number (внешний ключ) и supplier.supplier_number (первичный ключ).

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

1. 3 Межоперабельность

В контексте DDB _ежоперабельность означает две вещи. Во-первых, - это качество, позволяющее обмениваться данными между базами данных различных поставщиков. Как, например, тиражировать данные из базы данных Informix в Oracle и наоборот? Известно, что штатные средства тиражирования в составе данной конкретной СУБД позволяют переносить данные в однородную базу. Так, средствами CA-Ingres/Replicator можно тиражировать данные только из Ingres в Ingres. Как быть в неоднородной DDB? Ответом стало появление продуктов, выполняющих тиражирование между разнородными базами данных.

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

Характеристики

Список файлов реферата