Максимов Н.В., Голицына О.Л., Васина Е.Н. Управление данными

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

231

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

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

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

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

ента и сервером БД.

Дальнейшее снижение требований к ресурсам клиента достигается

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

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

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

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

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

ложений приведена на рис. 8.4.

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

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

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

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

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

жениях;

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

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

ным;

232

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

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

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

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

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

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

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

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

то двумя путями:

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

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

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

дур;

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

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

подзапросов и/или для одновременного обращения к частям базы дан-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запрос 1

Серверный

процесс 1

Запрос N

Серверный

процесс N

Процессор

БД

233

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

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

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

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

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

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

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

шение (рис. 8.7) требует введения дополнительного звена, в задачи ко-

торого входит диспетчеризация запросов для обеспечения сбалансиро-

ванной загрузки процессоров.

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

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

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

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

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

тельной степени зависит от того, поддерживает ли операционная систе-

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

приоритетами задач.

Запрос 1

Запрос N

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

Процессор

БД

Поток 1

Поток N

Запрос 1

Запрос 2

Запрос N

Серверный

процесс

Серверный

процесс

Процессор

БД

234

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

го параллелизма.

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

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

дена на рис. 8.8.

Рис. 8.8. Архитектура сервера обработки запроса при гибридном парал-

лелизме

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

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

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

работки (OLAP-приложений).

Запрос

Подзапрос 1

Подзапрос 2

Подзапрос N

Серверный

процесс

Серверный

процесс

Процес-

сор

Процес-

сор

Сегмент

БД

Сегмент

БД

235

8.3. Технологии и средства доступа к удаленным БД

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

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

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

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

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

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

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

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

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

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

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

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

кациям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ских приложений.

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

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

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

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

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

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

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

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

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

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

236

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения

Бизнес-

прило-

жения

Средства

разработки

Сетевое

управ-

ление

Систем-

ное

управ-

ление

Готовые программные

пакеты

RPС, MOM, TPM, ORB, COM,

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

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

UNIX VMS NT Macintosh OS/2 WINDOWS Os/400 …

237

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

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

SQL-шлюзы);

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

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

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

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

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

зволяют построить универсальное ПО, реализовав в одном продукте все

необходимые возможности.

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

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

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

ПК, в роли встроенного ПО доступа к данным могут выступать обычные

ODBC-драйверы.

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

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

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

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

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

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

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

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

интерфейса). SQL-шлюз выполняет синтаксический разбор такого за-

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

преобразование в SQL-диалект нужной СУБД. ПО этого типа реализует

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

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

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

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

ствующую информацию из расположенных в различных регионах баз

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

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

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

ных платформ в архитектуру клиент-сервер.

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

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

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

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

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

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

ботки.

238

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.10:

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

доступа

Клиент

Сервер

Прикладная

программа

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

функции

Драйвер СУБД

Драйвер сети

СУБД

Драйвер сети

Сеть

239

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

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

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

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

− соединение с базой данной;

− запрос к базе данных на выполнение SQL-выражения;

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

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

− закрытие соединения с базой данных.

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

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

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

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

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

тевые вызовы и передаются сетевым программным обеспечением на сер-

вер. На сервере происходит обратный процесс преобразования сетевых па-

кетов в SQL-запросы, которые обрабатываются СУБД. Результаты обра-

ботки передаются клиенту.

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

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

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

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

живается библиотека;

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

терфейсов;

− библиотечные функции обычно неунифицированы.

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

"встроенного" языка SQL. В этом случае текст программы на языке третье-

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

венно предложения SQL, которые предваряются выражением "EXEC SQL".

Перед компиляцией в машинный код такая программа обрабатывается пре-

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

СУБД и SQL-предложений в промежуточный "чистый" исходный код, а за-

тем коды SQL замещаются вызовами соответствующих процедур из биб-

лиотек, поддерживающих конкретную СУБД. Такой подход позволяет не-

сколько снизить степень привязанности к СУБД, например, при переклю-

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

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

8.3.2.2. Программный интерфейс уровня вызовов

Стандарт SQL2 определил интерфейс уровня вызова (CLI - Call Level

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

печивающий совместимость со всеми основными типами серверов баз дан-

ных.

240

Технологическая основа CLI – размещаемая на компьютере клиента

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

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

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

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

Использование программных вызовов позволяет свести к минимуму

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

ратор языка SQL в виде строки и пересылает ее на сервер посредством

процедуры исполнения (execute). Когда же сервер в качестве ответа воз-

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

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

полученной таблицы могут быть связаны с соответствующими перемен-

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

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

столбце.

8.3.2.3. Открытый интерфейс доступа к базам данных

Спецификация открытого интерфейса баз данных (ODBC - Open

Database Connectivity), предназначена для унификации доступа к данным,

размещенным на удаленных серверах. ODBC опирается на спецификации

CLI.

Рис.8.11. Структурная схема доступа к данным с использованием

ODBC

ODBC представляет собой программный слой, унифицирующий

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

СУБД 1

Драйвер сети

СУБД 2

Драйвер сети

Сеть

Локальный

диск

Прикладная

программа

ODBС-driver manager

локальный

ODBС-драйвер

СУБД 2

ODBС-драйвер

СУБД 1

Файловая

система

Драйвер сети