Тема: «Модели серверов баз данных» icon

Тема: «Модели серверов баз данных»


Скачать 14.17 Kb.
НазваниеТема: «Модели серверов баз данных»
Размер14.17 Kb.
ТипДокументы

Тема: «Модели серверов баз данных»

В период создания первых СУБД технология "клиент-сервер" только зарождалась. Поэтому изначально в архитектуре систем не было адекватного механизма организации взаимодействия процессов типа "клиент" и процессов типа "сервер". В современных же СУБД он является фактически основополагающим и от эффективности его реализации зависит эффективность работы системы в целом.

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

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

Затем функции управления данными были выделены в самостоятельную группу — сервер, однако модель взаимодействия пользователя с сервером соответствовала парадигме "один-к-одному" (рис. 1), то есть сервер обслуживал запросы только одного пользователя (клиента), и для обслуживания нескольких клиентов нужно было запустить эквивалентное число серверов.

взаимодействие пользовательских и клиентских процессов в модели
Рис. 1  Взаимодействие пользовательских и клиентских процессов в модели "один-к-одному"

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

Для обслуживания большого числа клиентов на сервере должно быть запущено большое количество одновременно работающих серверных процессов, а это резко повышало требования к ресурсам ЭВМ, на которой запускались все серверные процессы. Кроме того, каждый серверный процесс в этой модели запускался как независимый, поэтому если один клиент сформировал запрос, который был только что выполнен другим серверным процессом для другого клиента, то запрос тем не менее выполнялся повторно. В такой модели весьма сложно обеспечить взаимодействие серверных процессов. Эта модель самая простая, и исторически она появилась первой.

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

Она позволяет значительно уменьшить нагрузку на операционную систему, возникающую при работе большого числа пользователей ("trashing").

многопотоковая односерверная архитектура
Рис. 2  Многопотоковая односерверная архитектура

Кроме того, возможность взаимодействия с одним сервером многих клиентов позволяет в полной мере использовать разделяемые объекты (начиная с открытых файлов и кончая данными из системных каталогов), что значительно уменьшает потребности в памяти и общее число процессов операционной системы. Например, системой с архитектурой "один-к-одному" будет создано 100 копий процессов СУБД для 100 пользователей, тогда как системе с многопотоковой архитектурой для этого понадобится только один серверный процесс.

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

В некоторых системах эта проблема решается вводом промежуточного диспетчера. Подобная архитектура называется архитектурой виртуального сервера ("vir-tual server") (рис. 3).

В этой архитектуре клиенты подключаются не к реальному серверу, а к промежуточному звену, называемому диспетчером, который выполняет только функции диспетчеризации запросов к актуальным серверам. В этом случае нет ограничений на использование многопроцессорных платформ. Количество актуальных серверов может быть согласовано с количеством процессоров в системе.

Однако и эта архитектура не лишена недостатков, потому что здесь в систему добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки актуальных серверов ("load balancing") и ограничивает возможности управления взаимодействием "клиент—сервер". Во-первых, становится невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы становятся равноправными — нет возможности устанавливать приоритеты для обслуживания запросов.

архитектура с виртуальным сервером
Рис. 3  Архитектура с виртуальным сервером.

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

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

многопотоковая мультисерверная архитектура
Рис. 4  Многопотоковая мультисерверная архитектура.

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

Существует несколько возможностей распараллеливания выполнения запроса. В этом случае пользовательский запрос разбивается на ряд подзапросов, которые могут выполняться параллельно, а результаты их выполнения потом объединяются в общий результат выполнения запроса. Тогда для обеспечения оперативности выполнения запросов их подзапросы могут быть направлены отдельным серверным процессам, а потом полученные результаты объединены в общий результат (рис. 5). В данном случае серверные процессы не являются независимыми процессами, такими, как рассматривались ранее. Эти серверные процессы принято называть нитями (treads), и управление нитями множества запросов пользователей требует дополнительных расходов от СУБД, однако при оперативной обработке информации в хранилищах данных такой подход наиболее перспективен.

многонитевая мультисерверная архитектура
Рис. 5  Многонитевая мультисерверная архитектура


Похожие:

Тема: «Модели серверов баз данных» iconТема: «Модели серверов баз данных»
Поэтому изначально в архитектуре систем не было адекватного механизма организации взаимодействия процессов типа "клиент" и процессов...
Тема: «Модели серверов баз данных» iconТема Организация экономической информации
Внутримашинная организация экономической информации: файловая организация данных и базы данных. Преимущества баз данных
Тема: «Модели серверов баз данных» iconОрганизация доступа к базам данных
Используя bde, вы получаете доступ ко всем локальным стандартным базам данных вашего компьютера, к источникам данных odbc и к sql...
Тема: «Модели серверов баз данных» iconЛекция Экспортирование структур баз данных
При работе с аис часто возникают задачи, для решения которых необходимо производить перенос данных между бд. Существуют две формы...
Тема: «Модели серверов баз данных» iconЗаявитель
Протестую против действий по обработке моих персональных данных путём объединения данных обо мне из ведомственных баз данных или...
Тема: «Модели серверов баз данных» iconПредмет и содержание дисциплины «Технология баз данных» Предметной областью курса «Технологии организации, хранения и обработки данных»
...
Тема: «Модели серверов баз данных» iconMicrosoft SQL Server
Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия; конкурирует с другими...
Тема: «Модели серверов баз данных» iconБазы данных и экспертные системы Ответы на вопросы к госэкзамену
Основные понятия реляционных баз данных, ключи, внешние ключи. Команда sql create Table
Тема: «Модели серверов баз данных» icon1 Понятие о геоинформатике. Геоинформатика - это современная научная дисциплина, которая изучает природные и социально-экономические геосистемы различных иерархических уровней посредством компьютерного моделирования на основе баз данных и баз знаний. Геоинформатика изучает принципы, технику и техн
Геоинформатика это современная научная дисциплина, которая изучает природные и социально-экономические геосистемы различных иерархических...
Тема: «Модели серверов баз данных» iconКонцепция баз данных в access модель данных Access
Кроме того, Access является разработкой фирмы Microsoft и представляет собой развивающуюся систему. Все это обусловливает широкое...
Тема: «Модели серверов баз данных» iconОсновы SQL: запросы к базе данных
Пусть вы и не будете главным дизайнером баз данных, но работы с ними избежать практически невозможно. Я надеюсь этот краткий обзор...
Вы можете разместить ссылку на наш сайт:
Документы


При копировании материала укажите ссылку ©ignorik.ru 2015

контакты
Документы