Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application).
Трехуровневая модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных, которые относятся к области OLAP-приложений. (On-line analytical processing.) В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования, таких как С, C++, SmallTalk, Cobol. Это повышает переносимость системы, ее масштабируемость.
Функции промежуточных серверов могут быть в этой модели распределены в рамках глобальных транзакций путем поддержки ХА-протокола (X/Open transaction interface protocol), который поддерживается большинством поставщиков СУБД. [5, 8, 11, 15]
2.
5. Модели серверов баз данных В период создания первых СУБД технология «клиент-сервер» только зарождалась. Поэтому изначально в архитектуре систем не было адекватного механизма организации взаимодействия процессов типа «клиент» и процессов типа «сервер». В современных же СУБД он является фактически основополагающим и от эффективности его реализации зависит эффективность работы системы в целом.
Рассмотрим эволюцию типов организации подобных механизмов. В основном этот механизм определяется структурой реализации серверных процессов, и часто он называется архитектурой сервера баз данных.
Первоначально существовала модель, когда управление данными (функция сервера) и взаимодействие с пользователем были совмещены в одной программе. Это можно назвать нулевым этапом развития серверов БД.
Затем функции управления данными были выделены в самостоятельную группу — сервер, однако модель взаимодействия пользователя с сервером соответствовала парадигме «один-к-одному» (рис 6), то есть сервер обслуживал запросы только одного пользователя (клиента), и для обслуживания нескольких клиентов нужно было запустить эквивалентное число серверов.
Рис. 6. Взаимодействие пользовательских и клиентских процессов в модели «один-к-одному»
Выделение сервера в отдельную программу было революционным шагом, который позволил, в частности, поместить сервер на одну машину, а программный интерфейс с пользователем — на другую, осуществляя взаимодействие между ними по сети. Однако необходимость запуска большого числа серверов для обслуживания множества пользователей сильно ограничивала возможности такой системы.
Для обслуживания большого числа клиентов на сервере должно быть запущено большое количество одновременно работающих серверных процессов, а это резко повышало требования к ресурсам ЭВМ, на которой запускались все серверные процессы. Кроме того, каждый серверный процесс в этой модели запускался как независимый, поэтому если один клиент сформировал запрос, который был только что выполнен другим серверным процессом для другого клиента, то запрос тем не менее выполнялся повторно. В такой модели весьма сложно обеспечить взаимодействие серверных процессов. Эта модель самая простая, и исторически она появилась первой.
Проблемы, возникающие в модели «один-к-одному», решаются в архитектуре «систем с выделенным сервером», который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами (рис 7). Логически каждый клиент связан с сервером отдельной нитью («thread»), или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой односерверной («multi-threaded»).
Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей («trashing»).
Рис. 7. Многопотоковая односерверная архитектура Кроме того, возможность взаимодействия с одним сервером многих клиентов позволяет в полной мере использовать разделяемые объекты (начиная с открытых файлов и кончая данными из системных каталогов), что значительно уменьшает потребности в памяти и общее число процессов операционной системы. Например, системой с архитектурой «один-к-одному» будет создано 100 копий процессов СУБД для 100 пользователей, тогда как системе с многопотоковой архитектурой для этого понадобится только один серверный процесс.
Однако такое решение имеет свои недостатки. Так как сервер может выполняться только на одном процессоре, возникает естественное ограничение на применение СУБД для мультипроцессорных платформ. Если компьютер имеет, например, четыре процессора, то СУБД с одним сервером используют только один из них, не загружая оставшиеся три.
В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера («virtual server») (рис. 8).
Рис. 8. Архитектура с виртуальным сервером В этой архитектуре клиенты подключаются не к реальному серверу, а к промежуточному звену, называемому диспетчером, который выполняет только функции диспетчеризации запросов к актуальным серверам. В этом случае нет ограничений на использование многопроцессорных платформ. Количество актуальных серверов может быть согласовано с количеством процессоров в системе.
Однако и эта архитектура не лишена недостатков, потому что здесь в систему добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки актуальных серверов («load balancing») и ограничивает возможности управления взаимодействием «клиент-сервер». Во-первых, становится невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы становятся равноправными — нет возможности устанавливать приоритеты для обслуживания запросов.
Подобная организация взаимодействия клиент-сервер может рассматриваться как аналог банка, где имеется несколько окон кассиров, и специальный банковский служащий — администратор зала (диспетчер) направляет каждого вновь пришедшего посетителя (клиента) к свободному кассиру (актуальному серверу). Система работает нормально, пока все посетители равноправны (имеют равные приоритеты), однако стоит лишь появиться посетителям с высшим приоритетом, которые должны обслуживаться в специальном окне, как возникают проблемы. Учет приоритета клиентов особенно важен в системах оперативной обработки транзакций, однако именно эту возможность не может предоставить архитектура систем с диспетчеризацией.
Современное решение проблемы СУБД для мультипроцессорных платформ заключается в возможности запуска нескольких серверов базы данных, в том числе и на различных процессорах. При этом каждый из серверов должен быть многопотоковым. Если эти два условия выполнены, то есть основания говорить о многопотоковой архитектуре с несколькими серверами, представленной на рис. 9.
Рис. 9. Многопотоковая мультисерверная архитектура Она также может быть названа многонитевой мультисерверной архитектурой. Эта архитектура связана с вопросами распараллеливания выполнения одного пользовательского запроса несколькими серверными процессами.
Существует несколько возможностей распараллеливания выполнения запроса. В этом случае пользовательский запрос разбивается на ряд подзапросов, которые могут выполняться параллельно, а результаты их выполнения потом объединяются в общий результат выполнения запроса. Тогда для обеспечения оперативности выполнения запросов их подзапросы могут быть направлены отдельным серверным процессам, а потом полученные результаты объединены в общий результат. В данном случае серверные процессы не являются независимыми процессами, такими, как рассматривались ранее. Эти серверные процессы принято называть нитями (treads), и управление нитями множества запросов пользователей требует дополнительных расходов от СУБД, однако при оперативной обработке информации в хранилищах данных такой подход наиболее перспективен. [5, 6, 8]
Заключение
Развитие информационных и телекоммуникационных технологий обусловило исследование и разработку единых информационных сред в рамках различных сфер деятельности человека. В основе единых информационных сред лежат системы распределенных технологий обработки и хранения данных. Система распределенных технологий обработки и хранения данных, являясь совокупностью независимых компьютеров, представляется пользователю единым компьютером. Создание систем распределенных технологий обработки данных имеют следующие преимущества перед централизованными технологиями:
1) Экономическое: закон Гроша (Herb Grosh) — быстродействие процессора пропорциональна квадрату его стоимости. С появлением микропроцессоров закон перестал действовать — за двойную цену можно получить тот же процессор с несколько большей частотой.
2) Можно достичь такой высокой производительности путем объединения микропроцессоров, которая недостижима в централизованном компьютере.
3) Естественная распределенность: банк, поддержка совместной работы группы пользователей.
4) Надежность: выход из строя нескольких узлов незначительно снизит производительность.
5) Наращиваемость производительности. В будущем главной причиной будет наличие огромного количества персональных компьютеров и необходимость совместной работы без ощущения неудобства от географического и физического распределения людей, данных и машин.
Развитие распределенных технологий обработки и хранения данных позволит:
разделять данные и дорогие периферийные устройства, уникальные информационные и программные ресурсы;
достичь развитых коммуникаций между людьми;
гибче использовать различные ЭВМ, распределять нагрузки на них.
Список литературы
Агальцов В. П. Базы данных. В 2-х т., т. 2. Распределенные и удаленные базы данных. 1-e изд. -
Форум Инфра-М, 2009. 272 с.
Васильев А. А., Избачков Ю. С., Петров В. Н., Телина И. С. Информационные системы — Питер, 2011, 544 с.
Волкова В. Н., Кузин Б. И., Барабанова И. М. Информационные системы: Учебное пособие для вузов (под ред. Волковой В.
Н., Кузина Б. И.) Изд. 2-е, перераб., доп. — СПбГПУ, 2005 г., 224 с.
Голицына О. Л., Партыка Т. Л., Попов И. И. Системы управления базами данных — Форум, Инфра-М, 2011 г., 432 с.
Дейт К. Дж.
Введение
в системы баз данных. 8-е издание. — М.: Издательский дом «Вильяме», 2006. 1328 с.
Диго С. М. Базы данных: проектирование и использование: учебник — М.: Финансы и статистика, 2005. 592 с.
Душин В. К. Теоретические основы информационных процессов и систем. Учебник. 4-е изд. — Дашков и К, 2011 г., 348 с.
Карпова, Т. С. Базы данных: Модели, разработка, реализация -СПб.: Питер, 2002. — 303 c.
Кириллов В. В., Громов Г. Ю.
Введение
в реляционные базы данных (+CD). — СПб.: БХВ-Петербург, 2009. с 464
Крёнке Д. Теория и практика построения баз данных. 8-е изд. — СПб.: Питер, 2003. 800 с.
Кузин А. В., Левонисова С. В. Базы данных: учеб.
пособие для студ. вузов. 2-е изд., стер. — М. Издательский цент «Академия», 2008. 320 с.
Кузнецов С. Д. Основы баз данных: учебное пособие. 2-е изд., испр. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. 484 с.
Кузовкин А. В., Цыганов А. А., Щукин Б. А. Управление данными — Академия, 2010 г., 256 с.
Малыхина М. П. Базы данных: основы, проектирование, использование: учеб. пособие для студ. Вузов. 2-е изд. — СПб.: БХВ-Петербург, 2007. 528 с.
Марков А. С., Лисовский К. Ю. Базы данных.
Введение
в теорию и методологию: учебник. — М.: Финансы и статистика, 2006. 512 с.
Пирогов В. Ю. Информационные системы и базы данных. Организация и проектирование — БХВ-Петербург, 2009 г., 528 с.
Пирогов В. Ю. Информационные системы и базы данных: организация и проектирование: учебное пособие. — Спб.: БХВ-Петербург, 2009. 528 с.
Попов И., Максимов Н., Голицына О. Информационные системы — Форум, Инфра-М, 2007 г., 496 с.
Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: учебник для высших учебных заведений. 6-е издание. — КОРОНА-Век, 2010. 736 c.
Клиент
Presentation Logic
DatabaseLogic
BusinessLogic
Database Manager System
DatabaseLogic
БД
Сервер
Сервер
БД
СУФ
DatabaseLogic
Связующие функции
BusinessLogic
Presentation Logic
Клиент
СУБД
База метаданных
Файловые команды
Блоки данных
SQL-запрос
БМД
Database Logic
Сервер
БД
СУБД
Результат запрос
Связующие функции
BusinessLogic
Presentation Logic
Клиент
Результаты для вывода
Хранимые процедуры
Обработка общих сообщений (триггеры)
БМД
Вызов хранимых процедур
Сервер
БД
СУБД
Связующие функции
Presentation Logic
Клиент
Хранимые процедуры
Триггеры
Результаты для вывода
Сервер БД
Хранимые процедуры
Bisiness Logic
Запуск процедур
Сервер приложений
БД
Database Logic
Связующие функции
Presentation Logic
Клиент
1 / 0
Клиент N
Серверный процесс
Серверный процесс
БД
CPU
Клиент 1
1 / 0
Клиент N
Нить 1
Серверный процесс
БД
CPU
Клиент 1
Нить 2
Нить N
Клиент 2
Клиент 2
Клиент N
Клиент 1
Диспетчер
Клиент 1
1 / 0
Клиент 4
Серверный процесс 1
БД
CPU
1 / 0
CPU
Серверный процесс 2
Клиент 3
Серверный процесс 3
Серверный процесс 2
Клиент 2
CPU
Серверный процесс 1
БД
CPU
CPU
Клиент 6
Клиент 5
