Алешин Л.И., Максимов Н.В. Информационные технологии

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

361

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

В архитектуре сервера БД, схема которого представлена на Рис.

19-2, средства управления базой данных и БД размещены на машине-

сервере.

Взаимодействие между клиентом и сервером происходит на уров-

не команд языка манипулирования данными СУБД (обычно SQL), кото-

рые обрабатываются СУБД на машине-сервере. Сервер базы данных

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

щие условиям, могут накапливаться на сервере и после того, как запрос

будет целиком обработан, пользователю на клиентскую машину пере-

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

летворяющие поисковым условиям.

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

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

• возможность обслуживания запросов нескольких клиентов;

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

• защита данных осуществляется средствами СУБД, что позволяет

блокировать неразрешенные пользователю действия;

• сервер реализует управление транзакциями и может блокировать

попытки одновременного изменения одних и тех же записей.

Недостатки:

• бизнес-логика функциональной обработки и представление дан-

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

и это увеличит совокупные потребности в ресурсах при исполнении –

повторение части кода программ и запросов;

• низкий уровень управления непротиворечивостью информации,

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

клиентской части, могут быть противоречивыми.

Данная технология позволяет снизить сетевой трафик и повысить

общую эффективность обработки за счёт оптимизации и буферизации

ввода-вывода. Т.о., сервер может осуществить поиск и обрабатывать за-

362

просы даже быстрее, чем, если бы они обрабатывались на рабочей стан-

ции.

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

Для того чтобы устранить недостатки, свойственные архитектуре

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

логики и изменения БД контролировались на стороне сервера. Причём

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

последовательность взаимодействия приложения с БД.

Для этого функции бизнес-логики разделяются между клиентской

и серверной частью. Общие или критически значимые функции оформ-

ляются в виде хранимых процедур, включаемых в состав БД. Кроме это-

го, вводится механизм отслеживания событий БД – триггеров, также

включаемых в состав базы. При возникновении соответствующего со-

бытия (обычно изменения данных), СУБД вызывает для выполнения

хранимую процедуру, связанную с триггером, что позволяет эффективно

контролировать изменение БД.

Хранимые процедуры и триггеры могут быть использованы лю-

быми клиентскими приложениями, работающими с БД. Это снижает

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

ляции каждого запроса (Рис. 19-3).

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

Недостатком такой архитектуры становится существенно возрас-

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

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

Такую архитектуру организации взаимодействия и рассматривае-

мый далее сервер приложений иногда называют моделью с «тонким

клиентом», в отличие от предыдущих архитектур, называемых моделью

с «толстым клиентом», где на стороне клиента выполняется большин-

ство функций.

363

Архитектура «сервер приложений»

Рассмотренные выше архитектуры являются двухзвенными – все

функции доступа и обработки распределены между программой клиента

и сервером БД. Дальнейшее снижение требований к ресурсам клиента

достигается за счёт введения промежуточного звена – сервера приложе-

ний, на который переносится значительная часть программных компо-

нентов управления данными и большая часть бизнес-логики. При этом

серверы баз данных обеспечивают исключительно функции СУБД по

ведению и обслуживанию БД. Схема трёхзвенной архитектуры сервера

приложений приведена на Рис. 19-4.

Рис. 19-4. Архитектура сервера приложений

К другим (организационно-технологическим) достоинствам трёх-

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

• централизованное ведение бизнес-логики и в случае их измене-

ния отсутствие необходимости их тиражирования в клиентских прило-

жениях;

• отсутствие необходимости устанавливать на клиентских маши-

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

ным;

• возможность отложенного обновления БД в случае изменения

данных, запрошенных с сервера, в автономном режиме. Данные будут

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

с сервером приложений.

Архитектура сервера баз данных

Повышение эффективности и оперативности обслуживания боль-

шого числа клиентских запросов, помимо простого увеличения ресурсов

и вычислительной мощности сервера, может быть достигнуто двумя пу-

тями:

364

• снижением суммарного расхода памяти и вычислительных ре-

сурсов за счёт буферизации (кэширования) и совместного использования

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

дур;

• распараллеливанием процесса обработки запроса – использова-

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

подзапросов и (или) для одновременного обращения к частям БД, раз-

мещённым на отдельных физических носителях.

Рассмотрим архитектуры, реализующие следующие модели совме-

стной обработки клиентских запросов.

Архитектура «один к одному»

В этом случае (Рис. 19-4) для обслуживания каждого запроса за-

пускается отдельный серверный процесс.

Рис. 19-5. Архитектура сервера «один к одному»

Таким образом, даже если от клиентов поступят совершенно оди-

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

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

и использовать одни и те же ресурсы.

Многопотоковая односерверная архитектура

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

процесс (использующий один процессор), взаимодействующий со всеми

клиентами и монопольно управляющий ресурсами (Рис. 19-6). При этом

для отдельного клиентского процесса создаётся поток, (thread) в рамках

которого локализуется обработка запроса.

Рис. 19-6. Многопотоковая односерверная архитектура

Запрос 1

