Архитектура распределенных СУБД

Трехуровневая архитектура ANSI-SPARC для СУБД представляет собой типовое решение для централизованных СУБД. Однако распреде­ленные СУБД имеют множество отличий, которые сложно отразить в некотором эквивалентном архитектурном решении, приемлемом для большинства случаев.

Один из примеров рекомендуемой архитектуры СУРБД представлен на рис.10.3. Он включает следующие элементы:

§ набор глобальных внешних схем;

§ глобальную концептуальную схему;

§ схему фрагментации и схему распределения;

§ набор схем для каждой локальной СУБД, отвечающих требованиям трех­уровневой архитектуры ANSI-SPARC.

Рис.10.3. Рекомендуемая архитектура СУРБД

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

Глобальная концептуальная схема

Глобальная концептуальная схема представляет собой логическое описание всей базы данных, представляющее ее так, как будто она не является распределенной. Этот уровень СУРБД соответствует концептуальному уровню архитектуры ANSI-SPARC и содержит определения сущностей, связей, требований защиты и ограниче­ний поддержки целостности информации. Он обеспечивает физическую независи­мость данных от распределенной среды. Логическую независимость данных обеспе­чивают глобальные внешние схемы.

Схемы фрагментации и распределения

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

Локальные схемы

Каждая локальная СУБД имеет свой собственный набор схем. Локальная концеп­туальная и локальная внутренняя схемы полностью соответствуют эквивалентным уровням архитектуры ANSI-SPARC. Локальная схема отображения используется для отображения фрагментов в схеме распределения во внутренние объекты локальной базы данных. Эти элементы являются зависимыми от типа используемой СУБД и служат основой для построения гетерогенных СУРБД.

Независимо от рекомендованной общей архитектуры СУРБД компонентная архитектура СУРБД должна включать четыре следующих важнейших компонента (рис.10.4):

1) локальную СУБД;

2) компонент передачи данных;

3) глобальный системный каталог;

4) распределенную СУБД (СУРБД).

Локальная СУБД

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

Рис.10.4. Компонентная архитектура распределенной СУБД

Компонент передачи данных

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

Глобальный системный каталог

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

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

Распределенная СУБД

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

3. Разработка распределенных реляционных баз данных

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

§ Фрагментация. Любое отношение может быть разделено на некоторое ко­личество частей, называемых фрагментами, которые затем распределяются по различным сайгам. Существуют два основных типа фрагментов:гори­зонтальные и вертикальные. Горизонтальные фрагменты представляют со­бой подмножества кортежей, а вертикальные — подмножества атрибутов.

§ Распределение. Каждый фрагмент сохраняется на сайте, выбранном с уче­том «оптимальной» схемы их размещения.

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

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

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

- частота запуска приложения на выполнение;

- сайт, на котором запускается приложение;

- требования к производительности транзакций и приложений.

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

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

• Локальность ссылок. Везде, где только это возможно, данные должны храниться как можно ближе к местам их использования. Если фрагмент используется на нескольких сайтах, может оказаться целесообразным раз­местить на этих сайтах его копии.

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

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

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

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

Распределение данных

Существуют четыре альтернативные стратегии размещения данных в системе:

1) централизованное;

2) раздельное (фрагментированное);

3) размещение с полной репликацией;

4) размещение с выборочной репликацией.

Централизованное размещение

Данная стратегия предусматривает создание на одном из сайтов единственной ба­зы данных под управлением СУБД, доступ к которой будут иметь все пользователи сети («распределенная обработка»). В этом случае локальность ссылок минимальна для всех сайтов, за ис­ключением центрального, поскольку для получения любого доступа к данным требу­ется установка сетевого соединения. Соответственно уровень затрат на передачу дан­ных будет высок. Уровень надежности и доступности в системе низок, поскольку от­каз на центральном сайте вызовет паралич работы всей системы.

Раздельное (фрагментированное) размещение

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

Размещение с полной репликацией

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

Размещение с выборочной репликацией

Данная стратегия представляет собой комбинацию методов фрагментации, репли­кации и централизации. Одни массивы данных разделяются на фрагменты, что по­зволяет добиться для них высокой локальности ссылок, тогда как другие, исполь­зуемые на многих сайтах, но не подверженные частым обновлениям, подвергаются репликации. Все остальные данные хранятся централизованно. Целью применения данной стратегии является объединение всех преимуществ, существующих в осталь­ных, моделях, с одновременным исключением свойственных им недостатков. Благо­даря своей гибкости именно эта стратегия используется чаще всего.

