Технология "клиент-сервер"

К недостаткам RDA-модели можно отнести высокие требования к клиентским вычислительным установкам, так как прикладные программы  обработки данных, определяемые спецификой предметной области АИС, выполняются  на них. Другим недостатком является все же существенный трафик сети, обусловленный тем, что с сервера базы данных клиентам направляются наборы (таблицы) данных, которые в определенных случаях могут занимать достаточно существенный объем.

2.3 Модель сервера базы данных

         Развитием RDA-модели стала модель сервера базы данных. Ее сердцевиной является рассмотренный ранее механизм хранимых процедур. В отличие от RDA-модели, определенные для конкретной предметной области АИС события, правила и процедуры, описанные средствами языка SQL, хранятся вместе с данными на сервере системы и на нем же выполняются. Иначе говоря, прикладной компонент полностью размещается и выполняется на сервере системы. Схематично DBS-модель приведена на рис.3.

 

 

 

 Рис.3. Модель сервера  базы данных (DBS-модель)

 

         На клиентских установках в DBS-модели размещается только интерфейсный компонент (компонент представления) АИС, что существенно снижает требования к вычислительной установке клиента. Пользователь через интерфейс системы на клиентской установке направляет на сервер базы данных только лишь вызовы необходимых процедур, запросов и других функций по обработке данных. Все затратные операции по доступу и обработке данных выполняются на сервере и клиенту направляются лишь результаты обработки, а не наборы данных, как в RDA-модели. Этим обеспечивается существенное снижение трафика сети в DBS-модели по сравнению с RDA-моделью.

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

          К достоинствам же DBS-модели, помимо  разгрузки сети, относится и более активная роль сервера сети, размещение, хранение и выполнение на нем механизма событий, правил и процедур, возможность более адекватно и эффективно «настраивать» распределенную АИС на все нюансы предметной области системы. Также более надежно обеспечивается согласованность состояния и изменения данных, и, вследствие этого, повышается надежность хранения и обработки данных, эффективно координируется коллективная работа пользователей с общими данными.

2.4 Модель сервера приложений

Чтобы разнести требования к вычислительным ресурсам сервера в отношении быстродействия и памяти по разным вычислительным установкам, используется модель сервера приложений. Суть AS-модели заключается в переносе прикладного компонента АИС на специализированный в отношении повышенных ресурсов по быстродействию дополнительный сервер системы. Схема AS-модели приведена на рис.4.

 

 Рис.4. Модель сервера  приложений (AS-модель)

 Как и в DBS-модели, на клиентских установках располагается  только интерфейсная часть системы, т.е. компонент представления. Однако вызовы функций обработки данных направляются на сервер приложений, где эти функции совместно выполняются для всех пользователей системы. За выполнением низкоуровневых операций по доступу и изменению данных сервер приложений, как в RDA-модели, обращается к SQL-серверу, направляя ему вызовы SQL-процедур, и получая, соответственно, от него наборы данных. Как известно, последовательная совокупность операций над данными (SQL-инструкций), имеющая отдельное смысловое значение, называется транзакцией. В этом отношении сервер приложений от клиентов системы управляет формированием транзакций, которые выполняет SQL-сервер. Поэтому программный компонент СУБД, инсталлируемый на сервере приложений, еще называют также монитором обработки транзакций (Transaction Processing Monitors — TRM), или просто монитором транзакций.

AS-модель, сохраняя сильные  стороны DBS-модели, позволяет более  оптимально построить вычислительную  схему информационной системы,  однако, как и в случае RDA-модели, повышает трафик сети.

 В еще не устоявшейся  до конца терминологии по моделям  и технологиям «Клиент-сервер»  RDA-модель характеризуют еще как  модель с так называемыми «толстыми», а DBS-модель и AS-модель как  модели, соответственно, с «тонкими»  клиентами. По критерию звеньев системы RDA-модель и DBS-модель называют двухзвенными (двухуровневыми) системами, a AS-модельтрехзвенной (трехуровневой) системой.

В практических случаях  используются смешанные модели, когда  простейшие прикладные функции и  обеспечение ограничений целостности данных поддерживаются хранимыми на сервере процедурами (DBS-модель), а более сложные функции предметной области (так называемые «правила бизнеса») реализуются прикладными программами на клиентских установках (RDA-модель) или на сервере приложений (AS-модель).

3. Эволюция серверов баз данных

3.1 Централизованная архитектура и архитектура "один к одному"

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

Рисунок 5. Централизованная архитектура (а) и архитектура "один к одному" (б).

Чтобы понять суть проблемы, рассмотрим эволюцию серверов баз данных. Первое время доминировала модель, когда управление данными (функция сервера) и взаимодействие с пользователем были совмещены в одной программе (Рис. 5). Затем функции управления данными были выделены в самостоятельную группу — сервер, однако модель взаимодействия пользователя с сервером соответствовала парадигме "один-к-одному" (Рис. 5), то есть сервер обслуживал запросы ровно одного пользователя (клиента), и для обслуживания нескольких клиентов нужно было запустить эквивалентное число серверов. Выделение сервера в отдельную программу — революционный шаг, позволяющий, в частности, поместить сервер на одну машину, а программный интерфейс с пользователем — на другую, осуществляя взаимодействие между ними по сети (Рис. 6). Однако необходимость запуска большого числа серверов для обслуживания множества пользователей сильно ограничивала возможности такой системы.

Рисунок 6. Размещение клиента  и сервера на различный машинах.

3.2 Многопотоковая архитектура

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

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

 

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

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

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

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

 

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

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

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

Современное решение  проблемы СУБД для мультипроцессорных платформ заключается в возможности  запуска нескольких серверов базы данных, в том числе и на различных  процессорах. При этом каждый из серверов должен быть многопотоковым. Если два эти условия выполнены, то есть основание говорить о многопотоковой архитектуре с несколькими серверами (multi-threaded, multi-server architecture), представленной на Рис. 9.

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

 

 

 

 

 

 

 

 

Заключение

Наиболее бурно развивающимся  направлением в области информационных технологий в последние годы стала  разработка программного обеспечения  на основе архитектуры клиент-сервер, связанного с сетью Internet и системами Intranet, опирающегося на Web-технологию и язык Java. Объектные, распределенные технологии консорциумов OMG и ODMG интегрируются в общие тенденции, расширяя и обобщая их. Примечательно, что все ведущие производители систем Internet/Intranet, включая Sun, IBM, Netscape, Microsoft, встраивают в свои продукты поддержку КС совместимых протоколов.

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

 

 

 

 

 

 

 

 

 

 

 

Список литературы:

1) Калабухова Г.В., Титов  В.М. «Компьютерный практикум по информатике. Офисные технологии»: учеб.пособие. – М.:ИД «ФОРУМ»: ИНФРА-М, 2008, - 336с.: ил, - (Высшее образование).

2) Велихов, А. С. Основы информатики и компьютерной техники: учебное пособие. – Москва: СОЛОН-Пресс, 2008. – 539 с.

3) Симонович С.В., Евсеев  Г.А.Алексеев А. Н. Общая информатика.  Учебное пособие. – М.: АСТ–Пресс:  Инфорком–Пресс, 2008.- 277с.

4) Гвоздева, В. А. «Информатика, автоматизированные информационные технологии и системы»: учебник / В. А. Гвоздева. – Москва: Форум: Инфра-М, 2011. – 541 с.

5) Н. В. Макарова  и др «Информатика»: учебник  для студентов экономических  специальностей высших учебных  заведений ;.. – Москва: Финансы и статистика, 2009. – 765 c.