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

Эволюция серверов баз данных

В период создания первых СУБД технология «клиент — сер­вер» только зарождалась. Поэтому изначально в архитектуре сис­тем не было адекватного механизма организации взаимодейст­вия такого типа, в современных же системах он жизненно необ­ходим.

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

Проблемы, возникающие в модели «один к одному», реша­ются в архитектуре систем с выделенным сервером, спо­собным обрабатывать запросы от многих клиентов. Сервер обла­дает монополией на управление данными и взаимодействует од-
ш □ □

Ш □ □ Ф

41/ 1

ш □ □ □

\/ \/

ш □

 

Рис. 7.2. Разновидности серверов БД: а — централизованная архитектура; б — архитектура «один к одному»; в — разме­щение клиента и сервера на различных машинах; г — многопотоковая архитектура; д — архитектура с виртуальным сервером; е — многопотоковая мультисерверная ар­хитектура; 1 — клиент; 2 — сервер; 3 — диспетчер; 4 — многопотоковый сервер

Сеть

□ъ □ EEf □ □□ б

новременно со многими клиентами (рис. 7.2, г). Логически каждый клиент связан с сервером отдельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой (multi-threaded). Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользовате­лей. С другой стороны, возможность взаимодействия с одним сервером многих клиентов позволяет в полной степени исполь­зовать разделяемые объекты (начиная с открытых файлов и кон­чая данными из системных каталогов), что сильно уменьшает потребности в памяти и общее число процессов операционной
системы. Например, системой с архитектурой «один к одному» будет создано 50 копий процессов СУБД для 50 пользователей, тогда как системе с многопотоковой архитектурой для этого по­надобится только один сервер.

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

В некоторых системах эта проблема решается заменой выде­ленного сервера на д и с п е тч е р или виртуальный сервер (virtual server) (рис. 7.2. д), который теряет право монопольно распоряжаться данными, выполняя только функции диспетчери­зации запросов к актуальным серверам. Таким образом, в архи­тектуру системы добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки (load balancing) и ограничивает воз­можности управления взаимодействием «клиент — сервер». Во-первых, становится невозможным направить запрос от кон­кретного клиента конкретному серверу, во-вторых, серверы ста­новятся равноправными — невозможно устанавливать приорите­ты для обслуживания запросов.

Современное решение проблемы СУБД для мультипроцес­сорных платформ заключается в возможности запуска несколь­ких серверов базы данных, в том числе и на различных процес­сорах. При этом каждый из серверов должен быть многопотоко­вым. Если два эти условия выполнены, то есть основание говорить о многопотоковой архитектуре с несколь­кими серверами (multi-threaded, multi-server architecture), представленной на рис. 7.2, е.

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

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

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

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

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

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

• однопотоковые архитектуры — «один к одному», когда для обслуживания каждого запроса запускается отдельный сер­верный процесс. В этом случае, даже если от клиентов по­ступят совершенно одинаковые запросы, для обработки ка­ждого из них будет запущен отдельный процесс, каждый из которых будет выполнять одинаковые действия и исполь­зовать одни и те же ресурсы;

• многопотоковые архитектуры, когда обработку всех запро­сов выполняет один серверный процесс (использующий один процессор), взаимодействующий со всеми клиентами и монопольно управляющий ресурсами. Либо в том случае, когда для работы СУБД используются многопроцессорные платформы, обслуживание запросов может быть физически распределено для параллельной обработки между процес­сорами.

В общем случае для повышения оперативности за счет рас­параллеливания процесса обработки отдельного клиентского за­проса в мультисерверной архитектуре можно использовать сле­дующие подходы:

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

• запрос обрабатывается по конвейерной технологии. Для этого запрос разбивается на взаимосвязанные по результа­там подзапросы, каждый из которых может быть обслужен отдельным серверным процессом независимо от обработки других подзапросов. Получаемые результаты объединяются согласно схеме декомпозиции запроса и передаются клиен­ту. Такой тип распараллеливания называют моделью верти­кального параллелизма. Схема обработки клиентского запроса, построенная с ис­пользованием обеих моделей параллелизма (гибридная модель), приведена на рис. 7.3.

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

 

Отдельно необходимо упомянуть «интеграционный» под­ход — использование мулыпибазовой СУБД, которая размешается над существующими системами баз данных и файловыми систе­мами и позволяет пользователям рассматривать совокупность баз данных (и, возможно, под управлением разнотипных СУБД) как единую базу. Мультибазовая СУБД поддерживает глобаль­ную схему, на основании которой пользователи могут формиро­вать запросы и модифицировать данные. Мультибазовая СУБД работает только с глобальной схемой, тогда как локальные СУБД могут использовать собственные схемы представления и обработки «своих» данных.

