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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Схема обработки клиентского запроса, построенная с ис­пользованием обеих моделей параллелизма (гибридная модель), приведена на рис. 7.3.

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

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

В распределенных БД возникают следующие проблемы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процедура обычно хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается опера­тором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) И содержит определения переменных, операторы SQL (например, SELECT, INSERT), операторы проверки условий (if/then/else), операторы цикла (for, while), а также некоторые другие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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