Электронная библиотека диссертаций и авторефератов России
dslib.net
Библиотека диссертаций
Навигация
Каталог диссертаций России
Англоязычные диссертации
Диссертации бесплатно
Предстоящие защиты
Рецензии на автореферат
Отчисления авторам
Мой кабинет
Заказы: забрать, оплатить
Мой личный счет
Мой профиль
Мой авторский профиль
Подписки на рассылки



расширенный поиск

Алгоритмы репликации данных в распределенных системах обработки информации Белоусов Всеволод Евгеньевич

Алгоритмы репликации данных в распределенных системах обработки информации
<
Алгоритмы репликации данных в распределенных системах обработки информации Алгоритмы репликации данных в распределенных системах обработки информации Алгоритмы репликации данных в распределенных системах обработки информации Алгоритмы репликации данных в распределенных системах обработки информации Алгоритмы репликации данных в распределенных системах обработки информации Алгоритмы репликации данных в распределенных системах обработки информации Алгоритмы репликации данных в распределенных системах обработки информации Алгоритмы репликации данных в распределенных системах обработки информации Алгоритмы репликации данных в распределенных системах обработки информации Алгоритмы репликации данных в распределенных системах обработки информации
>

Диссертация - 480 руб., доставка 10 минут, круглосуточно, без выходных и праздников

Автореферат - бесплатно, доставка 10 минут, круглосуточно, без выходных и праздников

Белоусов Всеволод Евгеньевич. Алгоритмы репликации данных в распределенных системах обработки информации : Дис. ... канд. техн. наук : 05.13.01 Пенза, 2005 184 с. РГБ ОД, 61:05-5/3095

Содержание к диссертации

Введение

Глава 1. Проблема организации надежного механизма синхронизации данных в распределенных системах обработки информации 12

1.1 Обзор развития современных технологий создания распределенных вычислительных систем 12

1.2 Особенности построения и развертывания многоуровневых систем 24

1.3 Классификация распределенных вычислительных систем 31

1.4 Обоснование необходимости выполнения репликации данных в распределенных системах 38

1.5 Анализ современных программных средств и методов, применяемых для репликации данных в распределенных системах 44

1.6 Задача репликации данных в контексте обеспечения работоспособности полуавтономного модуля распределенной системы 50

Глава 2. Разработка архитектуры усовершенствованного механизма репликации данных 56

2.1 Определение основных направлений усовершенствования механизма репликации в контексте решаемой задачи 56

2.2 Обоснование выбора методики проектирования программной архитектуры 63

2.3 Разработка программной модели усовершенствованного механизма репликации 66

2.4 Особенности проектирования модели данных 81

Глава 3. Оптимизация параллельного доступа к ресурсам системы в условиях массового обслуживания клиентских приложений 95

3.1 Разработка инфраструктуры управления потоками заявок 95

3.2 Построение математической модели, описывающей работу подсистемы управления потоками заявок 110

3.3 Исследование влияния параметров конфигурации на характер работы системы 118

Глава 4. Применение результатов исследования в решении практической задачи 133

4.1 Описание задачи 133

4.2 Исследование эффективности систем хранения данных и распределенных программных технологий 136

4.3 Техническая реализация механизма репликации данных 150

4.4 Анализ результатов внедрения 164

Заключение 167

Список использованных источников 170

Приложение А. Описание модели системы управления потоками заявок на языке GPSS 180

Приложение Б. Копия акта о внедрении 183

Введение к работе

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

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

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

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

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

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

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

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

Цели и задачи исследования.

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

Классификация распределенных систем по отношению к использованию постоянных хранилищ информации.

Систематизация подходов к выполнению репликации данных.

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

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

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

Объект исследования.

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

8 Предмет исследования.

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

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

Информационная база исследования.

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

Научная новизна исследования.

1. Систематизированы методы выполнения репликации данных между
массивами хранения информации в распределенных системах.

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

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

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

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

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

Практическая значимость работы.

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

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

Апробация работы.

Основные результаты диссертационной работы докладывались и обсуждались на научно-технических конференциях профессорско-преподавательского состава Пензенского государственного университета (2000 - 2004), Международных научно-технических конференциях «Университетское образование» (Пенза, 1999 - 2000), «Проблемы автоматизации и управления в технических системах» (Пенза, 2004),

По теме диссертации опубликовано 10 печатных работ.

Реализация и внедрение.

Результаты проведенного исследования использованы в ходе разработки распределенного механизма репликации справочных данных, который был успешно внедрен в промышленную эксплуатацию в рамках подсистемы «Платежи населения» АС «София-ВМС» в Пензенском ОСБ №8624 СБ РФ. Результаты внедрения и эксплуатации подтвердили эффективность разработанных в ходе исследования подходов и методов и позволили констатировать, что разработанное программное обеспечение обладает высокой надежностью и отказоустойчивостью.

