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

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

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

Рис. 2.2. Файл-серверная архитектура.

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

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

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

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

В-третьих, файл-серверная архитектура предъявляет дополнительные требования к производительности клиентских рабочих мест: вся обработка данных производится на клиенте.

Примером многопользовательской системы с файл-серверной архитектурой является совместное использование БД Microsoft Access в локальной сети. В таком режиме с одной базой могут нормально работать несколько пользователей: в зависимости от размеров базы, характеристик сети и интенсивности работы с данными, это может быть до 5−10 одновременных сеансов.

Двухзвенная архитектура «клиент-сервер» . Данная архитектура предполагает, что СУБД находится на сервере и только она имеет доступ к файлам БД (рис. 2.3).

На клиентских компьютерах работают пользовательские приложения и клиентские компоненты СУБД, осуществляющие взаимодействие с сервером. От клиента на сервер приходят запросы, которые обрабатываются СУБД, и результат отправляется на клиентский компьютер. По сравнению с файл-серверной архитектурой, в этом случае минимизируется сетевой трафик: по сети передаются только затребованные данные.

Централизованная работа с файлами БД позволяет более эффективно решать вопросы, связанные с совместным доступом к данным и с обеспечением безопасности. В связи с тем, что СУБД работает на сервере, снижаются и требования к оборудованию на стороне клиента. Прикладная программа может быть написана на любом языке, который поддерживает взаимодействие с используемой СУБД через имеющиеся клиентские компоненты: могут использоваться такие технологии, как ODBC, ADO или ADO.Net, JDBC и др.

Рис. 2.3. Двухзвенная архитектура «клиент-сервер» .

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

Трехзвенная архитектура. Исправить недостатки двухзвенной архитектуры позволяет трехзвенная, также называемая трехуровневой (рис. 2.4). Данная архитектура предполагает наличие дополнительного сервера приложений, который проводит предварительную обработку запросов клиентов, формирует запросы к серверу БД и обрабатывает полученные результаты перед отправкой их клиенту.

В трехзвенной архитектуре бо? льшая часть логики приложения перенесена с клиента на сервер, и задачи клиентского приложения сводятся, в основном, к реализации пользовательского интерфейса и представлению результатов. Появляется возможность централизованно вносить изменения в алгоритмы бизнес-логики, реализованные в ПО сервера приложений. Также в этой архитектуре только сервер приложений может подключаться к серверу БД. Это снимает проблему поддержания неиспользуемых соединений и более предпочтительно с точки зрения безопасности. Недостатком многоуровневой архитектуры «клиент-сервер» является сложность разработки подобных решений.

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

Рис. 2.4. Трехзвенная архитектура.

Рис. 2.5. Архитектура интернет/интранет-решений.

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

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