Имя материала: Организация работы с документами

Автор: Кудряев В.А

19.6. системы распределенной обработки данных

 

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

Существует несколько понятий в этой области, которые необходимо определить более точно. Вначале выделим эти понятия:

распределенная обработка данных;

базы данных с сетевым доступом;

архитектура «клиент-сервер»;

распределенные базы данных.

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

Системы баз данных, построенные с помощью сетевых версий, иногда неправомерно называют распределенными базами данных, в то время как фактически имеют дело лишь с распределенным (сетевым) доступом к централизованной базе данных. Такие системы создаются на основе оборудования и программного обеспечения различных локальных вычислительных сетей; большинство СУБД работает в сетях IBM PC Network (IBM Corp.), Novell Network (Novell Inc.).

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

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

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

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

Протокол, принятый, например, в СУБД R:BASE for DOS, допускает возможность блокирования ресурсов данных вплоть до уровня поля. Благодаря этому два пользователя могут одновременно обновлять одну и ту же строку таблицы, но разные ее поля. Выбор разработчиками такой мелкой единицы блокирования позволяет минимизировать интегральное время ожидания доступа к блокированному ресурсу при исполнении приложения. Представляют интерес «тонкие» средства блокирования ресурсов, при котором один пользователь блокирует строку для обновления, а другой — может тем не менее в это же время читать ее. СУБД позволяет пользователям иметь информацию о том, кто в данный момент блокирует запрашиваемые ими данные.

Сложные проблемы связаны в мультипользовательском режиме работы с базами данных с тупиковыми ситуациями (Deadlock). В технологии баз данных предусматривается специальная техника профилактики возникновения тупиковых ситуаций и отката (Roll-Back) транзакций при их возникновении.

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

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

 

19.6.1. Архитектура «клиент-сервер»

 

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

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

В ответ на пользовательский запрос рабочая станция получит не «сырье» для последующей обработки, а готовые результаты. Программное обеспечение рабочей станции при такой архитектуре играет роль только внешнего интерфейса (Front—end) централизованной системы управления данными. Это позволяет существенно уменьшить сетевой трафик, сократить время на ожидание блокированных ресурсов данных в мультипользовательском режиме, разгрузить рабочие станции и при достаточно мощной центральной машине использовать для них более дешевое оборудование.

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

Для современных СУБД архитектура «клиент-сервер» стала фактически стандартом.

Если предполагается, что проектируемая информация будет иметь архитектуру «клиент-сервер», прикладные программы, реализованные в ее рамках, будут иметь распределенный характер. Это означает, что часть функций приложений будет реализована в программе-клиенте, другая — в программе-сервере. Основной принцип технологии «клиент-сервер» заключается в разделении функций стандартного интерактивного приложения на четыре группы:

функции ввода и отображения данных;

прикладные функции, характерные для предметной области;

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

служебные функции.

Исходя из этого деления любое приложение может состоять из следующих компонентов:

компонент представления (функции первой группы);

прикладной компонент (функции второй группы);

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

Различия определяются четырьмя факторами:

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

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

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

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

Исходя из этих допущений рассмотрим четыре подхода, реализованные в моделях технологии «клиент-сервер».

1. FS-моделъ — базовая для локальных сетей персональных компьютеров. Применялась для разработки информационных систем на базе FoxPRO, Clipper, Paradox.

Основные требования:

выделяется файл-сервер для реализации услуг по обработке файлов других узлов сети; работает под управлением сетевых ОС;

играет роль компонент доступа к информационным ресурсам;

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

протокол обмена — набор низкоуровневых вызовов;

Технология: запрос направляется на файловый сервер, который передает СУБД, размещенной на компьютере-клиенте, требуемый блок данных. Вся обработка осуществляется на компьютере-клиенте.

Недостатки:

высокий сетевой трафик;

небольшое число операций манипулирования;

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

2. RDA-модель.

Основные требования:

коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте;

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

Технология:

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

инициатор манипуляций с данными — программы на компьютере-клиенте.

Достоинства:

процессор сервера загружается операциями обработки данных;

уменьшается загрузка сети, так как передаются по сети запросы на языке SQL;

унификация интерфейса «клиент-сервер» в виде языка SQL; использование его в качестве стандарта общения клиента и сервера.