Результаты внедрения подтверждены соответствующим документом.

На защиту выносятся следующие положения-

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

  2. Метод организации хранения информации, необходимой для оперативного и точного отбора данных, подлежащих репликации;

  3. Метод построения инфраструктуры прикладного уровня распределенной системы в виде системы массового обслуживания;

4- Алгоритм порционной выборки больших наборов записей из базы данных;

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

Объем и структура работы.

Диссертационная работа состоит из введения, четырех глав, заключения, списка используемой литературы, включающего в себя 100 наименований, и двух приложений» Основной текст изложен на 164 страницах, содержит 5 таблиц и 48 рисунков, 2 приложения.

Обзор развития современных технологий создания распределенных вычислительных систем

Широкое распространение сетевых технологий и средств централизованного хранения данных создало в последние несколько лет предпосылки для кардинального пересмотра подходов к построению и разработке программных продуктов [32], Если еще в середине 90-х годов прошлого столетия настольные приложения занимали лидирующее положение на рынке программных продуктов, то в настоящее время подобные программы стали скорее исключением из общего правила» Круг задач, решаемых с помощью настольных приложений, сузился до таких несложных операций, как редактирование текста, выполнение нетрудоемких вычислений, создание графических изображений в однопользовательском режиме. При выполнении названных задач в условиях корпоративной рабочей команды у пользователей возникает потребность в средствах совместного доступа к обрабатываемым документам, поэтому даже текстовые и графические системы в настоящее время включают в себя инструменты распределенной обработки информации.

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

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

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

Компонентные технологии Единый для всех языков программирования стандарт интеграции компонентов. Единый стандарт интеграции распределенных компонентов в приложения. Введение элементов объекта о - ори є нтирован ного программирования в сферу организации распределенных вычислений.

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

Появление объектно-ориентированной технологии (ООП) программирования стало серьезным шагом на пути решения проблем, связанных с повторным использованием кода при разработке приложений. Центральным звеном в программах, разрабатываемых в соответствии с технологией ООП, стал объект, новое понятие, дополнившее перечень ранее существовавших программных элементов, таких, как функция, процедура, структура данных. Программный объект, представлягощий собой совокупность данных и методов их обработки, позволяет моделировать предметы окружающего нас мира. «Если нечто обладает определенным набором постоянных свойств, назовем это нечто объектам; если этот объект способен осуществлять какое-то действие, назовем это действие методам объекта» - таков был новый девиз программирования, провозглашенный автором объектно-ориентированного языка С-ьь Бьерном Страуструпом [79].

Предположим, перед нами стоит задача реализовать программу для работы с банковскими счетами [63]. Из анализа предметной области мы знаем, что любой счет характеризуется такими атрибутами, как остаток, дата открытия, имя владельца, дата начисления дохода и т.д. Кроме того, для любого счета возможны такие операции, как приход, расход, начисление дохода и т.д. Ничто ire мешает нам создать программный класс объектов, обладающий названными атрибутами и методами. Далее мы выясняем, что в зависимости от вида вклада операции со счетами производятся по-разному, но при этом набор постоянных атрибутов у всех счетов остается неизменным. Следовательно, для реализации работы со счетами разных видов нам не потребуется создавать новые классы с нуля: используя механизм наследования, входящий в арсенал объектно-ориентированной технологии программирования, можно разработать класс-потомок ранее созданного класса, описывающего основные свойства и перечень основных методов банковского счета. Класс-потомок наследует все атрибуты и реализацию методов класса-предка, хотя реализацию методов при наследовании можно переопределять, изменяя тем самым поведение нового класса объектов.

Определение основных направлений усовершенствования механизма репликации в контексте решаемой задачи

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

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

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

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

4. Программная архитектура механизма репликации должна быть спроектирована с учетом возможности масштабирования системы. Разрабатывая механизм репликации, предназначенный для функционирования в рамках распределенной вычислительной среды, необходимо принимать во внимание возможность изменения параметров системы, главным образом за счет увеличения ее масштабов. Главным условием успешного масштабирования распределенной системы является простота адаптации ее компонентов к новым условиям работы за счет внесения незначительных изменений в конфигурацию распределенных приложений [77], В случае разработки механизма необходимо учитывать, что в рамках масштабирования может потребоваться поддержка работы с различными системами, используемыми для организации локальных хранилищ данных. Данное обстоятельство должно приниматься во внимание при разработке механизмов репликации данных в распределенных системах, в особенности на этапе определения архитектуры решения и выбора технологии программной реализации.

