Файл: Лекция 5 распределенные базы данных.pptx

Модели технологии «клиент-сервер»

Модель файлового сервера (File Server — FS);
Модель доступа к удаленным данным (Remote Data Access — RDA);
Модель сервера базы данных (DataBase Server — DBS);
Модель сервера приложений (Application Server — AS).


7.6.3 Модель файлового сервера (FS)

Сетевая ОС

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

FS-модель и персональные СУБД

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

Недостатки модели FS

К технологическим недостаткам модели относят высокий сетевой трафик (передача множества файлов, необходимых приложению), узкий спектр операций манипулирования данными ("данные — это файлы"), отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы).
Собственно, перечисленное не есть недостатки, это следствие внутренне присущих FS-модели ограничений, определяемых ее характером. Недоразумения возникают в том случае, когда FS-модель используют не по назначению — например, пытаются интерпретировать как модель сервера базы данных. Место FS-модели в иерархии моделей "клиент-сервер" — это место модели файлового сервера и ничего более.

---

Модель доступа к удаленным данным (RDA)

ЯДРО СУБД

Отличие RDA – модели от FS

Более технологичная RDA-модель существенно отличается от FS-модели характером компонента доступа к информационным ресурсам. Это, как правило, SQL-сервер.
В RDA-модели коды компонента представления и прикладного компонента совмещены и выполняются на компьютере-клиенте. Клиент поддерживает как функции ввода и отображения данных, так и чисто прикладные функции.
Доступ к информационным ресурсам на сервере обеспечивается либо операторами языка SQL, либо вызовами функций специальной библиотеки (если имеется интерфейс прикладного программирования — API)

Достоинство RDA-модели

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

Пассивная роль ядра СУБД в RDA

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

Недостатки RDA-модели

К сожалению, RDA-модель не лишена ряда недостатков. Во-первых, взаимодействие клиента и сервера посредством SQL-запросов существенно загружает сеть.
Во-вторых, удовлетворительное администрирование приложений в RDA-модели практически невозможно из-за совмещения в одной программе различных по своей природе функций (функции представления и прикладные функции)


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

ЯДРО СУБД

Достоинства DBS-модели

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

---

Достоинства DBS-модели очевидны: это и возможность централизованного администрирования прикладных функций, и снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур), и возможность разделения процедуры между несколькими приложениями, и экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры.


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

Недостатки DBS-модели

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


Модель сервера приложений (AS)

Application Programming Interface (API) - стандарт прикладного программного интерфейса

Реализация AS-модели

В AS-модели процесс, выполняющийся на компьютере-клиенте, отвечает за интерфейс с пользователем (то есть реализует функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения (Application Client — AC).
Прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (Application Server — AS).
Все низкоуровневые операции над информационными ресурсами выполняются компонентом доступа на отдельном сервере, по отношению к которому AS играет роль клиента.

Двухзвенная схема разделения функций

RDA- и DBS-модели опираются на двухзвенную схему разделения функций.
В RDA-модели прикладные функции приданы программе-клиенту («толстый» клиент), в DBS-модели («тонкий» клиент) ответственность за выполнение прикладных функций берет на себя ядро СУБД.

---

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

Трехзвенная схема разделения функций

В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важнейший изолированный элемент приложения, для его определения используются универсальные механизмы многозадачной операционной системы, и стандартизованы интерфейсы с двумя другими компонентами.
AS-модель является фундаментом для мониторов обработки транзакций (Transaction Processing Monitors — TPM), которые выделяются как особый вид программного обеспечения, ориентированного на оперативную обработку распределенных транзакций.

Программное обеспечение промежуточного слоя (Middleware)

Трехзвенной AS – модель можно считать и потому, что в ней явно выделены:

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


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

двухзвенными моделями (технология «SQL-клиент - SQL-сервер» и

трехзвенными моделями (технология ПО класса Middleware, например, менеджера распределенных транзакций Tuxedo System).

В случае двухзвенной модели клиент явным образом запрашивает данные, зная структуру базы данных (имеет место так называемый data shipping, то есть "поставка данных" клиенту). Клиент передает СУБД SQL-запрос, в ответ получает данные. Имеет место жесткая связь типа "точка- точка«, для реализации которой все СУБД используют закрытый SQL-канал (например, Oracle SQL*Net).
Канал закрыт в том смысле, что невозможно, например, использовать программу шифрования SQL- запросов по специальному алгоритму (стандартные алгоритмы шифрования, используемые, например, в Oracle SQL*Net, не сертифицированы и вряд ли будут сертифицированы в будущем.)

---

В случае трехзвенной модели клиент явно запрашивает один из сервисов (предоставляемых прикладным компонентом), передавая ему некоторое сообщение (например) и получает ответ также в виде сообщения.
Клиент направляет запрос в информационную шину (которую строит менеджер Tuxedo System), ничего не зная о месте расположения сервиса.
Имеет место так называемый function shipping (то есть "поставка функций" клиенту). Важно, что для клиента база данных (в том числе и DDB) закрыта слоем сервисов. Более того, он вообще ничего не знает о ее существовании, так как все операции над базой данных выполняются внутри сервисов.

Вывод по моделям «Клиент-сервер»

Таким образом, речь идет о двух принципиально разных подходах к построению распределенных информационных систем по технологии "клиент-сервер". Первый из них (двухзвенный: RDA, DBS) устарел и явно уходит в прошлое.
Дело в том, что SQL (ставший фактическим стандартом общения с реляционными СУБД) был задуман и реализован как декларативный язык запросов, но отнюдь не как средство взаимодействия "клиент-сервер" (об этой технологии тогда речи не было). Только потом он был "притянут за уши" разработчиками СУБД в качестве такого средства.

Технология тиражирования

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

Тиражирование данных

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

Технологии - антиподы

Технология распределенных БД и технология тиражирования данных — в определенном смысле антиподы.
Краеугольный камень первой (DDB)

---