Серверный

процесс 1

Запрос N

Серверный

Процессор

БД

Запрос 1

Запрос N

Сервер-процесс

Процессор

БД

Поток 1

Поток N

365

Мультисерверная архитектура

Если для работы СУБД используются многопроцессорные плат-

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

для параллельной обработки между процессорами. Такое решение (Рис.

19-7) требует введения дополнительного звена, в задачи которого входит

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

процессоров.

Рис. 19-7. Многопотоковая односерверная архитектура

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

приложение, говорят, что СУБД имеет мультисерверную многопотоко-

вую архитектуру.

Следует отметить, что характер распределения запросов в значи-

тельной степени зависит от того, поддерживает ли ОС потоковую обра-

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

дач.

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

Для повышения оперативности за счёт распараллеливания процес-

са обработки отдельного клиентского запроса в мультисерверной архи-

тектуре можно использовать следующие подходы:

1) Размещение хранимых данных БД на нескольких физиче-

ских носителях (сегментирование базы). Для обработки запроса в этом

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

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

гих выполняет одинаковую последовательность действий, определяе-

мую существом запроса, но с данными, принадлежащими разным сег-

ментам базы. Полученные таким образом результаты объединяются и

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

горизонтального параллелизма.

2) Запрос обрабатывается по конвейерной технологии. Для это-

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

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

цессом независимо от обработки других подзапросов. Получаемые ре-

зультаты объединяются согласно схеме декомпозиции запроса и пере-

Запрос 1

Запрос 2

Запрос N

Серверный

процесс

Серверный

процесс

Процессор

БД

366

даются клиенту. Такой тип распараллеливания называют моделью вер-

тикального параллелизма.

Примерная схема обработки клиентского запроса, построенная с

использование обеих моделей параллелизма (гибридная модель) приве-

дена на Рис. 19-8.

Рис. 19-8. Архитектура сервера обработки запроса

при гибридном параллелизме

Использование моделей параллельной обработки позволяет суще-

ственно сократить общее время обслуживания запроса, что особенно

важно в случае работы с большими БД и аналитической обработки

(OLAP-приложений).

Программное обеспечение распределенных приложений

Распределенные корпоративные приложения всё более усложня-

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

и вновь приобретаемые готовые программные средства. Кроме того,

разные подсистемы решают разные бизнес-задачи, однако одна из глав-

ных целей создания корпоративной системы – получить «единый образ»

общего состояния системы, что обеспечит пользователям доступ к нуж-

ным операциям и ресурсам.

Основа такой инфраструктуры – так называемое промежуточное

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

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

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

кациям.

Промежуточное ПО эволюционировало вместе с архитектурой

клиент-сервер. Ранние, но достаточно эффективные как с точки зрения

разработки, так и эксплуатации, частные решения предназначались для

упрощения доступа к БД в двухзвенной модели, где «толстый» клиент

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

ром БД. Такие системы вполне удовлетворяли потребностям небольших

корпоративных подразделений с ограниченным числом пользователей и

невысокой интенсивностью обмена.

Однако, по мере того, как клиент-серверная архитектура стала

Запрос

Подзапрос 1

Подзапрос 2

Подзапрос N

Серверный

процесс

Серверный

процесс

Процессор

Сегмент

367

проникать в сферу высококритичных корпоративных приложений, об-

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

значительными массивами данных, стали очевидны недостатки двух-

звенного подхода. Этот способ реализации клиент-серверной схемы дос-

тупа ограничивал возможности масштабирования, поскольку увеличе-

ние числа обращений к одной БД непомерно увеличивало нагрузку на

сервер и делало доступ к данным «узким местом» в общей производи-

тельности системы. Кроме того, всякая модификация логики приложе-

ния требовала внесения изменений во все экземпляры клиентских при-

ложений.

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

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

приложения на отдельный уровень сервера приложений. В результате

клиентская часть приложения становится «тоньше» и в основном отве-

чает за предоставление удобного пользовательского интерфейса. Как

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

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

с помощью специальных расширений СУБД, например, хранимых про-

цедур. Перенос основных операций приложения на отдельный уровень

позволяет с максимальной эффективностью распределить нагрузку на

аппаратные средства (трёхзвенная модель на самом деле может быть

многозвенной с разделением нагрузки на несколько серверов приложе-

ний) и обеспечивает безболезненное наращивание как функционально-

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

Развитие этого среднего звена клиент-серверной модели идёт в

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

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

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

общие API (Application Program Interface), которые скрывали различия

специфических интерфейсов коммуникационных протоколов более низ-

кого уровня, например, TCP/IP, Sockets или DECNet. Однако теперь это-

го явно недостаточно для построения сложных распределенных прило-

жений. Современные решения не только обеспечивают межпрограммное

взаимодействие, но и являются платформой для реализации сервера

приложений, обеспечивая обширный набор необходимых служб: управ-

ления транзакциями, именования, защиты и т.д.

Вычислительная среда распределённых приложений может вклю-

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

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

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

различаться.

Таким образом, в распределённой неоднородной среде программ-

