КАТЕГОРИИ: Архитектура-(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; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |