Многоуровневые модели. 
Распределенные базы данных

Модель сервера приложений

Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Этот промежуточный уровень содержит один или несколько серверов приложений (рис. 9.8).

Рис. 9.8. Модель сервера приложений

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

Модель серверов баз данных

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

Появление сервера для управления данными. Архитектура «один к одному». Один сервер обслуживает одного клиента. Выделение сервера в отдельную программу — революционный шаг, который позволил, в частности, поместить сервер на одну машину, а программный интерфейс с пользователем — на другую, осуществляя взаимодействие между ними по сети. Для обслуживания многих клиентов на сервере должно быть запущено большое количество одновременно работающих серверных процессов.

Проблемы, возникающие в модели «один к одному», решаются в архитектуре «систем с выделенным сервером», который способен обрабатывать запуск от имени клиентов. Логически каждый клиент связан с сервером отдельной нитью (thread), или потоком, по которому передаются запросы. Такая архитектура получила название многопотоковой односерверной (multi-thread). Они позволяют значительно уменьшить нагрузку на ОС.

Рис. 9.10. Модель с выделенным сервером

Возможность взаимодействия с одним сервером многих клиентов позволяет в полной мере использовать разделяемые объекты, что значительно уменьшает потребности в памяти и общее число процессов ОС. Например, системой с архитектурой «один к одному» будет создано 100 копий процессов СУБД для 100 пользователей, а здесь понадобится только один единый процесс.

Недостаток:

Так как сервер может выполняться только на одном процессоре, возникает ограничение на применение СУБД для мультипроцессорных платформ.

В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера («Virtual Server»).

Рис. 9.11. Модель с архитектурой виртуального сервера

Здесь клиенты подключены не к реальному серверу, а к промежуточному звену, называемому диспетчером. В этом случае нет ограничений на использование многопроцессорных платформ.

Недостатки:

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

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

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

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

Например. Имеется последовательность операций.

• 1. R5=R1[A, C]
• 2. R6=R2[A, B, D]
• 3. R7=R5[A>128]
• 4. R8=R5[A] R6

Здесь 1 и 3 операции можно объединить и выполнить параллельно с операцией 2, а затем выполнить над результатом последнюю четвёртую операцию. В моделях «клиент-сервер» большая часть бизнес-логики клиентского приложения выполняется именно на сервере, а не на клиенте. Для этого используются специальные объекты — хранимые процедуры, и хранятся в БД как таблицы. Курсоры делятся на курсоры сервера и курсоры клиента. Курсоры сервера создаются и выполняются на сервере, данные, связанные с ним, не пересылаются на компьютер клиента. Курсоры сервера определяются обычно в хранимых процедурах или триггерах.