Основы проектирования корпоративных систем

Самое простое, что можно применить, – это файл-сервер. Есть выделенный компьютер-клиент и другой выделенный компьютер (файл-сервер), возможно, в другом сегменте локальной сети. Файл-сервер хранит исключительно данные. Например, на нем могут храниться документы для коллективной работы с ними. У клиента есть приложение СУБД, текстовый редактор или редактор таблиц, с помощью которых он взаимодействует с этими данными. При этом клиентов может быть довольно много. Пересылка данных осуществляется по каналам локальной сети. Все остальное, кроме данных, нужно устанавливать на клиентские машины заново. Бизнес-логика, СУБД находятся у клиента. Это невыгодно для больших нагрузок и интенсивностей SQL-запросов. Возможно долгое ожидание сервера, если вычисления осуществляются на клиенте. Магистраль тоже может быть перегружена. Для разгрузки магистрали и нагрузки сервера используется клиент-серверная архитектура. Таким образом мы избавляемся от долгой и дорогостоящей настройки СУБД на каждом клиенте. СУБД находится на сервере и взаимодействует с данными на этом или другом сервере. Логически обращение происходит всегда к одному серверу. На клиенте находится только приложение (логика). Таким образом, сервер становится существенным звеном. Магистраль разгружается. Клиент становится более специализированным и дешевым. Обработка данных становится эффективнее, и количество пользователей можно увеличить. При этом в явном виде можно выделить сервер базы данных как особый уровень (рис. 6.3).

Рис. 6.3. Обработка данных СуБД: файл-сервер

Возможности, характерные для данной архитектуры таковы: во-первых, явно присутствуют клиентская и серверная части; во-вторых, сервер БД отвечает за хранение данных и предоставление доступа к БД. Общая база данных хранится на сервере и доступна всем пользователям ЛВС. Таким образом, клиент получает согласованные данные, доступные всем пользователям, хранение удешевляется, а доступ к БД становится распределенным. Отдельные фрагменты БД могут храниться на разных компьютерах в одном узле ЛВС.

Запрос на доступ к данным инициируется клиентской частью. Все клиент-серверное взаимодействие строится на стандартах. В данном случае используется язык SQL – язык структурных запросов к БД со стандартами от 1992 г. и более поздний стандарт ANSI. Они позволяют инкрементально наращивать функциональность и обеспечить взаимодействие БД, созданных разными производителями (Microsoft, Oracle). Под SQL-сервером понимается логическое имя, возможно группа компьютеров или кластер со стандартным интерфейсом в виде языка SQL. При этом в идеале любой SQL-клиент совместим с любым SQL-сервером. Если вернуться к схеме взаимодействия клиента и сервера БД, то можно видеть, что на сервер приходится большая нагрузка. В связи с этим SQL-сервер является не только центральным звеном системы БД, но и наиболее ответственным и важным звеном, узким местом всей системы, несмотря на то, что клиент сам по себе достаточно мощный. Если клиент может взять на себя часть функций прикладной логики, то он должен ее на себя взять. В этом и состоит перспектива систем управления БД – гибкая балансировка нагрузки между клиентом и сервером.

Исторически первым методом организации клиент-серверного взаимодействия была RPC. Эта архитектура значима и сегодня. На довольно низком уровне можно обеспечить распределение нагрузки. Некоторые компоненты могут располагаться на клиенте. Если ЛВС вычислительно неоднородна, то взаимодействие на уровне процедурных сервисов позволяет скрыть неоднородность сети. При этом снижается значимость аппаратной совместимости. Часть парка аппаратного обеспечения может быть заменена без критического влияния на важные системы. Принцип открытых систем сглаживает подобные неровности инкапсуляцией функциональности на прикладном уровне процедур приложений. Если говорить о SQL-сервере, то функциональное разделение производится следующим образом. СУБД работает на стороне сервера, на стороне клиента организуется лишь инициирование запросов к SQL-серверу. Вся работа по формированию запросов, обработке данных, организации транзакционного многопользовательского взаимодействия осуществляется на стороне сервера. Ряд запросов носит типовой характер. Результат этих запросов стоит кешировать в ОЗУ на сервере. Таким образом возникает возможность хранения кэша на выделенном сервере. Если клиент использует одни и те же запросы, стоит кешировать БД на локальной машине. Так можно моделировать работу сервера на клиенте и осуществлять ряд операций по обработке данных локально. В отличие от традиционной клиент-серверной архитектуры мы получаем распараллеливание и балансировку прикладных функций между клиентом и сервером. Прежде чем обсудить трехзвенную архитектуру, поговорим об особенности архитектуры сервера баз данных.