ное обеспечение промежуточного уровня играет роль «информационной

шины», надстроенной над сетевым уровнем и обеспечивающей доступ

приложения к разнородным ресурсам, а также независимую от платформ

368

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

приложений от уровня сетевого взаимодействия и ОС (Рис. 19-9).

Рис. 19-9. Структура компонент поддержки удаленного доступа

ПО промежуточного уровня можно разделить на две категории:

1. ПО доступа к БД (например, ODBC-интерфейсы и SQL-

шлюзы);

2. ПО межмодульного взаимодействия – системы, реализующие

вызов удаленных процедур (RPC – Remote Procedure Call); мониторы

обработки транзакций (TP-мониторы); средства интеграции распреде-

ленных объектов.

При этом различия прикладных задач не позволяют построить

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

можности.

Доступ к базам данных в двухзвенных моделях клиент-сервер

В простых двухзвенных моделях клиент-сервер, где несколько БД

обслуживают ограниченное число пользователей настольных ПК, в роли

встроенного ПО доступа к данным могут выступать обычные ODBC-

драйверы.

Необходимость в более сложных решениях возникает в больших,

разнородных многозвенных системах, где множество приложений в па-

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

данных, включая разнотипные СУБД и хранилища данных. В таких сис-

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

точное звено – SQL-шлюз, представляющий набор общих API, позво-

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

ным данным (в формате SQL или с помощью ODBC-интерфейса). SQL-

шлюз выполняет синтаксический разбор такого запроса, анализирует и

Приложения

Бизнес-

прило-

жения

Средства

разработки

Сетевое

управ-

ление

Систем-

ное

управ-

ление

Готовые про-

граммные паке-

ты

RPС, MOM, TPM, ORB, COM,

Доступ к базам данных

TCP/IP SPX/IPX SNA DECnet X.25 …

UNI

VMS N

Macin-

tosh

OS/

WIN-

DOWS

Os/40

…

369

оптимизирует его и, в конце концов, выполняет преобразование в SQL-

диалект нужной СУБД. ПО этого типа реализует синхронный механизм

связи, когда выполнение приложения, сделавшего запрос, блокируется

до момента получения данных.

Пример такого приложения – система анализа статистических

данных о деятельности компаний, отбирающая соответствующую ин-

формацию из расположенных в различных регионах БД с разными

СУБД. Подобные решения достаточно просты, не требуют сложных ме-

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

ную миграцию важных приложений с унаследованных платформ в архи-

тектуру клиент-сервер.

Каждое приложение, построенное на основе архитектуры «клиент-

сервер», включает, как минимум, две части:

− клиентскую часть, отвечающую за целевую обработку данных

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

− серверную часть, собственно хранящую данные, обрабатываю-

щую запросы и посылающую результаты клиенту для специальной об-

работки.

В общем случае предполагается, что эти части приложения функ-

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

помощью сети подключены узлы – компьютеры пользователей (клиен-

ты). При этом узел-клиент сам может быть СУБД.

Создается такое приложение обычно с использованием средств

языков высокого уровня (например, C++, Pascal, Visual Basic), позво-

ляющих реализовать эффективную целевую обработку данных и друже-

ственный пользовательский интерфейс. В исходный текст программы

включаются SQL-выражения, специфицирующие условия выборки или

изменения данных в базе. Во время исполнения приложения эти выра-

жения передаются серверу, который собственно и манипулирует данны-

ми. Данные, полученные в результате выполнения сервером SQL-

запросов, возвращаются прикладной программе и размещаются в зара-

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

корректировки записей.

Рассмотрим различные способы организации доступа прикладной

программы к серверу базы данных в двухзвенной архитектуре.

Использование библиотек доступа и встраиваемого SQL

Каждая СУБД помимо интерактивной SQL-утилиты обязательно

имеет библиотеку процедур доступа и набор драйверов СУБД для раз-

личных операционных систем. Схема взаимодействия клиентского при-

ложения с сервером базы данных в этом случае представлена на Рис. 19-

10:

370

Рис. 19-10. Схема взаимодействия с использованием

библиотек процедур доступа

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

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

получать данные – результаты обработки запроса. Типичный набор

функций такой библиотеки включает:

• соединение с БД;

• запрос к БД на выполнение SQL-выражения;

• запрос на извлечение данных;

• запрос на изменение данных;

• закрытие соединения с БД.

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

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

док и имена столбцов, число строк, номер текущей строки), передви-

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

Библиотечные вызовы преобразуются драйвером БД в сетевые вы-

зовы и передаются сетевым ПО на сервер. На сервере происходит об-

ратный процесс преобразования сетевых пакетов в SQL-запросы, кото-

рые обрабатываются СУБД. Результаты обработки передаются клиенту.

Такой способ создания приложений достаточно гибок и позволяет

реализовать практически любое приложение, однако имеет и недостат-

ки:

Се

ве

Прикладная

программа

Библиотечные

функции

Драйвер СУБД

Драйвер сети

СУБД

Драйвер сети

Сеть