Малков О.Б., Гегечкори Е.Т. Базы данных

Подождите немного. Документ загружается.

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

Взаимодействие пользователя с БД строится на основе модели «клиент –

сервер». Клиентская часть отвечает за целевую обработку данных и

организацию взаимодействия с пользователем. Серверная часть обеспечивает

хранение данных, обрабатывает запросы и посылает результаты клиенту для

специальной обработки. В общем случае эти части функционируют на

отдельных компьютерах, т. е. к серверу БД с помощью сети подключены

компьютеры клиентов.

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

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

программам;

 централизовать функции управления, такие как защита информации,

обеспечение целостности данных, управление совместным использованием

ресурсов;

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

БД;

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

 повышать эффективность управления данными за счет

использования специальных серверов баз данных.

В архитектуре «файл-сервер» (рис. 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-запросов.

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

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

множестве клиентских приложений;

 централизованное ведение бизнес-логики (при внесении изменений

их не нужно тиражировать в клиентских приложениях);

 на клиентских машинах не следует устанавливать компоненту

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

 оптимизация доступа к БД (диспетчеризация запросов

выполняется сервером приложений);

 возможность отложенного обновления БД при изменении данных в

автономном режиме (данные будут обновлены в БД при следующем

соединении);

 повышение скорости и надежности за счет дублирования ПО на

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

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

приложений.

 уменьшение мощности сервера приложений за счет параллельной

работы сервера приложений и сервера БД.

5.3. Транзакции

Транзакция – это законченная совокупность действий над БД, которая

переводит ее из одного целостного состояния в другое. Если операторы

транзакции выполняются, происходит ее нормальное завершение и БД

переходит в обновленное (целостное) состояние (ситуация 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 имя_точки_сохранения) или к состоянию начала транзакции.

5.4. Сериализация транзакций

При совместной работе с БД нескольких пользователей СУБД должна

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

обработки транзакций позволяют изолировать пользователей друг от друга.

Подходящими единицами изолированности пользователей являются

транзакции.

Чтобы понять, как должны выполняться параллельные транзакции,

рассмотрим проблемы, возникающие при параллельной работе с данными.

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

Проблема утраченных обновлений заключается в том, что если

пользователи параллельно обновляют одни и те же данные, то запомнится

обновление, проведенное последним. Остальные будут потеряны (рис. 45).

Рис. 45. Проблема утраченного обновления

Проблема зависимости от незафиксированных обновлений состоит в

том, что пользователь А может увидеть данные, которые были обновлены

пользователем В, но эти обновления не были окончательно зафиксированы.

Пользователь В может провести откат БД в исходное состояние (рис. 46).

Рис. 46. Преждевременное чтение

Пользователь А будет предпринимать действия над ошибочными

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

преждевременное чтение.

Еще одна проблема возникает, если пользователь проводит групповую

обработку данных, не связанную с корректировкой (вычисляет сумму или

среднюю величину), а какие-то значения обрабатываемого множества в этот

момент претерпевают изменения в результате выполнения параллельной

транзакции. Иногда разделяют ситуации, когда проводится изменение

существующих записей и когда осуществляется вставка новой записи.

Первая проблема называется неповторяющееся чтение, а вторая –

фантомная вставка (строки-призраки) (рис. 47).

Рис. 47. Фантомная вставка

Чтобы добиться изолированности транзакций, СУБД должна

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

транзакций.

Метод сериализации транзакций – это механизм их выполнения по

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

эквивалентен результату некоторого последовательного выполнения этих же

транзакций. Обеспечение такого механизма является основной функцией

управления транзакциями. Сериализация транзакций реально обеспечивает

изолированность пользователей.

Простейшим решением является действительно последовательное

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

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

проблемным ситуациям. Примерами могут служить транзакции,

выполняющие только операции чтения, или транзакции, работающие с

разными объектами БД.

Между транзакциями могут существовать следующие виды конфликтов:

 транзакция 2 пытается изменять объект, измененный

незакончившейся транзакцией 1 (конфликт W-W, запись-запись);

 транзакция 2 пытается изменять объект, прочитанный

незакончившейся транзакцией 1 (конфликт R-W, чтение-запись);

 транзакция 2 пытается читать объект, измененный незакончившейся

транзакцией 1 (конфликт W-R, запись-чтение).

Для обеспечения сериализации транзакций применяются методы

захвата и освобождения объектов по инициативе транзакции. Транзакция

захватывает объект, что приводит к его блокировке для других транзакций, и

освобождает его только при своем завершении.

Захваты объектов на чтение несколькими транзакциями совместимы

(нескольким транзакциям разрешается читать один объект), захват объекта

одной транзакцией на чтение не совместим с захватом другой транзакцией

этого объекта на запись, захваты одного объекта разными транзакциями на

запись не совместимы.

Тем самым, выделяются два основных режима захватов:

 совместный режим – S (Shared), означающий разделяемый захват

объекта и необходимый для выполнения операции чтения объекта;

 монопольный режим – X (eXclusive), означающий монопольный

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

модификации.