Архитектура распределенных информационных систем и Web-приложений

Распределенная система - это набор независимых вычислительных машин, представляющийся их пользователям единой объединенной системой. Не смотря на то, что все компьютеры автономны, для пользователей они представляются единой системой.

К основным характеристикам распределенных систем:

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

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

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

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

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

К особенностям функционирования распределенных систем относятся:

· наличие большого количества объектов;

· задержки выполнения запросов (так если локальные вызовы требуют порядка пары сотен наносекунд, то запросы к объекту в распределенных системах требует от 0.1 до 10 мс);

· некоторые объекты могут не использоваться на протяжении длительного времени;

· распределенные компоненты выполняются параллельно, что приводит к необходимости согласования выполнения;

· запросы в распределенных системах имеют большую вероятность отказов;

· повышенные требования к безопасности.

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

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

Архитектура Web-приложений (Web -сервиса) широко применяется в настоящее время. Web-сервис – приложение, доступное через Интернет. Оно предоставляет услуги, форма которых не зависит от поставщика услуг, так как используется универсальная платформа функционирования и универсальный формат данных (XML). В основе Web –сервисов лежат стандарты, определяющие форматы и язык запросов, а также протоколы поиска этих сервисов в Интернете. Схема доступа к базе данных через Интернет показана на рис.1.12.

Рисунок 1.12 – Схема доступа к серверу СУБД через Интернет

В настоящее время существуют три различных технологии, поддерживающие концепцию распределенных объектных систем: EJB, DCOM CORBA.

Основная идея, лежащая в разработке технологии EJB (Enterprise Java Beans ) – создать такую инфраструктуру для компонентов, чтобы они могли бы легко вставляться и удаляться из серверов, тем самым повышая или снижая функциональность сервера. EJB-компоненты являются Java-классами и могут работать на любом EJB-совместимом сервере даже без перекомпиляции. Основными целями EJB-технологии является:

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

2. Описать основные структуры EJB-системы и интерфейсы взаимодействия между ее компонентами.

3. Освободить разработчика от реализации EJB-объектов за счет наличия специального кодогенератора.

Благодаря используемойJava-модели, EJB является относительно простым и быстрым способом создания распределенных систем.

Технология DCOM (Distributed Component Object Model ) - программная архитектура, разработанная компанией Microcoft для распределения приложений между несколькими компьютерами в сети. Программный компонент на одном из компьютеров может использовать DCOM для передачи сообщений к компоненту на другом компьютере. DCOM автоматически устанавливает соединение, передает сообщение и возвращает ответ удаленного компонента. Способность DCOM связывать компоненты позволила Microcoft наделить Windows рядом дополнительных возможностей, в частности, реализовать сервер Microsoft Transaction Server, отвечающий за выполнение транзакций баз данных через Интернет.

ВВЕДЕНИЕ 4

1.ПОНЯТИЕ РАСПРЕДЕЛЕННЫХ ИС 6

1.1. Предпосылки создания распределенных ИС 6

1.2. Понятие распределенных информационных систем 8

1.3. Средства работы с распределенными данными 11

2. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ 13

2.1. Основные принципы 13

2.2 Типы распределенных БД 15

2.3. Назначение и принцип работы распределенной БД 16

3. ПРИМЕРЫ РАСПРЕДЕЛЕННЫХ СИСТЕМ 21

ЗАКЛЮЧЕНИЕ 25

ЛИТЕРАТУРА 26

ВВЕДЕНИЕ

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

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

В данной работе рассмотрены основные сведения о распределенной информационной системе: описаны предпосылки ее развития, средства работы с данными, введено понятие распределенной базы данных, а также ее типов и основных принципов. В третьей главе представлены примеры распределенных информационных систем, такие как: - Informix On-Line фирмы Informix Software;- Ingres Intelligent Database фирмы Ingres Corp;- Oracle (version 7) фирмы Oracle Corp;- Sybase System 10 фирмы Sybase Inc.

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

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

1.ПОНЯТИЕ РАСПРЕДЕЛЕННЫХ ИС

1.1. Предпосылки создания распределенных ИС

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

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

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

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

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

1.2. Понятие распределенных информационных систем

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

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

