Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (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. Взаимодействие пользовательских и клиентских процессов в модели «один-к-одному»
Создание базы данных строительной организации
... базы данных; по способу организации хранения данных и выполнения функций обработки базы данных – централизованные и распределенные. Системы централизованных баз данных с сетевым доступом предполагают две основные архитектуры – файл-сервер или клиент-сервер. Архитектура файл-сервер. ... управления базами данных MicrosoftAccess и Oracle. Этапами работы в СУБД являются: создание структуры базы данных, ...
Выделение сервера в отдельную программу было революционным шагом, который позволил, в частности, поместить сервер на одну машину, а программный интерфейс с пользователем — на другую, осуществляя взаимодействие между ними по сети. Однако необходимость запуска большого числа серверов для обслуживания множества пользователей сильно ограничивала возможности такой системы.
Для обслуживания большого числа клиентов на сервере должно быть запущено большое количество одновременно работающих серверных процессов, а это резко повышало требования к ресурсам ЭВМ, на которой запускались все серверные процессы. Кроме того, каждый серверный процесс в этой модели запускался как независимый, поэтому если один клиент сформировал запрос, который был только что выполнен другим серверным процессом для другого клиента, то запрос тем не менее выполнялся повторно. В такой модели весьма сложно обеспечить взаимодействие серверных процессов. Эта модель самая простая, и исторически она появилась первой.
Проблемы, возникающие в модели «один-к-одному», решаются в архитектуре «систем с выделенным сервером», который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами (рис 7).
Логически каждый клиент связан с сервером отдельной нитью («thread»), или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой односерверной («multi-threaded»).
Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей («trashing»).
Рис. 7. Многопотоковая односерверная архитектура Кроме того, возможность взаимодействия с одним сервером многих клиентов позволяет в полной мере использовать разделяемые объекты (начиная с открытых файлов и кончая данными из системных каталогов), что значительно уменьшает потребности в памяти и общее число процессов операционной системы. Например, системой с архитектурой «один-к-одному» будет создано 100 копий процессов СУБД для 100 пользователей, тогда как системе с многопотоковой архитектурой для этого понадобится только один серверный процесс.
Однако такое решение имеет свои недостатки. Так как сервер может выполняться только на одном процессоре, возникает естественное ограничение на применение СУБД для мультипроцессорных платформ. Если компьютер имеет, например, четыре процессора, то СУБД с одним сервером используют только один из них, не загружая оставшиеся три.
В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера («virtual server») (рис. 8).
Рис. 8. Архитектура с виртуальным сервером В этой архитектуре клиенты подключаются не к реальному серверу, а к промежуточному звену, называемому диспетчером, который выполняет только функции диспетчеризации запросов к актуальным серверам. В этом случае нет ограничений на использование многопроцессорных платформ. Количество актуальных серверов может быть согласовано с количеством процессоров в системе.
Реферат настройка веб сервера апачи
... выполнения какой-либо сервисной задачи без непосредственного участия человека. Веб-сервер Apache может быть установлен на любой сервер. ... веб-сервер -- служба WWW, которая предоставляет клиентам доступ к сайтам по протоколам HTTP и, если произведена настройка, HTTPS. Один сервер ... авторизацию через СУБД или PAM. 1.2.2 Веб-сервер Internet Information Services(IIS) IIS -- проприетарный набор серверов для ...
Однако и эта архитектура не лишена недостатков, потому что здесь в систему добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки актуальных серверов («load balancing») и ограничивает возможности управления взаимодействием «клиент-сервер». Во-первых, становится невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы становятся равноправными — нет возможности устанавливать приоритеты для обслуживания запросов.
Подобная организация взаимодействия клиент-сервер может рассматриваться как аналог банка, где имеется несколько окон кассиров, и специальный банковский служащий — администратор зала (диспетчер) направляет каждого вновь пришедшего посетителя (клиента) к свободному кассиру (актуальному серверу).
Система работает нормально, пока все посетители равноправны (имеют равные приоритеты), однако стоит лишь появиться посетителям с высшим приоритетом, которые должны обслуживаться в специальном окне, как возникают проблемы. Учет приоритета клиентов особенно важен в системах оперативной обработки транзакций, однако именно эту возможность не может предоставить архитектура систем с диспетчеризацией.
Современное решение проблемы СУБД для мультипроцессорных платформ заключается в возможности запуска нескольких серверов базы данных, в том числе и на различных процессорах. При этом каждый из серверов должен быть многопотоковым. Если эти два условия выполнены, то есть основания говорить о многопотоковой архитектуре с несколькими серверами, представленной на рис. 9.
Рис. 9. Многопотоковая мультисерверная архитектура Она также может быть названа многонитевой мультисерверной архитектурой. Эта архитектура связана с вопросами распараллеливания выполнения одного пользовательского запроса несколькими серверными процессами.
Существует несколько возможностей распараллеливания выполнения запроса. В этом случае пользовательский запрос разбивается на ряд подзапросов, которые могут выполняться параллельно, а результаты их выполнения потом объединяются в общий результат выполнения запроса. Тогда для обеспечения оперативности выполнения запросов их подзапросы могут быть направлены отдельным серверным процессам, а потом полученные результаты объединены в общий результат. В данном случае серверные процессы не являются независимыми процессами, такими, как рассматривались ранее. Эти серверные процессы принято называть нитями (treads), и управление нитями множества запросов пользователей требует дополнительных расходов от СУБД, однако при оперативной обработке информации в хранилищах данных такой подход наиболее перспективен. [5, 6, 8]
Заключение
Развитие информационных и телекоммуникационных технологий обусловило исследование и разработку единых информационных сред в рамках различных сфер деятельности человека. В основе единых информационных сред лежат системы распределенных технологий обработки и хранения данных. Система распределенных технологий обработки и хранения данных, являясь совокупностью независимых компьютеров, представляется пользователю единым компьютером. Создание систем распределенных технологий обработки данных имеют следующие преимущества перед централизованными технологиями:
Проектирование и реализация хранилища данных для анализа бизнес ...
... поэтому компаниям требуется организовать работу с информацией наилучшим образом. Поэтому возникла необходимость в создании специализированных систем хранения данных и дополнительных средств анализа поступающей информации. Система хранения данных состоит из набора программного ...
1) Экономическое: закон Гроша (Herb Grosh) — быстродействие процессора пропорциональна квадрату его стоимости. С появлением микропроцессоров закон перестал действовать — за двойную цену можно получить тот же процессор с несколько большей частотой.
2) Можно достичь такой высокой производительности путем объединения микропроцессоров, которая недостижима в централизованном компьютере.
3) Естественная распределенность: банк, поддержка совместной работы группы пользователей.
4) Надежность: выход из строя нескольких узлов незначительно снизит производительность (https:// , 7).
5) Наращиваемость производительности. В будущем главной причиной будет наличие огромного количества персональных компьютеров и необходимость совместной работы без ощущения неудобства от географического и физического распределения людей, данных и машин.
Развитие распределенных технологий обработки и хранения данных позволит:
- разделять данные и дорогие периферийные устройства, уникальные информационные и программные ресурсы;
- достичь развитых коммуникаций между людьми;
- гибче использовать различные ЭВМ, распределять нагрузки на них.
Список литературы
[Электронный ресурс]//URL: https://drprom.ru/referat/raspredelennyie-tehnologii-hraneniya-i-obrabotki-dannyih/
В. П. Базы
Форум Инфра-М, 2009. 272 с.
Избачков Ю. С.
Кузин Б. И.
Н., Кузина Б. И.) Изд. 2-е, перераб., доп. — СПбГПУ, 2005 г., 224 с.
Партыка Т. Л.
Дейт К. Дж.
Введение
в системы баз данных. 8-е издание. — М.: Издательский дом «Вильяме», 2006. 1328 с.
С. М. Базы
В. К. Теоретические
Т. С. Базы
Громов Г. Ю.
Введение
в реляционные базы данных (+CD).
— СПб.: БХВ-Петербург, 2009. с 464
Крёнке Д. Теория и практика построения баз данных. 8-е изд. — СПб.: Питер, 2003. 800 с.
С. В. Базы
пособие для студ. вузов. 2-е изд., стер. — М. Издательский цент «Академия», 2008. 320 с.
С. Д. Основы, Цыганов А. А.
М. П. Базы
К. Ю. Базы
Введение
в теорию и методологию: учебник. — М.: Финансы и статистика, 2006. 512 с.
В. Ю. Информационные, В. Ю. Информационные
Попов И., Максимов Н., Голицына О. Информационные системы — Форум, Инфра-М, 2007 г., 496 с.
Цыганков В. М.
Клиент
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
