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

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

Разделение процесса на клиентскую и серверную компоненты позволяет:

· одновременно использовать БД различным прикладным программам;

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

· обеспечивать параллельную обработку запроса в распределенных БД;

· высвобождать ресурсы рабочих станций и сети;

· повышать эффективность управления данными за счет использования специальных серверов баз данных.

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

Рис. 38. Архитектура «файл – сервер»

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

Недостатки архитектуры:

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

· низкий уровень защиты данных, так как доступ к файлам БД управляется общими средствами ОС сервера;

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

Для схемы характерно наибольшее суммарное время обработки информации.

В архитектуре «выделенный сервер базы данных» (рис. 39) средства управления базой данных и база данных размещены на машине-сервере (DB-сервер).

Рис. 39. Архитектура с выделенным сервером базы данных

Обращение к БД осуществляется на языке SQL, поэтому сервер БД часто называют SQL-сервером. Он поддерживается всеми реляционными СУБД (Oracle, Informix, MS SQL, DB2, ADABAS D, InterBase, SyBase). Сервер БД осуществляет поиск записей и анализирует их. Записи, удовлетворяющие условиям, могут накапливаться на сервере и после обработки запроса передаваться пользователю. Клиентское приложение может быть реализовано на языке настольных СУБД (MS Access, FoxPro, Paradox, Clipper). Взаимодействие клиентского приложения с SQL-сервером осуществляется через ODBC-драйвер(Open DataBase Connectivity). ODBC стал стандартом де-факто на алгоритм доступа к разнородным БД.

Достоинства архитектуры:

· снижение нагрузки на машины сервера и клиентов;

· снижение сетевого трафика и повышение эффективности обработки за счет оптимизации и буферизации ввода-вывода;

· защита данных средствами СУБД, позволяющая блокировать не разрешенные пользователю действия;

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

Недостатки архитектуры:

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

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

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

Рис. 40. Архитектура «активный сервер баз данных»

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

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

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

Рис. 41. Трехзвенная архитектура сервера приложений

Связь клиентских рабочих станций с прикладными программами на сервере приложений устанавливается через интерфейс API (Application Programming Interface). Работа клиентской части сводится к вызову функций сервера приложений. Прикладные программы обращаются к серверу БД с помощью SQL-запросов.

К достоинствам трехзвенной архитектуры относятся:

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

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

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

· оптимизация доступа к БД (диспетчеризация запросов выполняется сервером приложений);

· возможность отложенного обновления БД при изменении данных в автономном режиме (данные будут обновлены в БД при следующем соединении);

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

· перенос проверки полномочий пользователей с сервера БД на сервер приложений.

· уменьшение мощности сервера приложений за счет параллельной работы сервера приложений и сервера БД.

Транзакции

Транзакция – это законченная совокупность действий над БД, которая переводит ее из одного целостного состояния в другое. Если операторы транзакции выполняются, происходит ее нормальное завершение и БД переходит в обновленное (целостное) состояние (ситуация COMMIT на рис. 42). При сбое происходит откат к исходному состоянию БД (ситуация ROLLBACK на рис. 42).

Рис. 42. Выполнение и откат транзакции

К транзакциям предъявляется набор требований, известный под названием ACID (Atomicity, Consistency, Isolation, Durability).

Атомарность (atomicity). Транзакция представляет собой набор законченных действий. Система обеспечивает их выполнение по принципу «все или ничего» – либо выполняются все действия, тогда транзакция фиксируется, либо (при сбое) транзакция откатывается назад, а БД остается в исходном состоянии.

Согласованность (consistency). Предполагается, что в результате выполнения транзакции система переходит из одного корректного состояния в другое.

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

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

Рассмотрим две модели транзакций, используемые в большинстве коммерческих СУБД: модель автоматического выполнения транзакций и модель управляемого выполнения транзакций, основанные на инструкциях языка SQL – COMMIT и ROLLBACK.

Автоматическое выполнение транзакций. Модель создана на основе схемы, принятой в СУБД DB2. Транзакция автоматически начинается с выполнения пользователем или программой первой инструкции. Далее происходит последовательное выполнение инструкций, пока транзакция не завершится (рис. 43).

Транзакция заканчивается одним из двух способов:

· инструкцией COMMIT, которая выполняет завершение транзакции (внесенные в БД изменения становятся постоянными, а новая транзакция начинается сразу после инструкции COMMIT);

· инструкцией ROLLBACK, которая отменяет выполнение текущей транзакции (БД возвращается к состоянию начала транзакции, новая транзакция начинается сразу после инструкции ROLLBACK).

Рис. 43. Модель автоматического выполнения транзакций

Управляемое выполнение транзакций. Модель используется в СУБД Sybase, где применяется диалект Transact-SQL, в котором для обработки транзакций служат четыре инструкции (рис. 44):

· инструкция BEGIN TRANSACTION сообщает о начале транзакции (начало транзакции задается явно);

· инструкция COMMIT TRANSACTION сообщает об успешном выполнении транзакции (при этом новая транзакция автоматически не начинается);

· инструкция SAVE TRANSACTION позволяет создать внутри транзакции точку сохранения и присвоить сохраненному состоянию имя точки сохранения, указанное в инструкции;

· инструкция ROLLBACK отменяет выполнение текущей транзакции и возвращает БД к состоянию, где была выполнена инструкция SAVE TRANSACTION (если в инструкции указана точка сохранения – ROLLBACK TO имя_точки_сохранения) или к состоянию начала транзакции.