Лекции по БЖ

AS

DBS

RDA.

FS.

Компонент представления и прикладной компонент размещаются на клиенте. На сервер выносится компонент доступа.

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

Преимущества:

1. Сервер поддерживает лишь один компонент доступа к ресурсам, следовательно сервер может не выделятся из общей среды.

Недостатки: клиент должен поддерживать прикладной и интерактивный компонент, следовательно к клиенту предъявляются требования.

2. Приходится тиражировать ядро СУБД.

3. Очень высокий трафик.

4. Низкоуровневый интерфейс.

Для данной схемы характерно максимально высокая степень децентрализации. Крайне сложно поддерживать защиту данных, т.е. функция защиты данных также децентрализована. В этой схеме практически нет места для SQL. Здесь используются сои языки.

Клиент посылает SQL запрос и получает SQL ответ, т.е. таблицу.

Преимущества:

1. Существенно снижается трафик

2. Разгрузка сервера от несвойственных ему функций.

3. Унифицируется интерфейс.

4. Невысокие требования к серверу.

Недостатки:

1. Загрузка сети по прежнему достаточно велика

2. Высокая степень децентрализации. Сложно организовать администрирование.

3. Роль сервера пассивна, т.е. сервер лишь отвечает на запросы клиента.

Прикладной компонент переносится на сервер.

Пояснение: здесь два типа взаимодействия

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

2. Взаимодействие между прикладным компонентом и компонентом доступа, с использованием SQL

Такую схему позволяют строить практически все современный БД: Informix, Sybase, Ingress, Oracle. Основой такой схемы является механизм хранимых процедур.

Плюсы:

1. Существенно снижается трафик. Хранимые процедуры выполняются на сервере, следовательно, предельно низкий трафик, предельно разгружена сеть.

2. Наличие хранимых процедур (библиотека), следовательно, позволяет существенно снижать объем программного кода.

3. Предельно высокая степень централизации позволяет организовать надежную защиту данных.

4. Ядро СУБД размещается на одном камне, следовательно, не требуется поддерживать другие ядра.

5. Перенесение одного компонента на другой позволяет активизировать сервер, передать ему кое-какие активные функции.

Минусы:

1. Очень высокие требования к серверу.

2. Язык хранимых процедур недостаточно выразителен, совершенно не стандартизован. Система не обладает мобильностью, переносимостью

Сервер выполняет прикладные функции, которые являются разделяемыми на клиенте, сохраняют функции специфичные для данной функции.

Выделяются два сервера.

Каждый компонент размещается на отдельном камне, этот компонент является клиентом: сервер приложений и сервер данных.

API - интерфейс.

AS работает под управлением многозадачной операционной системы.

Это трехзвенная архитектура.

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

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

Функции клиента и сервера совмещались в одной программе.

В прочем, были как функции доступа, так и прикладные программы.

II. В рамках той же самой централизованной архитектуры перешли к такому взаимодействию: выделили клиент и сервер в отдельные программы.

Но взаимодействие между клиентами и сервером осуществляется один к одному, следовательно, нужно поддерживать несколько копий ядра СУБД.

III. Эта схема существовала до тех пор, пока не появилась распределенные вычислительные системы на базе сетей.

Взаимодействие клиента с сервером стало осуществляться по сетям. Произошло реальное разделение клиента и сервера (физическое разделение). Но по-прежнему сохранялось взаимодействие 1:1, т.е. каждый клиент обслуживался своим собственным сервером.

IV Отказ от поддержания копии ядра СУБД и от взаимодействия 1:1

Этот шаг связан с переходом к архитектуре с выделенным сервером. В системе поддерживалась единственная программа – сервер, которой обладал монополией доступа и работой системы.

Взаимодействие 1:n. Один сервер взаимодействует с несколькими клиентами.

Каждый клиент связан отдельно с сервером.

Такая схема называется много потоковой архитектурой.

Эта архитектура централизует основную функцию доступа к ресурсам. Снизило нагрузку на операционную систему. Но: Эта архитектура не позволяет использовать возможности многопроцессорной системы параллельной обработки (будут простаивать процессы).

V Решением этой проблемы является выделение в этой схеме еще одного уровня управления, еще одной программы.

Эти программы выполняют единственную функцию – диспетчеризации.

Задача виртуального сервера принимать запросы от клиентов и распределять их по серверам, используя при этом определенную дисциплину. Каждый из утих серверов выполняется на отдельном процессоре. Такая схема называется – схема с виртуальным сервером.

Обеспечивает равномерную нагрузку на многопроцессорную систему. Напрямую с клиент-сервером не взаимодействует. Виртуальный сервер не делает различия между серверами.

Но:

- в такой системе не поддерживается специализация серверов.

- невозможно обслуживать приоритетные заявки.

VI в системах в которых нужно обеспечить эти два минуса, нужно обеспечить архитектуру, где каждому серверу привязывать своих клиентов – это многопотоковая мультисерверная архитектура.

Каждый сервер обслуживает своих клеентов. Каждый из серверов должен держать одновременно несколько потоков. Такая схема сегодня весьма перспективна.

Активный сервер

Активным является клиент, сервер – пассивен.

Какие могут возникать ситуации из-за пассивности сервера:

1. Доступ к информационным ресурсам: поддержание целостности данных. Решение: в системах (FS, RDA), где роль сервера пассивна, эта проблема решается у клиента, то есть в самом приложении контролируется логичность, не противоречивость.

2. Не поддержание некоторых правил. Решение: эта задача возлагается на приложения.

3. Отслеживание состояния в БД (пусть система должна контролировать данные о температуре, и в том случае, если температура превышает некий уровень, то должен запускаться некий процесс, который корректирует технологический процесс) Решение: имеется специальное приложение, которое через какой-то период времени опрашивает устройство и фиксирует значение параметра. После этого приложение анализирует параметр и запускает приложение, которое корректирует работу. Но это все создает проблему с определением периода опроса.

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

5. Работа с нестандартными типами данных. Возникает необходимость расширить стандартный набор типов данных. Решение: писать свой обработчик.

Начиная с DBS модели появляется механизм вынесения на сервер активных функций.

Современные БД обеспечивают возможность активизации активных функций тремя механизмами:

1. Механизм хранимых процедур

2. Механизм триггеров (правил)

3. Механизм событий

Механизм хранения процедур используется для поддержания целостности БД, разделение функций в БД.

Он позволяет организовать независимый уровень контроля доступа к данным;

Разделение функции несколькими приложениями;

Снижение трафика;

Поддержка функций администрирования.

Механизм триггеров: позволяет каждой таблице приписать некоторые условия, при выполнении которых происходит запуск некоторого приложения. Тем самым контроль правил предметной области переносится с клиента на сервер.

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

Дата добавления: 2014-01-20