2.4.3. Архитектура сервера бд

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

Модели (поколения) распределения функций между клиентом и сервером:

1. Совмещение клиентских и серверных функций в одной программе (FS-модель).

2. Разделение клиентских и серверных функций на два отдельных модуля с сохранением связи «один-к-одному». Запросы каждого клиентского приложения обслуживал один сервер, специально выделенный для этого приложения. Этот шаг позволил физически разделить клиент и сервер.

3. Архитектура выделенного многопотокового (multi-threaded) сервера. Результатом является снижение ресурсных требований сервера. Проблемой первых многопотоковых серверов была неспособность функционировать на нескольких процессорных ядрах. Для решения этой проблемы были применены следующие модели.

4. Модель виртуального сервера (диспетчера). Серверная часть делится на функциональные серверы, выполняющие функции управления данными, и диспетчер. Количество функциональных серверов равно количеству процессорных ядер. Диспетчер перенаправляет запросы между клиентами и серверами.

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

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

Концепция активного сервера направлена на решение следующих проблем:

• поддержка целостности данных и логики предметной области;

• мониторинг и контроль данных.

Концепция активного сервера опирается на следующие принципы:

• процедуры базы данных;

• правила (триггеры);

• события в базе данных.

Процедуры БД (stored procedures – хранимые процедуры, также присоединенные, разделяемые процедуры). Цели использования хранимых процедур:

• концентрация бизнес-логики;

• повторное использование кода процедур;

• снижение трафика сети;

• поддержка целостности БД.

Механизм правил позволяет однотипно обрабатывать определенные стандартные ситуации в БД (добавление, удаление, изменение записи).

Механизм событий БД (database events) позволяет серверу БД уведомлять другие программы о наступлении в БД определенных ситуаций. Операторы SQL, обеспечивающие уведомление, называют сигнализаторами событий БД (database event alerters). Каждая программа, зарегистрировавшаяся в SQL-сервере как слушатель событий, может опрашивать состояние событий и узнавать об их фиксации. Наступление события может быть установлено в результате некоторой операции с данными, например, в результате вставки в таблицу записи с определенным значением наблюдаемой величины.

В отсутствие механизма событий фиксация ситуаций выполнялась бы путем обращения клиентского ПО к БД для формирования выборок.