Сводные харак­теристики всех рассмотренных выше стратегий приведены в табл.10.1.

Таблица 10.1

	Локальность ссылок	Надежность и доступность	Производительность	Стоимость устройств хранения данных	Затраты на передачу
Централизованное	Самая низкая	Самая низкая	Неудовлетворительная	Самая низкая	Самая высокая
Фрагментированное	Высокая	Низкая для отдельных элементов; высокая для системы в целом	Удовлетвори тельная	Самая низкая	Низкая
Полная репликация	Самая высокая	Самая высокая	Хорошая для операций чтения	Самая высокая	Высокая для операций обновления, низ­кая для опера­ций чтения
Выборочная репликация	Высокая	Низкая для отдельных элементов, высокая для системы	Удовлетворительная	Средняя	Низкая

Фрагментация

Необходимость фрагментации вызывают следующие причины.

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

§ Эффективность. Данные хранятся в тех местах, в которых они чаще всего используются. Кроме того, исключается хранение данных, которые не ис­пользуются локальными приложениями.

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

§ Защищенность. Данные, не используемые локальными приложениями, не хранятся на сайтах, а значит, неавторизированные пользователи не смогут получить к ним доступ.

Механизму фрагментации свойственны два основных недостатка.

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

§ Целостность данных. Поддержка целостности данных может существенно осложняться, поскольку функционально зависимые данные могут оказать­ся фрагментированными и размещаться на различных сайтах.

При проведении фрагментации следует обязательно придерживаться трех следующих правил.

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

2. Восстановимость. Должна существовать операция реляционной алгебры, по­зволяющая восстановить отношение R из его фрагментов. Это правило гаран­тирует сохранение функциональных зависимостей.

3. Непересекаемость. Если элемент данных d_i присутствует во фрагменте R_i, то он не должен одновременно присутствовать в каком-либо ином фрагменте. Исключени­ем из этого правила является операция вертикальной фрагментации, поскольку в этом случае в каждом фрагменте должны присутствовать атрибуты первичного ключа, необходимые для восстановления исходного отношения. Данное правило гарантирует минимальную избыточность данных во фрагментах.

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

Существуют два основных типа фрагментации (рис.10.5, а, б):

- горизонтальная,

- вертикальная.

Горизонтальные фрагменты представляют собой подмножества кортежей отношения, а вертикальные — подмножества атрибутов отношения.

Кроме того, различают смешанную (рис.10.5, в, г) и производную (вариант горизонтальной) фрагментации.

Горизонтальный фрагмент – выделенный по горизонтали фрагмент отношения, состоящий из некоторого подмножества кортежей этого отношения.

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

Рис.10.5. Типы фрагментации:

а) горизонталь­ная; б) верти­кальная; в) горизонталь­но разделенные вертикальные фрагменты; г) верти­кально разделенные горизонтальные фрагменты

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

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

Набор предикатов явля­етсяполным тогда и только тогда, когда вероятность обращения к любым двум корте­жам одного и того же фрагмента со стороны любого приложения будет одинакова.

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

Вертикальный фрагмент – выделенный по вертикали фрагмент отношения, состоящий из подмножества атрибутов этого отношения.

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

Вертикальные фрагменты определяются путем установкиродственности одного атрибута по отношению к другому. Один из способов решить эту задачу состоит в создании матрицы, содержащей количество обращений с выборкой каждой из пар атрибутов. Например, транзакция, которая осуществляет доступ к атрибутам А₁, А₂ и А₄ отношения R, состоящего из набора атрибутов (А₁, А₂, А₃, А₄), может быть пред­ставлена следующей матрицей.

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

Подобный подход носит название расщепления (splitting) и впервые был предло­жен группой разработчиков в 1984 году. Он позволяет выде­лить набор неперекрывающихся фрагментов, которые гарантированно будут отвечать определенному выше правилу непересекаемости. Фактически требование непересе­каемости касается только атрибутов, не входящих в первичный ключ отношения. Атрибуты первичного ключа должны присутствовать в каждом из выделенных вер­тикальных фрагментов, а потому могут быть исключены из анализа.

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

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

