Основы проектирования корпоративных систем - Сергей Зыков

Рис. 6.2. Обработка данных СуБД: клиент – сервер

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

Далее речь пойдет о базах данных корпоративных систем, их особенностях и разновидностях. Корпоративные базы данных бывают достаточно разнородными. БД можно назвать приборной доской бизнеса – по ней видны бизнес-успехи, текучесть кадров, динамика движения средств.

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

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

Преимущества лучших черт предыдущих архитектур обеспечивают централизованное администрирование, в том числе и баз данных, безопасность, надежность и отказоустойчивость и файл-серверов, обеспечивающих достаточно низкую стоимость реализации и распределение обработки данных с использованием клиентских компьютеров. Современные клиентские компьютеры, как правило, достаточно мощные. Вспомним, что Windows Vista налагает серьезные требования на вычислительную мощность и объемы памяти современных компьютеров (1Гб RAM). Ряд ресурсов клиента можно использовать.

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

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

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

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

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