Файл: "Технология построения распределенных информационных систем".pdf

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3 Задачи распределенных систем

Задачи распределенных систем

Рассмотрим четыре важнейшие задачи, решение которых делает построение распределенных систем осмысленным.

Задача 1. Доступ пользователей к ресурсам

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

Так, широкое использование сети интернет привело к появлению концепции виртуального офиса, когда географически удаленные друг от друга группы сотрудников работают вместе при помощи систем групповой работы (groupware) - программ для совместного редактирования документов, проведения презентаций и т.д.^[6]

Стоит заметить, что по мере роста степени совместного использования ресурсов все более и более важными становятся вопросы безопасности.

Задача 2. Прозрачность

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

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

1. Доступ (access transparency). Скрывается разница в представлении данных и доступа к ресурсам. Например, при передаче целого числа с компьютера на базе процессора Intel x86 на компьютер на базе процессора Sun SPARC следует учитывать, что на Intel используется Little Endian представление целых чисел, а на SPARC - Big Endian.
2. Местоположение (location transparency). Скрывается местоположение ресурса. Важную роль в реализации прозрачности местоположения имеет именование. Например URL http://www.yandex.ru/index.html не содержит никакой информации о реальном местоположении сервера Яндекса.
3. Перенос (migration transparency). Скрывается факт переноса ресурса в другое место. Т.е. смена местоположения ресурса не влияет на доступ к нему.
4. Смена местоположения (relocation transparency). Скрывается факт перемещения ресурса в другое место в процессе обработки. В качестве примера - мобильные пользователи, работающие с беспроводным переносным компьютером и не отключающиеся от сети при переходе с места на место.
5. Репликация (replication transparency). Скрывается факт репликации ресурса, т.е. существования нескольких копий ресурса. Для скрытия факта репликации необходимо, чтобы все реплики (копии) имели одно и то-же имя. Соответственно система, которая поддерживает прозрачность репликации должна поддерживать и прозрачность местоположения.
6. Параллельный доступ (concurrency transparency). Скрывает факт возможного совместного использования ресурса несколькими пользователями одновременно. Такой параллельный доступ к совместно используемому ресурсу сохраняет этот ресурс в непротиворечивом состоянии. Для обеспечения непротиворечивости может быть использован механизм блокировок или механизм транзакций (хотя реализация механизма транзакций - очень непростая задача в рамках распределенной системы)
7. Отказ (failure transparency). Скрывается факт выхода из строя и восстановления ресурса. Лэсли Лампорт: "Вы понимаете, что у вас есть эта штука, поскольку при поломке компьютера вам никогда не предлагают приостановить работу". Основная трудность состоит в сложности отличить неработоспособный ресурс от ресурса с очень медленным доступом.
8. Сохранность (persistence transparency). Скрывается, хранится программный ресурс на диске или находится в оперативной памяти. Например, многие объектно-ориентированные базы данных предоставляют возможность непосредственного вызова методов для сохранных объектов. Сервер БД при этом копирует состояние объекта в оперативную память, вызывает метод объекта запрошенный пользователем и сохраняет новое состояние объекта на диск. Пользователь об этой цепочке ничего не знает.

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

Задача 3. Открытость

Открытая распределенная система (open distributed system) - это система, предполагающая службы, вызов которых осуществляется с использованием стандартизированного синтаксиса и семантики.

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

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

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

Переносимость (portability) характеризует то, насколько приложение, разработанное для распределенной системы A может без изменений выполняться в распределенной системе B.

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

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

Задача 4. Масштабируемость

Масштабируемость системы может измеряться по трем различным показателям:

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

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

Например:

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

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

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

1. ни одна из машин не обладает полной информацией о состоянии системы;
2. машины принимают решения на основе локальной информации;
3. сбой в работе одной машины не нарушает работу алгоритма;
4. не требуется предположение о существовании единого времени.

Первые три свойства более-менее понятны, последнее-же возможно требует некоторого уточнения. Любой алгоритм, начинающийся со слов "Ровно в 12:00:00 все машины делают ..." работать не будет, поскольку невозможно синхронизировать все часы на свете.

NOTE: Google Spanner http://research.google.com/archive/spanner.html . Один из компонентов системы - атомные часы в каждом сервере.