Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Технологии реплицирования данных

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

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

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

При этом, однако, возникают две проблемы обеспечения одного из основополагающих принципов построения и функ­ционирования распределенных систем, а именно — непрерыв­ности согласованного состояния данных:

· обеспечение согласованного состояния во всех репли­ках количества и значений общих данных;

· обеспечение согласованного состояния во всех репли­ках структуры данных.

Обеспечение согласованного состояния общих данных, в свою очередь, основывается на реализации одного из двух принципов:

• принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено);

· принципа отложенных обновлений (обновления реплик могут быть отложены до специальной команды или ситуации).

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

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

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

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

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

Решение второй проблемы согласованности данных, а именно — согласованности структуры данных, осуществля­ется через частичное отступление, как и в системах «Клиент-сервер», от принципа отсутствия центральной установки и основывается на технике «главной» реплики.

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

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

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

 

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

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

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

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

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

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

 

Вопросы для самоконтроля:

1. Что «распределено» в распределенных информационных системах и каковы основные принципы создания и функционирования распределенных информационных систем?

2. Поясните суть техники «представления» в базах данных и задачи, которые решаются на основе техники «представлений».

3. Какой из основных принципов распределенных информационных систем принесен в «жертву» в системах «Клиент-сервер»? Пояс­ните преимущества и недостатки такого подхода.

4. На какие компоненты подразделяется программное обеспечение систем «Клиент-сервер»? Какие функции выполняются каждым компонентом?

5. Поясните принципы и схемы RDA, DBS и AS-моделей систем «Клиент-сервер» и дайте их сравнительную характеристику. Ка­кие системы называются системами с «тонкими» («толстыми») клиентами, с 2- или 3-уровневой (2- или 3-звенной) архитектурой?

6. Охарактеризуйте роль и место монитора транзакций в СУБД сис­тем «Клиент-сервер».

7. Какие издержки совместной обработки общих данных предотв­ращает монитор транзакций в системах «Клиент-сервер»?

8. Дайте определение сериальному плану выполнения транзакций и охарактеризуйте основные подходы к механизмам построения та­ких планов.

9. Поясните суть двухфазного протокола синхронизационных захватов объектов и механизм возможного образования тупиковых ситуаций.

10. Как распознаются и разрушаются тупиковые ситуации в технике двухфазного протокола синхронизационных захватов?

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

12. Каковы достоинства и недостатки техники временных меток при синхронизационных захватах объектов?

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

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

15. Какие функции, кроме традиционных, выполняют локальные («настольные») СУБД при использовании технологий объектного связывания?

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

17. Поясните принцип отложенных обновлений и процессов синхро­низации реплик.

18. Чем главная реплика отличается от остальных?

19. Как наличие главной реплики соотносится с принципами распределенных систем?

20. Что обеспечивается возможностью создания частичных реплик?

 

 

<== предыдущая лекция | следующая лекция ==>
Технологии объектного связывания данных | Основные термины и понятия
Поделиться с друзьями:


Дата добавления: 2014-01-03; Просмотров: 1233; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.156 сек.