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

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

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

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

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

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

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

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

Системы баз данных, построенные с помощью сетевых версий, иногда неправомерно называют распределенными базами данных, в то время как фактически имеют дело лишь с распределенным (сетевым) доступом к централизованной базе данных. Такие системы создаются на основе оборудования и программного обеспечения различных ло­кальных вычислительных сетей; большинство СУБД работает в сетях 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-модель является фундаментом для мониторов обработки транзакций.