Презентация, доклад Программное обеспечение ИС на тему Архитектура клиент-сервер

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

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

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

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

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

серверные процессы.

способен обрабатывать запросы от многих клиентов.
Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами

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

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

(virtual server)

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

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

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

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

называть нитями (treads), и управление нитями множества запросов пользователей требует дополнительных расходов от СУБД, однако при оперативной обработке информации в хранилищах данных такой подход наиболее перспективен.

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