Данные из разнородных систем обычно объединяются в логические группы, к которой и адресуются запросы. Абстрактная система запросов предполагает, что система оперирует не конкретным синтаксисом запросов, а его логической сутью на основе абстрактных атрибутов.
При построении распределенных ИС, как правило, используются две базовые архитектуры: Клиент/сервер и Internet Intranet.
Корпоративные ИС, построенные по архитектуре Клиент/сервер, предоставляют клиентам широкий спектр приложений и инструментов разработки, которые ориентированы на максимальное использование вычислительных возможностей клиентских рабочих мест. Ресурсы сервера используются в основном для хранения и обмена документами, а также для выхода во внешнюю среду. Данная архитектура позволяет лучше защитить серверную часть приложений, при этом, предоставляя возможность приложениям либо непосредственно адресоваться к другим серверным приложениям, либо маршрутизировать запросы к ним. Однако, частые обращения клиента к серверу снижают производительность работы сети. Приходится решать вопросы безопасной работы в сети, так как приложения и данные распределены между различными клиентами. Распределенный характер построения системы обусловливает сложность ее настройки и сопровождения

В основе ИС на базе Internet Intranet лежит принцип "открытой архитектуры". ПО ИС реализуется в виде аплетов или сервлетов (программ на языке JAVA) или в виде cgi модулей (программ на Perl или С). ИС данной архитектуры включает Web-yinh\, реализованные при помощи технологий CORBA Enterprise JavaBeans, ActiveX 1X"ОМ, многоуровневые приложения на основе Java и XML, .Net-концепция с XML, в которой обмен между различными серверами (хранилищами данных, бизнес-приложениями, серверами для мобильных клиентов и другое) производится при помощи нейтрального к любой архитектуре XML.

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

Функционирующих по единым правилам, определенным централизованно для всех баз данных, входящих в распределенную информационную базу;

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

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

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

1.3. Средства работы с распределенными данными

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

1) Фрагментация и дублирование

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

2) Словари данных и директории

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

3) Двухфазная фиксация изменений

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

4) Обеспечение целостности

Важной характеристикой распределенной ИС является то, как она обеспечивает поддержку ссылочной целостности между данными таблицы-мастера и данными связанных с ней таблиц. Рассмотрим пример ссылочной целостности. Предположим в распределенной БД имеются три таблицы:

Таблица, содержащая информацию о детях сотрудников;

Таблица, содержащая информацию о зарплатах сотрудников за год;

Таблица, содержащая информацию о темах, выполненных сотрудником.

Все эти таблицы содержат столбец "ФИО сотрудника". Правила обеспечения ссылочной целостности требуют, чтобы при изменении значений столбца "ФИО сотрудника" в одной таблице, автоматически выполнялась корректировка значений этого столбца в других таблицах. Для обеспечения ссылочной целостности используются 2 различных метода - триггеры и декларативные ограничения целостности стандарта ANSI .

2. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ

2.1. Основные принципы

Распределённые базы данных (РБД) - совокупность логически взаимосвязанных баз данных, распределённых в компьютерной сети.

РБД состоит из набора узлов, связанных коммуникационной сетью, в которой:

а)каждый узел - это полноценная СУБД сама по себе;

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

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

Фундаментальный принцип создания распределённых баз данных («правило 0»): Для пользователя распределённая система должна выглядеть так же, как нераспределённая система.

Фундаментальный принцип имеет следствием определённые дополнительные правила или цели. Таких целей всего двенадцать:

1.Локальная независимость. Узлы в распределённой системе должны быть независимы, или автономны. Локальная независимость означает, что все операции на узле контролируются этим узлом.

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

3.Непрерывное функционирование. Распределённые системы должны предоставлять более высокую степень надёжности и доступности.

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

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

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

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

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

9.Аппаратная независимость. Желательно иметь возможность запускать одну и ту же СУБД на различных аппаратных платформах и, более того, добиться, чтобы различные машины участвовали в работе распределённой системы как равноправные партнёры.

10.Независимость от операционной системы. Возможность функционирования СУБД под различными операционными системами.

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

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

2.2. Типы распределенных БД

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

Помимо вышеназванных типов распределенных баз данных можно выделить следующие:

1) Распределённые Базы Данных

2) Мультибазы данных с глобальной схемой. Система Мультибаз данных - это распределённая система, которая служит внешним интерфейсом для доступа ко множеству локальных СУБД или структурируется, как глобальный уровень над локальными СУБД.

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

4) Мультибазы с общим языком доступа - распределённые среды управления с технологией "клиент-сервер"

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

2.3. Назначение и принцип работы распределенной БД

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

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

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

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

Рис.2.1. Принцип работы БД

Узел 1 является корневым для всей распределенной базы и главным узлом для подчиненных ему второму и третьему. Второй узел является главным узлом для подчиненных ему четвертому и пятому. Третий узел будет главным для подчиненных ему шестому, седьмому и восьмому.