Смешанная фрагментация определяется с помощью операций выборки и проек­ции реляционной алгебры.

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

Производный фрагмент – горизонтальный фрагмент отношения, созданный на основе горизонтального фрагмента родительского отношения.

Термин «дочернее» используется для ссылок на отношение, содержащее внешний ключ, а термин «родительское» — для ссылок на отношение с соответст­вующим первичным ключом. Определение производных фрагментов осуществляется с помощью операции полусоединения реляционной алгебры (см. гл.4).

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

Последний вариант возможной стратегии при разработке распределенных БД состоит в отказе от фрагментации отно­шения.

Репликация

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

Механизм репликации очень важен, поскольку позволяет организации обеспечивать доступ пользователям к актуальным данным там и тогда, когда они в этом нуждают­ся. Использование репликации позволяет достичь многих преимуществ, включая по­вышение производительности (в тех случаях, когда централизованный ресурс оказы­вается перегруженным), надежности хранения и доступности данных, наличие «горячей» резервной копии на случай восстановления, а также возможность под­держки мобильных пользователей и хранилищ данных.

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

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

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

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

§ Масштабируемость. Служба репликации должна эффективно обрабаты­вать как малые, так и большие объемы данных.

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

§ Репликация объектов. Должна существовать возможность реплицировать объекты, отличные от обычных данных. Например, в некоторых системах допускается репликация индексов и хранимых процедур (или триггеров).

§ Средства определения схемы репликации. Система должна предоставлять механизм, позволяющий привилегированным пользователям задавать дан­ные и объекты, подлежащие репликации.

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

§ Механизм инициализации. Система должна включать средства, обеспечи­вающие инициализацию вновь создаваемой реплики.

Владение данными определяет, какому из сайтов будет предоставлена привилегия обновления данных. Основными типами схем владения являются:

- «ведущий/ведомый»;

- «рабочий поток»;

- «повсеместное обновление».

Последний ва­риант иногда называют одноранговой, или симметричной репликацией.

При организации владения данными по схеме «ведущий/ведомый» асинхронно реплицируемые данные принадлежат одному из сайтов, называемому ведущим, или первичным, и могут обновляться только на нем. Здесь можно провести аналогию ме­жду издателем и подписчиками. Издатель (ведущий сайт) публикует свои данные. Все остальные сайты только лишь подписываются на данные, принадлежащие веду­щему сайту, т.е. имеют собственные локальные копии, доступные им только для чтения. Потенциально каждый из сайтов может играть роль ведущего для различ­ных, не перекрывающихся наборов данных. Однако в системе может существовать только один сайт, на котором располагается ведущая обновляемая копия каждого конкретного набора данных, а это означает, что конфликты обновления данных в системе полностью исключены. Ниже приводится несколько примеров возможных вариантов использования этой схемы репликации.

§ Системы, поддержки принятия решений (ППР). Данные из одной или более распределенных баз данных могут выгружаться в отдельную, локальную систему ППР, где они будут только считываться при выполнении различных видов анализа.

§ Централизованное распределение или распространение информации. Распро­странение данных имеет место в тех случаях, когда данные обновляются толь­ко в центральном звене системы, после чего реплицируются их копии, доступ­ные только для чтения. Этот вариант репликации данных показан на рис.10.6,а.

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

Рис.10.6. Владение данными по схеме «ведущий/ведомый»:

а) распределение дан­ных; б) консолидация данных

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

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

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

Централизованные системы позволяют приложениям, выполняющим отдельные этапы обработки, получать доступ и обновлять данные в одной интегрированной базе данных. Каждое приложение обновляет данные о заказе по очереди тогда и только тогда, когда состояние заказа указывает, что предыдущий этап обработки уже за­вершен. В модели владения «рабочий поток» приложения могут быть распределены по различным сайтам, и когда данные реплицируются и пересылаются на следую­щий сайт в цепочке, вместе с ними передается и право на их обновление, как пока­зано на рис.10.7.

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

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

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

Рис.10.7. Схема владения «рабочий поток»

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

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

В противоположность этому, на рис.10.8,б показан пример репликации с со­хранением структуры транзакции в исходной базе данных.

Рис.10.8. Репликация транзакций:

а) без соблюдения свойства атомарности; б) с соблюдением атомарности транзакций