Технологии тиражирования данных

Министерство образования  и науки Российской Федерации

Федеральное государственное  бюджетное образовательное

учреждение высшего профессионального  образования

Уфимский государственный  авиационный технический университет

 

Кафедра экономической информатики

 

 

 

Реферат

на тему «Технологии тиражирования данных»

 

 

 

                                              Выполнила: Цветкова Е.О.

Студентка гр. БИ-302

                                                            

 

 

 

 

 

 

 

 

Уфа 2013

Оглавление

Аннотация 3

Введение 3

Принцип тиражирования данных 4

Инструментарий тиражирования 7

Использование репликатора 11

Заключение 13

Список использованной литературы 14

 

Аннотация

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

Введение

Идея организации единой информационной среды крупного современного предприятия на принципах распределенной обработки данных становится все более популярной. Переход к реализации таких принципов от дорогостоящих и недостаточно гибких централизованных много пользовательских mainframe-систем, либо от мало мощных и слабо интегрированных систем на базе персональных компьютеров (что характерно для стран Восточной Европы и России в частности), происходит сейчас во всем компьютерном мире и встречается со сходными концептуальными трудностями.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

Принцип тиражирования данных

 

Принцип тиражирования - сопоставление с физическим распределением данных.

Использование современными организациями технологии "клиент-сервер" делает актуальной проблему доступа  к удаленным базам данных и  комбинирование информации из двух или  более физически разделенных узлов информационной системы. Ответом на требования реальной жизни стали такие возможности обработки распределенных данных, как двухфазовая фиксация транзакций.

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

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

Для этого в современных  СУБД предусмотрен так называемый протокол двухфазовой фиксации транзакций (two-phase commit protocol - 2PC). Название отражает то, что фиксация распределенной транзакции выполняется в две фазы.

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

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

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

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

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

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

Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных (source database) в базы данных, принадлежащие к различным узлам распределенной системы. Функции тиражирования данных возложены на специальный компонент СУБД - сервер тиражирования данных, называемый репликатором (replicator), задача которого состоит в обеспечении идентичности данных в принимающих базах данных (target database) данным в исходной БД.

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

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

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

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

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

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

Один из них состоит  в том, что для каждого узла (базы данных) должны быть определены некие  уникальные функции, исключающие коллизии. Другой предполагает правильный реляционный  дизайн, в частности, отказ от тиражирования  вычисляемых данных в пользу первичных. Например, в банковских приложениях  верным решением была бы репликация проводок, а не остатков на счетах. Можно попытаться перенести центр тяжести с  операций обновления данных (update) на операции удаления (delete) или вставки (insert) записей в тиражируемом наборе. Интересны также сочетания репликатора и прямого применения двухфазовой фиксации распределенных транзакций в топологии STAR, реализующие необходимые блокировки.

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

Инструментарий  тиражирования

На практике установка  тиражируемой системы сводится к  чисто административным действиям, для выполнения которых необходимо получить ответы на четыре вопроса: Что  тиражировать? Где тиражировать? Когда  тиражировать? Как разрешать предполагаемые конфликты? Напомним, прикладной программе  не обязательно знать детали организации  данных в системе - ведь они со временем могут измениться! Рассмотрим ответы, которые дает репликатор на эти вопросы.

Что тиражировать?

Как и любая другая методология, тиражирование имеет собственную  терминологию. Краеугольным камнем тиражирования  является понятие согласованного распределенного набора данных (consistent distributed data set - CDDS). Фактически, это тот самый набор данных в базе (или база данных целиком), идентичность которого на всех узлах, вовлеченных в процесс тиражирования, и поддерживает репликатор. Здесь и далее мы будем говорить об узлах распределенной системы, хотя участвовать в тиражировании могут и базы данных, расположенные на одном узле.

CDDS может быть представлен следующими конфигурациями данных:

1. Вся база данных:
2. Избранные объекты базы данных: таблицы или представления;
3. Вертикальные проекции объектов БД: избранные столбцы таблиц и/или представлений;
4. Горизонтальные подмножества объектов: избранные записи из таблиц и/или представлений;
5. Сочетание наборов 2-4.

Строгое определение CDDS заключается  в выполнении следующих условий:

1. Набор данных, претендующий на определение в качестве CDDS, должен располагаться в нескольких базах данных в идентичных копиях;
2. Данные из различных CDDS должны быть взаимно ортогональны, т. е. одни и те же данные не могут входить в различные CDDS;
3. CDDS должен обладать свойством полноты, т. е. включать все идентичные копии данных, существующие в распределенной системе.

Идентичность здесь понимается как одинаковость определения и  состава данных. При установке  тиражируемой системы идентичность состава данных может обеспечиваться средствами репликатора.

В результате, согласованность CDDS автоматически поддерживается репликатором и проявляется в том, что:

1. Любое изменение любой копии CDDS автоматически распространяется на все остальные копии;
2. Внутри CDDS ни одна копия данных не имеет преимущества перед другой копией - они абсолютно равноправны;
3. Все объекты, составляющие каждую копию CDDS, имеют одинаковые имена.

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

 

Где тиражировать?

Следующий основополагающий элемент схемы тиражирования - это путь переноса изменений (data propagation path - DPP) из каждой тиражируемой базы данных в другие БД. Гибкость тиражирования в значительной степени обеспечивается богатством выбора способа передачи данных между узлами распределенной системы.

Практика эксплуатации распределенных систем подсказала следующие схемы  тиражирования данных, реализуемые  репликатором: