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

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

Первое время доминировала модель, в которой управление данными (функция сервера) и взаимодействие с пользователем были совмещены в одной программе (рис. 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.

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