Любой узел распределенной базы данных (УРБД) "видит" только узлы, напрямую связанные с ним. С такими узлами он и осуществляет обмен данными.

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

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

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

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

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

Обмен данными между базами производится следующим образом:

1)В базе-источнике система определяет список изменённых объектов за время, прошедшее с предыдущего сеанса выгрузки данных.

2)По данному списку система формирует XML-пакет, который передается в базу-приемник.

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

3) XML-пакет передается в базу-приемник.

В базе-приемнике XML-пакет разворачивается и изменения, содержащиеся в нем, вносятся в базу.

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

3. ПРИМЕРЫ РАСПРЕДЕЛЕННЫХ СИСТЕМ

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

Среди многочисленных прототипов и научно-исследовательских систем следует упомянуть систему SDD-1 , созданную в конце 70-х -- начале 80-х годов в научно-исследовательском отделении фирмы Computer Corporation of America; систему R* , которая является распределенной версией системы System R и создана в начале 80-х годов фирмой IBM; а также систему Distributed INGRES , которая является распределенной версией системы INGRES и создана также в начале 80-х годов в Калифорнийском университете в Беркли.

Что касается коммерческих продуктов, то в настоящее время в большинстве реляционных систем предусмотрены разные виды поддержки использования распределенных баз данных с разной степенью функциональности. Среди таких систем наиболее известны система INGRES/STAR отделения Ingres Division фирмы The ASK Group Inc., система ORACLE фирмы Oracle Corporation, а также модуль распределенной работы системы DB2 фирмы IBM.

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

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

Informix On-Line фирмы Informix Software;

Ingres Intelligent Database фирмы Ingres Corp;

Oracle (version 7) фирмы Oracle Corp;

Sybase System 10 фирмы Sybase Inc.

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

Наиболее полно функции распределенной СУБД реализованы в СУБД Ingres и Oracle. Коротко рассмотрим возможности этих пакетов.

СУБД Ingres работает на множестве UNIX-платформ, на платформах DEC VMS, Hewlett-Packard MPE, DOS, Microsoft Windows 3.1, OS/2, Macintosh. Она также работает со многими сетевыми протоколами, включая Open System Interconnection Transport Class 4. Ingres имеет средства для доступа к данным СУБД DB2, Rdb, Allbase. Основные функции распределенной СУБД обеспечиваются дополнительной компонентой Ingres/Star. Она поддерживает оптимизацию распределенных запросов, позволяет читать и обновлять в рамках одной транзакции данные разных узлов, обеспечивает возможность удалять записи одновременно в нескольких узлах.

СУБД Informix-Online разработана для среды UNIX, но может также работать под Novell. Informix-Online имеет оптимизатор запросов и реализует те же функции работы с распределенной БД, что и Ingres, однако у Informix более жесткие требования к ресурсам компьютера, в частности ему требуется больше оперативной памяти.

СУБД System 10 фирмы Sybase в настоящее время находится в состоянии разработки. Она должна работать на UNIX-платформах, на платформах OS/2, Window NT, NetWare. System 10 будет работать с несколькими сетевыми протоколами и поддерживать связь с СУБД DB2, Oracle 7, Informix-Online, Rdb. System 10 будет иметь оптимизатор распределенных запросов, она позволит читать и обновлять данные нескольких узлов. Функции работы с распределенной БД будут реализованы с помощью дополнительной компоненты Replication Server.

В 7 версии СУБД Oracle реализовано множество функций для работы с распределенной БД. Среди них следует выделить оптимизатор распределенных запросов и средство чтения и обновления данных нескольких узлов в рамках одной транзакции. Oracle v 7 работает на более чем 80 вычислительных платформах, поддерживает большинство существующих коммерческих сетевых протоколов и может обмениваться данными с СУБД DB2, SQL/DS, Tandem Computers, NonStop SQL, Rdb, HP TurboImage. Разрабатываются шлюзы еще к 18 СУБД.

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

Все 4 рассмотренные СУБД поддерживают локальную автономию узлов. Это означает, что администратор БД может рассматривать локальную БД конкретного узла как самостоятельную БД. Все СУБД поддерживают ANSI стандарт языка SQL - ANSI SQL-89 и расширение этого стандарта. Запросы к БД формулируются на языке SQL. Дополнительно к непроцедурному языку SQL Oracle поддерживает свой собственный процедурный язык PL/SQL, а Sybase поддерживает свой язык Transact-SQL.

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

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

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

ЗАКЛЮЧЕНИЕ

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

Необходимость оперативного получения информации из баз данных дистанционно отдаленных подразделений (или филиалов);

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

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

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