Анализ приведенных требований позволяет выделить следующие показатели эффективности работы механизма репликации:

время, затрачиваемое на выполнение синхронизации содержимого хранилищ информации (Г);

объем данных, передаваемых по сети в процессе репликации (У);

объем дискового пространства, необходимый для накопления данных, подлежащих репликации (5);

отказоустойчивость (R) (выражается как время, требуемое для восстановления работоспособности после сбоя);

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

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

Разработка инфраструктуры управления потоками заявок

Программная архитектура механизма репликации, описанная в главе 2 (см. п. 2,3, рис. 2.5), определяет характер взаимодействия программных компонентов в процессе выполнения информационного обмена с отдельно взятым узлом системы. В данной главе будет рассмотрен процесс функционирования системы, имеющей подобную архитектуру, в условиях параллельной работы сервера с множеством клиентских приложений. Также будут выяснены возникающие при этом проблемы и предложены пути их решения.

Как известно [77], программные компоненты уровня прикладной логики и уровня доступа к данным реализуют функции, необходимые для работы множества приложений, входящих в состав системы. Следовательно, в процессе одновременной работы множества клиентских приложений на сервере создается множество экземпляров программных компонентов. Аналогичное утверждение можно отнести на счет одновременной работы приложений, использующих функции механизма репликации- Множественная активизация экземпляров компонентов прикладного уровня влечет за собой множественную активизацию экземпляров компонентов уровня доступа к данным. При этом каждая группа экземпляров компонентов, активизируемых одним приложением, устанавливает с базой данных, как показано на рисунке 3.1, по крайней мере, одно новое соединение. Таким образом, отсутствие ограничений на число активизируемых компонентов приводит к неконтролируемому росту числа активных соединений с базой данных.

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

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

Будем считать распределение таблиц между транзакциями бесконфликтным в том случае, если среди п транзакций на запись ни одна транзакция не обращается к таблице, которая в то же самое время используется хотя бы одной другой транзакцией на запись или на чтение» Иначе говоря, распределение таблиц между транзакциями будет бесконфликтным, если п транзакций на запись распределили между собой п таблиц без пересечений, а к транзакций на чтение каким угодно образом распределили между собой оставшиеся п—к таблиц. Соотношения (3.1.5) — (ЗЛ.7) позволяют заключить, что по мере приближения пкт вероятность бесконфликтного распределения быстро убывает. В соотношениях (3.1,5), (3.1.6) для равновероятного распределения знаменатель по мере увеличения п возрастает значительно быстрее, нежели числитель. Для выражения (3.1,7) можно также показать, что значение вероятности бесконфликтного распределения уменьшается с ростом п.

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

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

1) обеспечить возможность работы множества клиентских приложений при ограниченном числе активных соединений с базой данных;

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

Как указывается в [23, 63, 77], задача ограничения числа активных соединений с базой данных может быть решена двумя способами.

1. Путем определения максимального допустимого числа поддерживаемых соединений в параметрах сервера БД,

2. Путем создания «пула соединений» (connections pool) - специальным образом организованного конечного множества компонентов, используемых объектами уровня доступа к данным при обращении к БД.

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

Исследование эффективности систем хранения данных и распределенных программных технологий

Перед началом реализации репликационпых механизмов приложения «АРМ контролера по платежам населения» был произведен сравнительный анализ производительности ряда систем хранения данных и распределенных компонентных технологий» Были протестированы следующие системы хранения данных: - СУБД Paradox (взаимодействие через механизм BDE); - СУБД Firebird 1.5 Super Server (взаимодействие через собственный API СУБД посредством компонентов для систем Borland C++ Builder /Borland Delphi); - СУБД Microsoft Access XP (взаимодействие через интерфейс ADO-NET); - СУБД Microsoft SQL Server 2000 Desktop Edition (взаимодействие через интерфейс ADO.NET), Также были исследованы характеристики производительности следующих распределенных компонентных технологий: - DCOM; - СОМ+.

В число систем хранения данных, подлежащих тестированию, отбирались наиболее популярные в настоящие время продукты этой серии, пригодные для организации настольного (одномашинного) хранения данных. Как известно, СУБД Paradox и Access являются системами, специально ориентированными на организацию и управление локальными хранилищами данных. Система Firebird, представляющая собой модифицированный вариант широко известной серверной СУБД InterBase, с одинаковым успехом может быть использована как в многопользовательской системе, так и при работе настольных приложений, Microsoft SQL Server 2000 Desk top Edition - это редакции широке известной сершршзй СУБД, специально приспособленная для работы насголышх приложении,