Недостатки:

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

3. DBS-модель, — реализована в реляционных СУБД Informix,

Ingres, Oracle.

Основные требования:

основа модель-механизм хранимых процедур — средство программирования SQL-сервера;

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

компонент представления выполняется на компьютере-клиенте, прикладной компонент и ядро СУБД — на компьютере-сервере базы данных.

Достоинства:

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

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

ограниченность средств для написания хранимых процедур. На практике чаще используется разумный синтез RDA- и DBS-моделей для построения многопользовательских информационных систем.

4. AS-модель. Основные требования:

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

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

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

все операции над БД выполняются соответствующим компонентом, для которого AS — клиент.

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

AS-модель является фундаментом для мониторов обработки транзакций.

 

19.6.2. Распределенные базы данных

 

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

большой поток обменов данными;

низкая надежность;

низкая общая производительность;

большие затраты на разработку.

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

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

улучшенное использование данных на местах при выполнении удаленных (дистанционных) запросов;

меньшие затраты;

простота управления.

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

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

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

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

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

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

Самый высший уровень архитектуры распределенной СУБД — это интерфейс прикладной программы и интерфейс процессора запросов.

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

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

1-4 уровни архитектуры распределенной СУБД относятся к сетевой СУБД.

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

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

Дейт установил 12 свойств или качеств идеальной распределенной базы данных:

1. Локальная автономия (local autonomy).

2. Независимость узлов (no reliance.on central site),

3. Непрерывность операции {continuous operation).

4. Прозрачность расположения (location independence).

5. Прозрачная фрагментация (fragmentation independence).

6. Прозрачное тиражирование (replication independence).

7. Обработка распределенных запасов (distributed query processing).

8. Обработка распределенных транзакций (distributed transaction processing).

9. Независимость от оборудования (hardware independence).

10. Независимость от операционных систем (operationg system independence).

11. Прозрачность сети (network independence).

12. Независимость от баз данных (database independence).

 

Локальная автономия.

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

 

Независимость от центрального узла.

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

 

Непрерывные операции.

Это качество можно трактовать как возможность непрерывного доступа к данным (известное «24 часа в сутки, семь дней в неделю») в рамках DDB вне зависимости от их расположения и вне зависимости, от операций, выполняемых на локальных узлах. Это качество можно выразить лозунгом «данные доступны всегда, а операции над ними выполняются непрерывно».

 

Прозрачность расположения.

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

 

Прозрачная фрагментация.

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

 

Прозрачность тиражирования.

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

 

Обработка распределенных запросов.

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

 

Обработка распределенных транзакций.

 Это качество DDB можно трактовать как возможность выполнения операций обновления распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и согласованность данных. Эта цель достигается применением двухфазового или двухфазного протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции.

 

.Независимость от оборудования.

 Это свойство означает, что в качестве узлов распределенной системы могут выступать компьютеры любых моделей и производителей — от мэйнфреймов до «персоналок».

 

Независимость от операционных систем.

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

Прозрачность сети.

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

 

Независимость от баз данных.

Это качество означает, что в распределенной системе могут мирно сосуществовать СУБД различных

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

Исходя из определения Дэйта СУБД в общем случае можно рассматривать как слабосвязанную сетевую структуру, узлы которой представляют собой локальные базы данных. Локальные базы данных автономны, независимы и самоопределены; доступ к ним обеспечивается от различных поставщиков. Связи между узлами — это потоки тиражируемых данных. Топология DDB варьирует в широком диапазоне — возможны варианты иерархии, структур типа «звезда» и т.д. В целом топология DDB определяется географией информационной системы и направленностью потоков тиражирования данных.

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

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

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

3. Распределенные базы данных могут быть однородными или неоднородными в смысле аппаратных и программных средств (СУБД). Проблему неоднородности сравнительно легко решить, если распределенная база является неоднородной в смысле аппаратных средств, но однородной в смысле программных средств (одинаковые СУБД в узлах). Если же в узлах распределенной системы используются разные СУБД, необходимы средства преобразования структур данных и языков. Это должно обеспечить прозрачность преобразования в узлах распределенной базы данных.

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

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

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

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

 

Страница: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 |