ЛИТЕРАТУРА

1. Как организовать распределенную информационную базу?

http://www.intelis-it.ru/services/automation_act/information-systems.html

2. Распределенные базы данных. Википедия.

http://ru.wikipedia.org/wiki/распереленные_бд

3. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – 2-е изд. – М.: Финансы и статистика, 1989. – 350 с.

4. Дейт К. Дж. Введение в системы баз данных.: Пер. с англ. – 6-е изд. – Киев: Диалектика, 1998. – 784 с.

5. Распределенные информационные системы и базы данных. Глеб Ладыженский

http://articles.org.ru/cfaq/index.php?qid=1306&catid=54

6. . Глобально распределенные информационные системы

http://www.ci.ru/inform4_97/astr1.htm

7. Проектирование структуры распределенной базы данных.

http://www.integro.ru/projects/gis/quest_1.htm

8. Коннолли, Т., Бегг, К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание.: Пер. с англ. - М.: Издательский дом «Вильяме», 2003. – 433 с.

http://www.lcard.ru/~nail/database/osbd/glava_~3.htm

10. Технологии распределенных баз данных

http://rema.44.ru//resurs/study/dblab/dblab.html.

ВВЕДЕНИЕ 4

1.ПОНЯТИЕ РАСПРЕДЕЛЕННЫХ ИС 6

1.1. Предпосылки создания распределенных ИС 6

1.2. Понятие распределенных информационных систем 8

1.3. Средства работы с распределенными данными 11

2. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ 13

2.1. Основные принципы 13

2.2 Типы распределенных БД 15

2.3. Назначение и принцип работы распределенной БД 16

3. ПРИМЕРЫ РАСПРЕДЕЛЕННЫХ СИСТЕМ 21

ЗАКЛЮЧЕНИЕ 25

ЛИТЕРАТУРА 26

ВВЕДЕНИЕ

1.ПОНЯТИЕ РАСПРЕДЕЛЕННЫХ ИС

1.1. Предпосылки создания распределенных ИС

1.2. Понятие распределенных информационных систем

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

1.3. Средства работы с распределенными данными

1) Фрагментация и дублирование

2) Словари данных и директории

3) Двухфазная фиксация изменений

ВВЕДЕНИЕ 4

1.ПОНЯТИЕ РАСПРЕДЕЛЕННЫХ ИС 6

1.1. Предпосылки создания распределенных ИС 6

1.2. Понятие распределенных информационных систем 8

1.3. Средства работы с распределенными данными 11

2. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ 13

2.1. Основные принципы 13

2.2 Типы распределенных БД 15

2.3. Назначение и принцип работы распределенной БД 16

3. ПРИМЕРЫ РАСПРЕДЕЛЕННЫХ СИСТЕМ 21

ЗАКЛЮЧЕНИЕ 25

ЛИТЕРАТУРА 26

ВВЕДЕНИЕ

1.ПОНЯТИЕ РАСПРЕДЕЛЕННЫХ ИС

1.1. Предпосылки создания распределенных ИС

1.2. Понятие распределенных информационных систем

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

Главная > Документ

РАСПРЕДЕЛЕННЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ

Ю.А. Илларионов

ГЛАВА 1. АНАЛИЗ СОСТОЯНИЯ РАЗВИТИЯ ОСНОВНЫХ КОНЦЕПЦИЙ И АЛГОРИТМОВ УПРАВЛЕНИЯ ДЛЯ РАСПРЕДЕЛЁННЫХ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ НА БАЗЕ ЛОКАЛЬНЫХ СЕТЕЙ. 1.1. Определение области исследования. Распределённой вычислительной системой (РВС) будем называть систему, состоящую из двух компонентов: множества электронно вычислительных машин (ЭВМ) и сети связи (или сети передачи данных), объединяющей все ЭВМ, входящие в РВС. Всю полезную обработку информации производят вычислительные процессы, выполняющиеся на хост ЭВМ . Всю обработку информации, связанную с необходимостью её передачи через сеть связи, выполняют процессы, расположенные на коммуникационных ЭВМ .Коммуникационные ЭВМ необходимы в сетях связи, имеющих сложную многосвязную топологию, при условии, что прямые физические соединения (каналы) между взаимодействующими посредством передачи информации хост ЭВМ отсутствуют. Таким образом, учитывая, что для эффективной обработки информации в РВС необходимо не только эффективно её обрабатывать на хост ЭВМ , но и эффективно (т.е. с наименьшими задержками) передавать её через сеть связи, работы в области РВС разделились на две группы: 1. Работы в области организации взаимодействия вычислительных процессов в РВС. В этих работах предполагается, что сеть связи уже существует и удовлетворяет определённым требованиям, выдвигаемым к ней. Таким образом, остаётся только решить задачу организации взаимодействия вычислительных процессов, учитывая, что:

оперативных систем

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

соединения между портами не являются фиксированными, и структура логических связей в сети может динамически изменяться; сеть может иметь многосвязную топологию, в которой отсутствуют непосредственные физические соединения между портами; информация в процессе передачи может искажаться; потоки информации, включая их объём и направление, заранее не определены; для организации передачи информации через сеть связи требуется организовать разделение коммуникационных ресурсов между потоками информации в условиях недостатка этих ресурсов; управление разделением коммуникационных ресурсов имеет тенденцию к децентрализации. Настоящая диссертация относится к работам первой группы и посвящена только вопросам организации взаимодействия вычислительных процессов в РВС. Определим область исследования более точно. Учитывая, что с точки зрения возможностей технических средств РВС в основном различаются по применяемым в них сетям связи, распределённые системы можно разбить на две большие группы: РВС, построенные на базе сетей с маршрутизацией и РВС, построенные на базе сетей с селекцией информации, или сетей с общим каналом связи. Настоящая работа посвящена вопросам организации разделения вычислительных ресурсов в РВС, предназначенных для управления производственными процессами в реальном времени и построенных на базе локальных сетей связи с децентрализованным приоритетным управлением доступом к общему каналу. Вопросы децентрализованного приоритетного управления доступом (ДПУ) рассмотрены в работах. В этих же работах впервые была высказана мысль о том, что наличие средств ДПУ и средств обработки информации непосредственно в общем канале в процессе передачи может по новому организовать управление взаимодействием распределённых вычислительных процессов в РВС. Другими словами, локальные сети с ДПУ можно рассматривать не только как систему связи, но и как дополнительное средство управления распределёнными системами. Однако, этот вопрос не был до конца исследован. Итак, основной целью настоящей работы является исследование вопросов разделения ресурсов РВС между вычислительными процессами в условиях существующей распределённости как ресурсов, так и процессов, при наличии множества параллельно возникающих в неопределённые моменты заявок на использование ресурсов; на основании проведённых исследований в работе должны быть разработаны новые высокоскоростные алгоритмы разделения ресурсов для РВС, построенных на базе локальных сетей с ДПУ и средствами вычислений в общем канале (ВОК).Как уже было отмечено, исследования будут вестись в области РВС для промышленного применения, т.е. для систем реального времени. С точки зрения вычислительных мощностей этой системы, построенные в основном на базе микропроцессорной техники, поэтому в дальнейшем будем называть такие РВС распределёнными микропроцессорными управляюще вычислительными системами (РМУВС). Учитывая существующие особенности сетей связи для исследуемых систем, проанализируем эти особенности в сравнении с другими известными сетями.1.2. Особенности локальных сетей с децентрализованным приоритетным управлением доступом к каналу. Первые публикации, посвящённые принципам передачи информации через общий канал связи в режиме его разделения многими абонентами (с точки зрения сети, абонент – это хост ЭВМ, имеющая доступ к каналу через сетевой контроллер; в более широком смысле абонентом может быть и отдельный процесс, выполняемый на хост ЭВМ), появились в начале 70 х годов. К этому моменту был накоплен достаточно большой опыт по созданию РВС на базе глобальных сетей, и это отразилось на решениях, которые в дальнейшем были использованы в РВС на базе локальных сетей (или локальных РВС ЛРВС). В некоторых работах до сих пор не делается различия между организацией управления в глобальных РВС и ЛРВС, а считается, что эти два класса различаются только по протяжённости их линий связи. Появление стандартов IEEE 802 и ECMA внесло некоторую ясность в этот вопрос, однако только в отношении организации связи с ЛРВС. Поэтому в большинстве работ, посвящённых организации взаимодействия вычислительных процессов в ЛРВС, не учитывается специфика таких систем, которая будет отражена ниже. Однако, ряд авторов считает, что ЛРВС в их современном понимании являются системами, по своим архитектурным особенностям приближающимся скорее к многопроцессорным системам, чем к «вычислительным сетям» в их традиционном понимании. В особенности это относится к исследуемым в настоящей работе системам – ряд отличительных признаков позволяет рассматривать их как совершенно новый класс РВС, построенных на базе локальных сетей связи с уникальными возможностями, недоступными в других распределённых системах. Отметим основные архитектурные особенности локальных сетей связи с ДПУ и ВОК, которые будут иметь значение в дальнейшем исследовании.