Активный сервер

В распределенных БД возникают следующие проблемы: • база данных в любой момент времени должна правильно отражать состояние предметной области — дан­ные должны быть взаимно непротиворечивыми. Пусть, например, база данных Кадры хранит сведения о рядовых

сотрудниках, отделах, в которых они работают, и их руко­водителях. Нужно учесть следующие правила: каждый со­трудник должен быть подчинен реальному руководителю; если руководитель уволился, то все его сотрудники пере­ходят в подчинение другому, а отдел реорганизуется; во главе каждого отдела должен стоять реальный руководи­тель; если отдел сокращен, то его руководитель перево­дится в резерв на выдвижение и т. д.;

• база данных должна отражать некоторые правила предметной области, законы, по которым она функ­ционирует (business rules). Завод может нормально работать только в том случае, если на складе имеется достаточный запас деталей определенной номенклатуры. Следовательно, как только количество деталей некоторого типа станет меньше минимально допустимого, завод должен докупить их в нужном количестве;

• необходим постоянный контроль за состоянием базы данных, отслеживание всех изменений и адекват­ная реакция на них. Например, в автоматизированной сис­теме управления производством датчики контролируют температуру инструмента; она периодически передается в базу данных и там сохраняется; как только температура ин­струмента превышает максимально допустимое значение, он отключается;

• необходимо, чтобы возникновение некоторой ситуа­ции в базе данных четко и оперативно влияло на ход выполнения прикладной программы. Многие про­граммы требуют оперативного оповещения обо всех про­исходящих в базе данных изменениях. Так, в системах ав­томатизированного управления производством необходимо моментально уведомлять программы о любых изменениях параметров технологических процессов, когда последние хранятся в базе данных. Почтовая служба требует опера­тивного уведомления получателя, как только получено но­вое сообщение;

• важная функция — контроль типов данных. В базе данных каждый столбец в любой таблице содержит данные некоторых типов. Тип данных определяется при создании таблицы. Каждому столбцу присваивается один из стан­дартных типов данных, разрешенных в СУБД.

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

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

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

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

Процедуры базы данных. В различных СУБД они носят назва­ние хранимых (stored), присоединенных, разделяемых и т. д. Ниже используется терминология, принятая в СУБД Ingres.

Использование процедур базы данных преследует четыре цели:

• обеспечивается новый независимый уровень центра­лизованного контроля доступа к данным, осущест­вляемый администратором базы данных;

• одна и та же процедура может использоваться несколькими прикладными программами — это позволяет существенно сократить время написания программ за счет оформления их общих частей в виде про­цедур базы данных. Процедура компилируется и помеща­ется в базу данных, становясь доступной для многократ­ных вызовов. Так как план ее выполнения определяется единожды при компиляции, то при последующих вызовах процедуры фаза оптимизации пропускается, что сущест­венно экономит вычислительные ресурсы системы;

• значительное снижение трафика сети в системах с архитектурой «клиент — сервер». Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры. В процедуре, как правило, концентрируются повторяющиеся фрагменты из нескольких прикладных программ (рис. 7.4). Если бы эти фрагменты остались ча­стью программы, они загружали бы сеть посылкой полных SQL-запросов;

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

Процедура обычно хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается опера­тором create procedure (создать процедуру) и содержит оп­ределения переменных, операторы SQL (например, select, insert), операторы проверки условий (if/then/else), опера­торы цикла (for, while), а также некоторые другие.

Рис. 7.4. Увеличение производительности за счет использования процедур баз данных: а — процедуры не используются: б — выделение фрагмента прикладных про­грамм в виде процедуры БД

 

Пусть, например, необходимо разработать процедуру, кото­рая переводила бы рядового сотрудника в резерв на выдвижение на руководящую должность. Процедура Назначение перемещает строки из таблицы Сотрудник, которая содержит сведения о со­трудниках, в таблицу Резерв для всех сотрудников с указанным номером. Номер сотрудника представляет собой целое число (тип integer), который не может иметь пустое значение, явля­ется параметром процедуры и передается ей при вызове из при­кладной программы оператором execute procedure (выпол­нить процедуру):

CREATE PROCEDURE Назначение

(Номер сотрудника integer not nul)

AS

BEGIN

INSERT INTO Резерв

