Файл: Технология клиент-сервер (динамика создания и изменения клиент-серверной технологии).pdf

Функции промежуточных серверов могут быть в этой модели распределены в рамках глобальных транзакций путем поддержки XA-протокола (X/Open transaction interface protocol), который поддерживается большинством поставщиков СУБД. [2]

3.3.5 Архитектура серверов баз данных

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

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

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

Рисунок 5. Развитие серверов БД

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

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

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

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

рисунок 6. Виртуальный сервер

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

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

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

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

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

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

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

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

Заключение

Активно развитие компьютерных наук и сети привело к большому количеству информации и способов реализации различных систем. Так полвека назад появилось понятие распределенные системы и стала часто использоваться технология клиент-сервер.

Эта технология применима к различным системах, но в рамках данного предмета мы рассмотрели 3 части.

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

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

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

Основные выводы которые можно сделать по данной курсовой работе:

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

Библиография

1. Таненбаум Э. Распределенные системы, принципы и парадигмы / Э. Таненбаум — Спб.: Питер, 2003. - 877 с.
2. Гома Х. UML. Проектирование систем реального времени, параллельных и распределенных приложений / Х. Гома — ДМК Пресс, 2016. - 700 с.
3. Габалин А. Вопросы оптимизации структуры распределенных систем обработки информации / А. Габалин — Издательский дом Университета "Университет" , 2007. - 300 с.
4. Виноградов В. Информационно-вычислительные системы. Распределенные модульные системы автоматизации / В. Виноградов — Энергоатомиздат, 1986. - 385 с.
5. Бежитский С. Распределенные системы обработки информации и управления / С. Бежитский — Энергоатомиздат, 2012. - 140 с.