эффективное средство

Высокая скорость

передаваемых пакетов

Перечисление особенности сетей связи с ДПУ и ВОК даёт основания считать, что ЛРВС, построенные на базе таких сетей, нельзя рассматривать как «те же большие вычислительные сети, только маленькие», хотя вообще такая позиция в настоящее время широко распространена. Перейдём к рассмотрению основных задач и концепций управления в распределённых системах.1.3. Основные задачи и концепции управления в распределённых вычислительных системах. Основной задачей управления в любой вычислительной системе является задача разделения ресурсов в условиях недостатка последних. В РВС задача разделения имеет свои особенности, связанные с распределением ресурсов и процессов по различным абонентам системы. Перечислим эти особенности.

Поскольку в РВС входит множество ЭВМ, то каждая из них может иметь свои ресурсы, доступные для процессов, выполняющихся как локально (т.е. на этой же ЭВМ), так и удалённо (т.е. на другой ЭВМ). Если ресурс является локальным (т.е. полностью принадлежит отдельной ЭВМ), то ответственность за корректную синхронизацию процессов при доступе к такому ресурсу полностью возлагается на эту ЭВМ. В этом случае проблемы синхронизации не возникает, если ресурс является монопольно используемым. Если же ресурс является коммунальным, то в РВС возникает проблема разделения такого ресурса из за того, что если в сосредоточенных централизованных системах большинство накладных расходов на организацию разделения (т.е. выделение памяти для буферов и т.д.) берут на себя сами процессы по принципу «кому нужно, тот и платит», то в РВС эти расходы возлагаются на обслуживающую ЭВМ и получается, что «кто обслуживает, тот ещё и платит». В РВС ресурс может быть организован таким образом, что для решения о его предоставлении некоторому процессу необходимо коллективное согласие всех ЭВМ, которым принадлежат отдельные части такого ресурса, называемого распределённым. Эта задача возникла первоначально в распределённых базах данных, в которых для обеспечения высокой надёжности хранения информации применялось её многократное копирование и распределение копий по системе. Возникающая при этом задача синхронизации при обновлении многих копий распределённой информации является базовой задачей распределённого управления в РВС, и от эффективности её решения зависит в конечном итоге эффективность управления в целом. Традиционно в любых вычислительных системах управление разделением ресурсов возлагается на системное программное обеспечение – операционные системы (ОС). Для РВС это также справедливо – подобное программное обеспечение называется распределёнными операционными системами (РОС). Несмотря на большое разнообразие существующих в настоящее время РОС и различие в применяемых в них алгоритмов управления, их можно классифицировать на основании нескольких базовых моделей, приводимых ниже.Модель МРММ (много ресурсов – много мониторов). Основной идеей, положенной в основу этой модели, является принцип автономности, согласно которому любая ЭВМ, входящая в РОС, является «хозяином» своих собственных локальных ресурсов и только она имеет право решать задачу их разделения. При таком подходе на каждой ЭВМ имеется процесс, являющийся монитором ресурсов этой ЭВМ. Все остальные процессы связаны с мониторами посредством механизма обмена сообщениями через транспортную сеть согласно семиуровневой архитектуре |SO/OSI.Модель МРММ является моделью вычислительной сети в её традиционном понимании; системы, построенные в соответствии с этой моделью, предназначены в основном для реализации «электронной почты» и организации доступа к ресурсам удалённых ЭВМ. Задача управления разделением распределённых ресурсов в таких системах не решается.Модель МРОМ (много ресурсов – один монитор). Полностью централизованная модель. В систему вводится центральный процесс, являющийся монитором всей системы и в частности, монитором распределённых ресурсов. Все остальные процессы имеют доступ к мониторам только посредством обращения к центральному монитору. Управление разделением распределённых ресурсов в этом случае не составляет трудности, но введение центрального процесса резко снижает надёжность работы РВС. Поэтому централизованные способы управления применяются, как правило, только в самых простых распределённых системах, не предназначенных для ответственных применений.Модель ОРММ (один ресурс – много мониторов). Модель основана на предположении, что в системе имеется ресурс, надёжность которого намного больше, чем надёжность любого монитора. В действительности, как уже было сказано, такие ресурсы образуются за счёт копирования наиболее важных системных ресурсов и распределения копий по различным абонентам РВС; причём каждая копия имеет свой монитор. Считывать информацию можно параллельно с любой работоспособной копии ресурса, обновлять информацию необходимо на всех копиях. В этих условиях при обновлении информации все мониторы копий должны взаимодействовать с целью с целью принятия коллективного решения о предоставлении ресурса для операции обновления или записи. Такие РВС называются системами с распределённым (децентрализованным коллективным) управлением; их развитию и посвящена настоящая работа. Ключевым вопросом для таких систем является проблема синхронизации мониторов при выработке или коллективного решения. В зависимости от методов, используемых в настоящее время для синхронизации мониторов, РВС этого класса можно разбить на две группы. В РВС первой группы мониторы взаимодействуют, обмениваясь сообщениями через транспортную сеть. Основное достоинство подобных систем состоит в том, что алгоритмы синхронизации мониторов в этом случае не зависят от структуры сети (топологии, методов доступа и т.д.) и могут быть использованы в любых РВС. Однако, как будет показано в дальнейшем, алгоритмы этого класса требуют пересылки значительного количества сообщений через транспортную сеть, что приводит к большим временным расходам на синхронизацию. При оценке эффективности алгоритмов следует учитывать то, что накладные расходы на пересылку одного сообщения через транспортную сеть составляют около 20 мс для широкого круга распределённых систем. Тем не менее, такой подход к синхронизации широко используется из за отсутствия в настоящее время подходящих альтернативных способов для сетей ЭВМ. В РВС второй группы для синхронизации мониторов применяются специально выделенные линии связи, по которым возможна передача только синхронизирующей управляющей информации (импульсов, потенциалов на линиях и т.д.). Такой принцип используется в мультимикропроцессорных системах с сетевой организацией, имеющих небольшую протяжённость линий связи. Однако для РВС на базе локальных сетей большой протяжённости (до 2 км) такой подход неприемлем из за значительного увеличения кабельной продукции, поскольку число линий синхронизации может зависеть как от числа распределённых продуктов, так и от числа абонентов системы. Перейдём к рассмотрению известных алгоритмов разделения ресурсов в РВС с распределённым управлением.1.4. Алгоритмы разделения ресурсов для систем с распределённым управлением. Все алгоритмы разделения ресурсов для систем с распределённым управлением можно разбить на три группы: алгоритмы с использованием голосования, алгоритмы с использованием предварительной блокировки и алгоритмы с циркулирующей привилегией.Алгоритмы с использованием голосования основаны на процессе обмена сообщениями между процессами контроллерами с целью прихода к соглашению относительно последовательности транзакций в распределённой системе. Под транзакцией понимается последовательность операций чтения информации из некоторой базы данных, обновления (изменения) считанной информации и записи обновлённой информации в базу данных. Если голосования и выполнение транзакций производителя одними и теми же контроллерами, то голосование называется синхронным; если разными, то голосование называется асинхронным. В алгоритме синхронного голосования контроллер, контроллер, принявший запрос на транзакцию, присоединяет тег – временной штамп из сообщения, содержащего суть запроса и идентификатор пославшего запрос абонента. Далее, если не было инициировано голосование предыдущей транзакции, этот контроллер посылает широковещательное сообщение со своим голосом всем остальным контроллерам (рис. 1.1.). Если предположить, что можно отличить более высокий приоритет некоторой транзакции Т а от приоритета транзакции Т с, то система из трёх контроллеров будет работать следующим образом. 1. Контроллер В: если голос для транзакции Т с принят раньше, чем некоторый голос для Т а, то контроллер В широковещательно посылает свой голос, отдавая его Т с (рис. 1.1а.). При получении запроса на транзакцию Т а В уничтожает Т с и широковещательно отдаёт свой голос транзакции Т а (рис. 1.1б.). Если голос за транзакцию Т а принят раньше, В сразу отдаёт свой голос за Т а, отбрасывая голоса за Т с, пришедшие позднее.Рис 1.1. 2. Контроллер С: отдаёт свой голос за Т а при приёме голоса за Т а. 3. Контроллер А: отбрасывает все голоса за Т с. После приёма голосов от всех контроллеров за одну и ту же транзакцию (в рассмотренном случае Т а) каждый из контроллеров начинает выполнение этой транзакции. В другом алгоритме синхронного голосования явно выделяется инициирующий контроллер. Если транзакция поступила к контроллеру на выполнение (т.е. от пользователя), то этот контроллер инициирует голосование, посылая запрос на начало голосования остальным контроллерам. Если все остальные контроллеры ответят на этот запрос передачей сообщения АСК + , то транзакция принимается и инициирующий контроллер широковещательно посылает UPD сообщение для локальных инициаций транзакции всеми остальными контроллерами. Контроллеры, закончившие локальное выполнение транзакции (или вообще не начинавшие её выполнение) сигнализируют ответом END инициатору. После приёма END – сообщений от всех контроллеров, инициатор переходит в начальное состояние. Контроллеры, завершившие очередную транзакцию, также переходят в начальное состояние и готовы для новых транзакций. Каждый из контроллеров, приняв запрос на новую транзакцию, может начать её выполнение только в том случае, если она совместима с текущей транзакцией, выполняемой контроллером. Только в этом случае сообщение АСК + может быть послано инициатору, и начаться выполнение новой транзакции после приёма UPD. Транзакции считаются совместимыми, если они запрашивают различные наборы чтения и записи для своего выполнения. Приоритеты транзакций различаются согласно алгоритму, приведённому в работе.На рис. 1.2. показано, как различается конфликт в том случае, когда две совместимые транзакции инициируют запрос на голосование. Контроллеры А и С голосуют за Т а и Т с конкурентно. Контроллер В голосует за обе транзакции, т.к. он находится в начальном состоянии. А и С голосуют друг за друга после проверки, что транзакции Т а и Т с совместимы (б). Инициируется локальное выполнение транзакций (в) и после завершения локального выполнения сигнализируется окончание (г). Алгоритмы асинхронного голосования были использованы в распределённой базе данных SDD 1. В этой системе транзакции группируются в набор классов транзакций в соответствии сих наборами чтения и записи. Классы транзакций предварительно определяются администратором базы данных. С целью уменьшения затрат на синхронизацию разработаны четыре различных протокола синхронизации. Протокол Р1 предоставляет управление на нижнем уровне, обладая минимальной стоимостью и высокой эффективностью, в то время, как протокол Р4 обеспечивает верхний уровень управления, обладая большими накладными расходами. Протоколы выбираются в соответствии с классами транзакций. Упорядочивание запросов чтения/записи от различных параллельных транзакций осуществляется путём присваивания временных штампов транзакциям и записи этих временных штампов во все запрошенные элементы базы данных, к которым конкретная транзакция имеет доступ.Изменение копии элемента базы данных предоставляется транзакции только в том случае, если временной штамп запроса транзакции на изменение более новый по сравнению с временным штампом копии. Это гарантирует, что все копии приходят в одинаковое состояние одновременно с прекращением процедур их обновления. Класс транзакций в SDD 1 определён как набор транзакций, связанных с отдельной хост ЭВМ, на которой расположена новая база данных. Все транзакции, принадлежащие характеризуются взаимоисключающими наборами чтения