Поскольку в процессе репликации инраШ -шых данных основным видом операций с таблицами локальной бты является добавление новых записей, в ходе исследования оцениванием главным образом, нрймя, затрачиваемое НУ выполнение операщш ветагмш в различных системах.

Сплети Firebird в Microsoft SQL Server 2000 позволяют сочдзшпъ в базах данных хранимые щкщедуры (stored prouixbrex) фрагменты откомпилированного кода на яшке SQL, тя исполнении гшторых система чаранеиг ймее з тішшй план» Как указано в [23 77, 81]. ш&пщщм наличию заранее подго-говлешюго плана исполнения, хранимые процедуры работают значительно 5шпрее, чем анаюгичные им просі ыс запросы (&d hoc queries) и их рекомендуется использовать в качестве эффективного средства повышения иром;шоди гельмостм приложений, работающих с базами данных,

В процессе проїшдеїшн сравнит ел ы юге анализа произвооттелыюстй СУВД было пришло решение прогеетироннгь, насколько эффективнооъ работы хранимых процедур при выполнений записи новых строк в таблицу отличается от работы простых НСДхшпросов. В связи с этим ;шя СУБД Firebird и Microsoft SQL Server 2000 выполнялось но 2 эксперимента. Системы Paradox и Mierosofl Access не поддерживают хранимые процедуры, поэтому с шшя работа осуществлялась только посредством простых SQI -шпросон.

Анализ дшптт графика позволяет заключить что на троке т 0 до 80,000 записей математическое ожидание и дисперсия функции остаются постоянными. При более высоких значении количества записей в таблице дисперсия заменю возрастает.

График вршеин на добавление 100 записей в СУБД Microsoft SQL Server2000 при использовании простых запросов приведен на рисунке 4,7.

Как видно из Приведенною графика, в случае использования SQL Server посредством просты_н запросов нрещ сс менее устойчив, нежели это наблюдается в случае СУБД Access. На графике можно видеть целый рад резких выбросов. Так же. как и в предыдущем случае, наиболее значительный выброс имеет место в самом начале отрезка. Характер наблюдаемого в данном случае процесса в основном аналогичен предыдущему случаю. Следует заметить, что наблюдаемые на приведенном графике выбросы по величине не столь резко отличаются от начального выброса, также имеющего место в начале координат. Величина начального выброса на рассматриваемом графике почти вдвое меньше аналогичной величины в предыдущем случае. Этот факт может быть объяснен тем, что в системе SQL Server 2000 исполнению простых запросов обязательно предшествует подготовительная фаза» в ходе которой составляется план выполнения запроса. При исполнении хранимых процедур готовый план уже имеется в системе, поэтому подготовительная фаза занимает меньшее количество времени.

Среднее значение для данного случая составляет 104 мс. Необходимо заметить, что средние величины, полученные для случаев использования SQL Server посредством выполнения простых запросов и хранимых процедур, значительно меньше отличаются друг от друга, нежели аналогичные значения для СУБД Firebird. Это позволяет сделать вывод о том, что в системе SQL Server 2000 реализован более эффективный оптимизатор запросов, позволяющий в некоторой степени нивелировать различия в быстродействии простых запросов и хранимых процедур.

Обобщая полученные результаты, можно сделать следующие выводы: 1)в рассмотренном диапазоне объемов таблиц производительность выполнения операции вставки в исследованных системах не зависит от количества записей, хранимых в таблице; 2)использование хранимых процедур в системе Firebird позволяет получить ощутимый выигрыш по производительности по сравнению с работой через простые запросы, в то время как в системе Microsoft SQL Server хранимые процедуры отличаются по быстродействию от простых запросов в гораздо меньшей степени; 3}система Microsoft SQL Server выигрывает по производительности по сравнению с Firebird примерно в 2 - 3 раза; 4)наиболее эффективной системой для хранения данных в случае настольного приложения среди рассмотренных СУБД является Paradox-СУБД Paradox, не будучи рассчитана на хранение сверхбольших объемов данных и интенсивную параллельную работу большого числа пользователей, в случае монопольного однопользовательского режима показывает наилучшие результаты по производительности.

Как указывалось выше, размер самого большого справочника, используемого в подсистеме «Платежи населения», составляет порядка 5,000 наименований. Практика показывает, что при таких объемах таблиц система Paradox работает весьма устойчиво. Снижение надежности хранения данных, выражающееся, прежде всего, в периодическом разрушении индексных файлов, наблюдается при переходе размеров таблиц за критическую отметку, превышающую 100,000 записей. На основании этих соображений и результатов произведенного сравнительного анализа было сделан вывод

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

Похожие диссертации на Алгоритмы репликации данных в распределенных системах обработки информации