SELECT *

FROM Сотрудник

WHERE Номер = Номер_сотрудника;

DELETE

FROM Сотрудник

WHERE Номер = Номер сотрудника;

END.

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

Правило придается таблице базы данных и применяется при выполнении над таблицей операций включения, удаления или обновления строк.

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

Это требование может быть описано правилом Прове- рить_деталь. Оно применяется в случае обновления столбца Количество таблицы Деталь: если новое значение в столбце меньше 1000, то выполняется процедура Заказать_деталь. В качестве параметров ей передаются номер детали данного типа и остаток (число детатей на складе):

CREATE RULE ПроЕерить_деталь

AFTER UPDATE (Количество) OF деталь

WHERE Деталь.Количество < 1000

EXECUTE PROCEDURE Заказать_деталь

(Номер детали = Деталь.Номер,

Остаток - Деталь.Количество).

Таким образом, если возникает ситуация, когда на складе количество деталей какого-либо типа становиться меньше тре­буемого, запускается процедура базы данных, которая заказыва­ет недостающее количество деталей этого типа. Заказ сводится к посылке письма (например, по электронной почте), на завод или в цех, который изготавливает данные детали. Все это проис­ходит автоматически, без вмешательства пользователя.

Важнейшая цель механизма правил — обеспечение целост­ности базы данных. Один из аспектов целостности — целост­ность по ссылкам (referential integrity) — относится к связи двух таблиц между собой.

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

Руководитель.

Для обеспечения целостности ссылок должны быть учтены два требования. Во-первых, если в таблицу Сотрудник добавля­ется новая строка, значение столбца номер руководителя должно быть взято ИЗ множества значений столбца Номер таблицы Ру­ководитель (сотрудник может быть подчинен только реальному руководителю). Во-вторых, при удалении любой строки из таб­лицы Руководитель В таблице Сотрудник не ДОЛЖНО остаться ни одной строки, в которой в столбце Номер_руководителя было бы значение, тождественное значению столбца Номер в удаляемой строке (все сотрудники, если их руководитель уволил­ся, должны перейти в подчинение другому).

Для того чтобы учесть эти требования, должны быть созданы правила, их реализующие. Первое правило Добавить_сотруд- ника срабатывает при включении строки в таблицу Сотрудник; его применение заключается в вызове процедуры Прове- рить_руководителей, устанавливающей, существует ли среди множества значений столбца Номер таблицы Руководитель зна­чение, тождественное значению поля Номер_руководителя до­бавляемой строки. Если это не так, процедура должна ее отверг­нуть. Второе правило применяется при попытке удалить строку из таблицы Руководитель; оно состоит в вызове процедуры, ко­торая сравнивает значения в столбце Номер_рукозодителя таб­лицы Сотрудник со значением поля Номер в удаляемой строке. В случае совпадения значение в столбце Номер_руководителя обновляется.

CREATE RULE Добавить_сструдника

AFTER INSERT INTO Сотрудник

EXECUTE PROCEDURE

Проверить_руксводителя

(Номер = Сотрудник.Номер_руксводктеля).

Механизм правил позволяет реализовать и более общие огра­ничения целостности. Пусть, например, таблица Сотрудник со­держит информацию о сотрудниках, в том числе имя и название отдела, в котором они работают. Таблица Отдел хранит для каж­дого отдела количество работающих в нем сотрудников в столб­це Количество__сотруднихоз. Одно из ограничений целостно­сти заключается в том, что это количество должно совпадать с числом строк для данного отдела в таблице Сотрудник. Чтобы учесть это ограничение, можно использовать правило Доба­вить сотрудника, которое применяется при включении строки в таблицу Сотрудник и запускает процедуру нозый_сотрудник. Она, в свою очередь, обновляет значение столбца количест­во сотрудников, увеличивая его на единицу. Параметр проце­дуры — название отдела.

CREATE RULE

AFTER INSERT JNTO Сотрудник

EXECUTE PROCEDURE Нсвь:й_сотрудШк

(Отдел = Сотрудник.Отдел).

Разумеется, на практике с помощью механизма правил реализуются более сложные и изощренные ограничения цело­стности.

Аналогом правил послужили триггеры (triggers), которые впервые появились в СУБД Sybase и впоследствии были реали­зованы в том или ином виде и под тем или иным названием в большинстве многопользовательских СУБД.

