22.2.4. Архитектура «сервер приложений» (слайд 12)

Рассмотренные выше архитектуры являются двухзвенными: здесь все функции доступа и обработки распределены между программой клиента и сервером БД.

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

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

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

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

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

Для приведенных моделей архитектуры на слайде 13 представлена диаграмма распределения ресурсов по обработке логических компонент запросов, включая: ввод и отображение данных (Presentation Logic - PL), функциональную обработку прикладной задачи (Business Logic - BL), общие «бизнес-правила» на уровне данных (Common DB Logic - CDBL), манипулирование данными БД в рамках приложения (Database Logic - DBL), управление ресурсами БД (Resource Logic - RL).

Лекция 23 (db_l23.Ppt). Схемы распределения данных и запросов. Обработка распределенных данных и запросов. Многопотоковые и многосерверные архитектуры. Типы параллелелизма при обработке запросов.

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

Повышение эффективности и оперативности обслуживания большого числа клиентских запросов, помимо простого увеличения ресурсов и вычислительной мощности серверной машины, может быть достигнуто двумя путями (слайд 2):

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

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

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

23.1.1. Архитектура «один к одному» (слайд 3)

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

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

23.1.2. Многопотоковая односерверная архитектура (слайд 4)

Обработку всех клиентских запросов выполняет один серверный процесс (использующий один процессор), взаимодействующий со всеми клиентами и монопольно управляющий ресурсами (рис. 8.6). При этом для отдельного клиентского процесса создается поток, (thread) в рамках которого локализуется обработка запроса.