Обзор архитектуры клиент-сервер

 

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

Существуют две технологии (архитектуры) обработки удаленных данных:

• файл-серверная архитектура
• архитектура клиент-сервер.

Рассмотрим подробней каждую из этих технологий.

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

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

Исторически на персональных компьютерах использовался именно этот подход как более простой в освоении. Однако большой объем перегоняемых по сети данных быстро “забивает” сеть уже при небольшом числе пользователей, существенно ограничивая возможности роста. Этот основной и самый существенный недостаток заставил искать способы уменьшения нагрузки на сеть.

Здесь приложения выполняются на рабочих станциях. Приложение включает модули для организации диалога с пользователем, бизнес-правила (транзакции), обеспечивающие требуемую логику вычислений, и ядро СУБД. Часто ядро СУБД в модели файлового сервера не является выраженным и представляет собой набор функций, связанных с остальными компонентами приложения. Приложение, включая и ядро СУБД, дублируется на различных рабочих станциях. На файловом сервере хранятся только файлы базы данных (индексы, файлы данных и т. д.) и некоторые технологические файлы (оверлейные файлы, файлы сортировки и др.). Операторы обращения к СУБД, закодированные в прикладной программе, обрабатываются ядром СУБД на рабочей станции. СУБД организует доступ к файлам базы данных для выполнения оператора. По сети передаются запросы на чтение/запись данных, индексы, промежуточные и результирующие данные, блоки технологических файлов.
      На основе модели файлового сервера функционируют такие популярные СУБД как FoxPro ( Microsoft), dBase (Borland), CF-Clipper (Computer Associates International), Paradox (Borland) и др.
      СУБД рассматриваемого класса стоят недорого, просты в установке и освоении. Но они обладают и рядом существенных недостатков:

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

Архитектура клиент-сервер

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

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

Такой подход обеспечивает решение трех важных задач:

• уменьшение нагрузки на сеть
• уменьшение требований к компьютерам-клиентам
• повышение надежности и сохранение логической целостности базы данных.

Здесь приложения также выполняются, в основном, на рабочих станциях. Приложение включает модули для организации диалога с пользователем и бизнес-правила (транзакции). Ядро СУБД является общим для всех рабочих станций и функционирует на сервере. Операторы обращения к СУБД (SQL-операторы), закодированные в транзакции, не выполняются на рабочей станции, а пересылаются для обработки на сервер. Ядро СУБД транслирует запрос и выполняет его, обращаясь для этого к индексам и другим промежуточным данным. Обратно на рабочую станцию передаются только результаты обработ-ки оператора.
      В современных СУБД на сервере могут запускаться так называемые хранимые процедуры и триггеры, которые вместе с ядром СУБД образуют сервер базы данных. К хранимым процедурам можно обращаться из приложений на рабочих станциях. Это позволяет сократить размер кода прикладной программы и уменьшить поток SQL-операторов с рабочей станции, так как группу требуемых SQL-предложений можно закодировать в хранимой процедуре. Триггеры - это программы, которые выполняются ядром СУБД перед или после обновления (UPDATE, INSERT, DELETE) таблицы базы данных. Они позволяют автоматически поддерживать целостность базы данных.
      Модель сервера базы данных (БД) поддерживают следующие СУБД: Oracle, Sybase, Informix, Ingress, Progress и др. Причём на первые три СУБД приходятся более 80 % рынка.
      СУБД рассматриваемого класса имеют следующие преимущества:

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

 Действительно, теперь сервер БД (в случае реляционных баз данных называемый SQL-сервером) возвращает клиентскому приложению только “выжимку” того, что он просмотрел в базе, а она (выжимка), в общем случае, действительно составляет малую часть от общего объема. Поэтому в сети не наблюдается резкого увеличения нагрузки при увеличении числа клиентов. Клиентские же приложения могут выполняться на менее мощных (по сравнению с сервером) компьютерах благодаря тому, что им практически не требуется выполнять никакой дополнительной обработки полученных от сервера результатов запроса (хотя, конечно же, это не запрещено). Побочным эффектом уменьшения нагрузки на сеть является повышение скорости выполнения приложений клиентов. Кроме того, система легче масштабируется - легче и дешевле заменить один сервер на более мощный, чем десятки рабочих станций.

      Но эти СУБД имеют и недостатки:

      ==>    они намного дороже СУБД предыдущего класса, сложны в освоении,
      ==>    для эффективной работы этих СУБД требуются высокоскоростные (а поэтому и дорогие) серверы и сети.

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

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

      Использование этой модели позволяет разгрузить рабочие станции, то есть перейти к "тонким" клиентам. Конечно, сервер приложений можно организовать и с помощью хранимых процедур. Но для реализации хранимых процедур используют языки высокого уровня (например, в Oracle - язык PL/SQL ), поэтому программы получаются ресурсоёмкими. Причём возможности этих языков ограничены: с их помощью нельзя организовать обработку данных на уровне битов. Хранимые процедуры также не поддерживают распределённые приложения, т. е. они не обеспечивают автоматический запуск требуемой программы на другом сервере.
      Для устранения указанных недостатков разработаны специальные средства, которые часто называют менеджерами транзакций, мониторами транзакций, OLTP (Online Transaction Processing)-мониторами. Часто менеджер транзакций и приложения запускаются на том же компьютере (хотя это не явля-ется обязательным), где выполняется сервер базы данных, чтобы уменьшить поток SQL-запросов по сети.