События в базе данных. Механизм событий в базе данных (database events) позволяет прикладным программам и серверу базы данных уведомлять другие программы о наступлении в базе данных определенного события и тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление, часто называют сигнализаторами событий в базе данных (database event alerters). Функции управления событиями цели­ком ложатся на сервер базы данных.

Рисунок 7.5 иллюстрирует один из примеров использования механизма событий: различные прикладные программы и проце­дуры вызывают события в базе данных, а сервер оповещает мо­нитор прикладных программ об их наступлении. Реакция мони­тора на события заключается в выполнении действий, которые предусмотрел его разработчик.

Механизм событий используется следующим образом. Вна­чале в базе данных для каждого события создается флажок, со­стояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор create dbevent - создать событие). Далее, во все прикладные про­граммы, на ход выполнения которых может повлиять это собы-

Сервер DBMS

 

Уведомление о событии

Программа

Рис. 7.5. События в базе данных

тие, включается оператор register dbevent (зарегистриро­вать событие), который оповещает сервер базы данных, что программа заинтересована в получении сообщения о наступле­нии события. Теперь любая прикладная программа или процеду­ра базы данных может вызвать событие оператором raise dbevent (вызвать событие). Как только событие произошло, каждая зарегистрированная программа может получить его, для чего она должна запросить очередное сообщение из очереди со­бытий (оператор get dbevent — получить событие) и запро­сить информацию о событии, в частности его имя (оператор SQL inquire_sql).

Следующий пример иллюстрирует обработку всех событий из очереди:

loop

EXEC SQL GET DBEVENT;

EXEC SQL INQUIRE_SQL (:event_name =

DBEVENTNAME);

if (event_name = 'event_l')

обработать событие event_i

else if (event_name = 'event_2') обработать событие ever.t_2 else

endif

until fevent_narr.e = ' '.

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

Создается правило, которое применяется всякий раз, когда новое значение температуры инструмента заносится в таблицу Инструмент. Как только оно превосходит 500 градусов, правило вызывает процедуру Отключить_кнструмент.

CREATE RULE Перегрев_:-:-:струмента AFTER UPDATE OF Инструмент (Температура)

WHERE Новое.Температура >= 5С0 EXECUTE PROCEDURE ОтключиЦЩ инструмент (Номер инструмента = Инструмент.Номер);

Создается процедура базы данных ®£ключить_инструмент, которая вызывает событие Перегрев; она будет выполнена в ре­зультате применения правила, определенного на шаге 1.

CREATE PROCEDURE Отключхть^инструмент (Номер_инструмента) AS BEGIN

UPDATE Инструмент

SET Статус = 'ЗЫКЛ'

WHERE Номер = Номер_у:нструмента;

RAISE D3EVENT Перегрев;

END;

Создается событие Перегрев, которое будет вызвано, когда инструмент перегреется:

CREATE DBEVENT Перегрев;

Наконец, создается прикладная программа Монитор^Инст- рументов, которая следит за состоянием инструментов. Она ре­гистрируется сервером в качестве получателя события Перегрев с помощью оператора register dbevent. Если событие про­изошло, программа посылает сообщение пользователю и сигнал, необходимый для отключения инструмента:

EXEC SQL REGISTER DBEVENT Перегрев;

EXEC SQL GET DBEVENT;

EXEC SQL INQUIRE_SQL (Имя события =

DBEVENTNAME,...);

if (Имя события = 'Перегрев') then послать сообщение; отключить инструмент; endif.

Описанные выше конструкции в совокупности определяют логику работы (рис. 7.6).

Инструмент, код 3114 Рис. 7.6. Пример использования механизма событий в базе данных

 

Прикладная программа Монитор_Инструментов периодиче­ски регистрирует с помощью датчиков текущие значения пара­метров множества различных инструментов и заносит в табли­цу Инструмент новое значение температуры для данного инст­румента.

Всякий раз, когда это происходит, т. е. обновляется значение в столбце Температура таблицы Инструмент, применяется пра­вило Перегрев инструмента.

Применение правила состоит в проверке нового значения температуры. Если оно превышает максимально допустимое, то запускается процедура Отключить_кнструмент.

В том случае, когда используются традиционные методы оп­роса БД, логика работы была бы совершенно иной. Пришлось бы разработать дополнительную программу, которая периодиче­ски выполняла бы операцию выборки из таблицы Инструмент по критерию Температура > 5 0 0. Это очень сильно сказалось бы на эффективности, поскольку операция SELECT является ре­сурсоемкой. Разумеется, пример приведен лишь для иллюстра­ции схемы срабатывания механизма «правило — процедура — событие».