и взаимоисключающими наборами записи

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

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

. Примитивы и неделимы, в то время как комбинация L и U транзакции t не нуждаются в неделимости. В SDD 1 возможна такая последовательность примитивов L и U при условии, что история выполнения трёх транзакций t1,t2 и t3 сохраняется .Для определения возможного взаимовлияния транзакций из разных классов, вызванного перекрытием наборов записи и чтения, предлагается конструкция, названная L U графом. Этот граф соединяет пары узлов, отмеченных как L и U для каждого класса .Дуги между

и остальными узлами находятся в соответствии со следующими типами взаимовлияния транзакций: 1 .Дуга к узлу U, принадлежащему к тому же классу. 2 .Дуга к узлу

другого класса на той же хост ЭВМ m возникает при выполнении условий

или

(горизонтальная дуга). 3 .Дуга к узлу

того же класса, расположенному на другой хост ЭВМ возникает, если

(горизонтальная дуга). 4. Дуга к узлу U другого класса, расположенному на другой хост ЭВМ возникает, если

, . 5. Дуги между узлом U и другими узлами возникают по следующему правилу: к , если

и (диагональная дуга). На рис. 1.3. показан L U граф для транзакций классов

при условиях

Как только граф L U для данной системы построен, определяется таблица для выбора одного из четырёх протоколов Р1 Р4 для каждого класса транзакций в соответствии с топологией L U по следующим правилам. Протоколы Р2 и Р3 идентичны, за исключением правил присваивания временного штампа голосовательным сообщениям, которые широковещательно адресуются всем контроллерам. Протокол Р2 выбирает наиболее новый временной штамп из , в то время как Р3 выбирает временной штамп с текущим временем. На рис. 1.4. показана работа протоколов Р2 и Р3. Предположим, что две транзакции t a и t c конкурируют, причём транзакция t c имеет более новый временной штамп. Тогда контроллеры А,В и С взаимодействуют следующим образом при голосовании:

Если к А приходит голос за t c , он помещается в очередь.

Разработка распределенных информационных систем. Общая классификация и характеристика технологий распределенных информационных систем

Архитектура распределенных информационных систем и Web-приложений