Процессор управления данными расположение модели распределений

Вы будете перенаправлены на Автор24

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

Поддержка соответствия базы данных вносимым изменениям

В современных распределенных системах информация хранится децентрализованно или централизованно.

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

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

Готовые работы на аналогичную тему

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

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

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

Основные достоинства модели распределенной базы данных:

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

Недостатки модели распределенной базы данных:

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

В модели тиражирования данных предполагается дублирование (создание точных копий) данных в узлах сети (рисунок 2). Обработка данных проводится локально.

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

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

Достоинства модели тиражирования баз данных представлены:

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

Основным недостатком модели тиражирования баз данных является возможное несоответствие копий баз данных в некоторый период времени.

Доступ к общим данным

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

Монопольный доступ чаще всего используют в двух случаях:

  • при необходимости исключения доступа к объектам другими пользователями;
  • при проведении ответственных операций с базами данных, которые не допускают других действий.

Пользователем в первом случае устанавливается явная блокировка. Во втором случае пользователем также может быть установлена явная блокировка или при необходимости автоматически устанавливается неявная (без ведома приложения или пользователя) блокировка самой СУБД.

Режим коллективного доступа не предполагает полную блокировку на используемые объекты.

При организации коллективного доступа используется механизм блокировок.

Блокировкой является временный запрет или ограничение доступа к используемому объекту на время выполнения какой-нибудь операции в базе данных других пользователей.

Существует 4 основные вида блокировок:

  • предохраняющая полная блокировка;
  • предохраняющая блокировка от записи;
  • блокировка от записи;
  • полная блокировка.

Тупики

При отсутствии управления доступом к совместно используемым объектам между пользователями ресурсов могут возникнуть тупиковые ситуации (блокировки, «смертельные объятия» или клинчи). Обратим внимание на различие понятий блокировки в смысле тупикового события от блокировки в смысле контроля доступа к объектам.

Существуют взаимные и односторонние тупики.

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

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

Протоколы фиксации транзакций

Широко использующимися являются 2 протокола фиксации транзакций: двухфазный и трехфазный.

Источник

Управление распределенными данными

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

Модели архитектуры клиент-сервер

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

Типичные варианты (рис. 5.1) разделения функций между компьютером-сервером и компьютером-клиентом:

o Распределенное представление;

o Удаленное представление;

o Распределенная функция;

o Удаленный доступ к данным;

o Распределенная БД.

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

В модели удаленного доступа к данным (Remote Data Access — RDA) программы, реализующие функции представления информации и логик прикладной обработки, совмещены и выполняются на компьютере-клиенте. Обращение за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызовом специальной библиотеки API (Application Programming Interface – интерфейс прикладного программирования).

Распределенное представление Удаленное представление Распределенная функция Удаленный доступ к данным Распределенная БД
Управление данными Управление данными Управление данными Управление данными Управление данными
Обработка Обработка Обработка
Представление
Управление данными
Обработка Обработка Обработка
Представление Представление Представление Представление Представление

Рис. 5.1. Спектр моделей архитектуры клиент-сервер

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

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

Модель удаленного представления (сервера баз данных) (DataBase Server — DBS) отличается от RDA-модели тем, что функции компьютера-клиента ограничиваются функциями представления информации, а прикладные функции обеспечиваются приложением, находящемся на компьютере-сервере. Приложения реализуются несколькими клиентами в виде хранимых процедур, хранящихся в словаре базы данных. Хранимые процедуры могут выполняться в режиме компиляции и интерпретации.

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

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

— низкая эффективность использования вычислительных ресурсов ЭВМ, поскольку не удается организовать управление входным потоком запросов к программам компьютера-сервера, а также обеспечить перемещение процедур на другие компьютеры-серверы.

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

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

Модель распределенного представления реализует централизованную схему управления вычислительными ресурсами.

Достоинство модели РП: простота обслуживания и управления доступом к системе и относительная дешевизна ввиду невысокой стоимости оконечных терминалов.

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

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

Похожее:  Драйвера на материнскую плату Biostar Socket AM2 NF520 A2 ver 6 x

Модель распределенной базы данных предполагает наличие мощного компьютера-клиента. Данные хранятся на компьютере-клиенте и на компьютере-сервере. Взаимосвязь обеих баз данных может быть двух разновидностей: а) в локальной и удаленной базах хранятся отдельные части единой базы данных; б) локальная и удаленная базы данных являются синхронизируемыми друг с другом копиями.

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

Трехзвенная модель распределения функций представляет собой типовой вариант, при котором каждая из трех функций приложения реализуется на отдельном компьютере. Модель имеет название модель сервера приложений, или AS-модель (Application Server) (рис. 5.2).

Рис. 5.2. Трехзвенная модель сервера приложений

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

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

Достоинство AS-модели – гибкость и универсальность, благодаря разделению функций на три независимые составляющие. Модель во многих случаях более эффективна по сравнению с двухзвенными моделями. Недостаток модели – более высокие затраты ресурсов компьютеров на обмен информацией между компонентами приложения по сравнению с двухзвенными моделями.

Программные продукты, реализующие среду функционирования приложений на компьютерах-серверах приложений – BEA WebLogic Server (BEA System Corp.), Inprise Application Server (Inprise Corp.) и IBM Web Sphere Application Server (IBM Corp.)

Сложные схемы взаимодействия – схемы, в которых элемент, являющийся сервером для некоторого клиента, в свою очередь, выступает в роли клиента по отношению к другому серверу (рис. 5.3). Пример этого мы наблюдали в AS-модели.

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

Источник

Модели клиент—сервер в технологии распределенных баз данных

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

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

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

Рассмотрим основные понятия, применяемые в системах уп­равления распределенными базами данных.

Рис.1. Режимы работы с базами данных

Пользователь БД — программа или человек, обращающийся к базе данных.

Запрос — процесс обращения пользователя к БД с целью вво­да, получения или изменения информации в БД.

Транзакция — последовательность операций модификации дан­ных в БД, переводящая БД из одного непротиворечивого состоя­ния в другое непротиворечивое состояние.

Логическая структура БД — определение БД на физически независимом уровне; ближе всего соответствует концептуальной модели БД.

Топология БД, или структура распределенной БД, — схема рас­пределения физической организации базы данных в сети.

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

Удаленный запрос — запрос, который выполняется с использо­ванием модемной связи.

Возможность реализации удаленной транзакции — обработка од­ной транзакции, состоящей из множества SQL-запросов, на од­ном удаленном узле.

Поддержка распределенной транзакции допускает обработку тран­закции, состоящей из нескольких запросов SQL, которые выпол­няются на нескольких узлах сети (удаленных или локальных), но каждый запрос в этом случае обрабатывается только на одном узле.

Распределенный запрос — запрос, при обработке которого ис­пользуются данные из БД, расположенные в разных узлах сети.

Системы распределенной обработки данных в основном свя­заны с первым поколением БД, которые строились на мульти­программных операционных системах и использовали централи­зованное хранение БД на устройствах внешней памяти централь­ной ЭВМ и терминальный многопользовательский режим доступа. При этом пользовательские терминалы не имели собственных ресурсов, т. е. процессоров и памяти, которые могли бы исполь­зоваться для хранения и обработки данных. Первой полностью реляционной системой, работающей в многопользовательском режиме, была СУБД SYSTEM R фирмы IВМ. Именно в ней были реализованы как язык манипулирования данными SQL, так и основные принципы синхронизации, применяемые при распре­деленной обработке данных, которые до сих пор являются ба­зисными практически во всех коммерческих СУБД.

Модели клиент—сервер в технологии распределенных баз данных

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

Основной принцип технологии клиент— сервер применитель­но к технологии управления базами данных заключается в разде­лении функций стандартного интерактивного приложения на пять групп, имеющих различную природу:

— функции ввода и отображения данных (Presentation Logic);

— прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);

— функции обработки данных внутри приложения (Database Logic);

— функции управления информационными ресурсами (Database Manager System);

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

Структура типового приложения, работающего с базой дан­ных в архитектуре клиент— сервер, приведена рис. 2.

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

• формирование экранных изображений;

• чтение и запись в информации экранные формы;

• обработка движений мыши и нажатие клавиш клавиатуры.

Рис. 2. Структура типового приложения, работающего с базой данных

Бизнес-логика, или логика собственно приложений — это часть кода приложения, которая опре­деляет собственно алгоритмы решения конкретных задач при­ложения. Обычно этот код пишется с использованием различных языков программирования, таких как С, С++, Visual Basic и др.

Таблица 1

Логика обработки данных — это часть кода приложения, которая непосредственно связана с обработкой данных внутри приложения. Данными управляет соб­ственно СУБД. Для обеспечения доступа к данным использует­ся язык SQL.

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

В централизованной архитектуре эти части приложения располагаются в единой среде и комбинируют­ся внутри одной исполняемой программы.

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

• распределенная презентация (DR – Distribution Presentation);

• удаленная презентация (RP — Remote Presentation);

• распределенная бизнес-логика (RBL – Remote business logic);

• распределенное управление данными (DDM – Distributed data manegement);

• удаленное управление данными (RDM – Remote data manegement).

Эта условная классификации показывает, как могут быть рас­пределены отдельные задачи между серверным и клиентскими процессами. В этой классификации отсутствует реализация уда­ленной бизнес-логики. Считается, что она не может быть удале­на сама по себе полностью, а может быть лишь распределена между разными процессами, которые могут взаимодействовать друг с другом.

Похожее:  Кулер для процессора матрица

Двухуровневые модели

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

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

Распределение функций в этой модели представлено на рис. 3.

В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм уп­равления всеми информационными ресурсами, собственно база метаданных, находится на клиенте.

Достоинство этой модели заключается в том, что приложение разделено на два взаимодействующих процесса. При этом сервер (серверный процесс) может обслуживать множество клиентов, ко­торые обращаются к нему с запросами.

Собственно СУБД должна находиться в этой модели на клиентском компьютере.

Алгоритм выполнения клиентского запроса сводится к следу­ющему.

1. Запрос формулируется в командах ЯМД.

2. СУБД переводит этот запрос в последовательность файловых команд.

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

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

Данная модель имеет следующие недостатки:

• высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению;

• узкий спектр операций манипулирования с данными, кото­рый определяется только файловыми командами;

• отсутствие адекватных средств безопасности доступа к дан­ным (защита только на уровне файловой системы).

Модель удаленного доступа к данным.В модели удаленного до­ступа (RDA – Remote Data Access) база данных хранится на сер­вере. На сервере же находится и ядро СУБД. На компьютере кли­ента располагается презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 4.

Рис.4. Структура модели удаленного доступа к данным

Преимущества данной модели заключаются в следующем:

• перенос компонента представления и прикладного компо­нента на клиентский компьютер существенно разгружает сервер БД, сводя к минимуму общее число выполняемых процессов в операционной системе;

« сервер БД освобождается от несвойственных ему функций; процессор или процессоры сервера целиком загружаются опера­циями обработки данных запросов и транзакций;

• резко уменьшается загрузка сети, так как по ней от клиентов к серверу передаются не запросы на ввод-вывод в файловой тер­минологии, а запросы на SQL, а их объем существенно меньше. В ответ на запросы клиент получает только данные, соответству­ющие запросу, а не блоки файлов.

Основное достоинство RDA-модели — унификация интерфей­са клиент—сервер (стандартом при общении приложения-клиен­та и сервера становится язык SQL).

Данная модель имеет следующие недостатки:

• запросы на языке SQL при интенсивной работе клиентской части приложения могут существенно загрузить сеть;

• так как в этой модели на клиенте располагается и презентационная логика, и бизнес-логика приложения, то при повторении аналогичных функций в разных приложениях код соответствующей бизнес-логики должен быть повторен для каждого клиентского при­ложения. Это вызывает излишнее дублирование приложения;

• сервер в этой модели играет пассивную роль, поэтому функ­ции управления информационными ресурсами должны выполнять­ся на клиенте.

Источник

Распределенная обработка данных

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

Модель удаленного управления данными. Модель файлового сервера

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

Распределение функций в этой модели представлено на рис. 10.4.

В этой модели файлы базы данных хранятся на сервере, клиент обращается к серверу с файловыми командами, а механизм управления всеми информационными ресурсами, собственно база мета-данных, находится на клиенте.

Модель файлового сервера

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

Каков алгоритм выполнения запроса клиента?

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

Перекачка информации с сервера на клиент производится до тех пор, пока не будет получен ответ на запрос клиента.

  • высокий сетевой трафик, который связан с передачей по сети множества блоков и файлов, необходимых приложению;
  • узкий спектр операций манипулирования с данными, который определяется только файловыми командами;
  • отсутствие адекватных средств безопасности доступа к данным (защита только на уровне файловой системы).

Модель удаленного доступа к данным

В модели удаленного доступа (Remote Data Access, RDA ) база данных хранится на сервере. На сервере же находится ядро СУБД. На клиенте располагается презентационная логика и бизнес-логика приложения. Клиент обращается к серверу с запросами на языке SQL. Структура модели удаленного доступа приведена на рис. 10.5.

Модель удаленного доступа (RDA)

Преимущества данной модели:

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

Основное достоинство RDA -модели — унификация интерфейса «клиент-сервер», стандартом при общении приложения-клиента и сервера становится язык SQL.

  • все-таки запросы на языке SQL при интенсивной работе клиентских приложений могут существенно загрузить сеть;
  • так как в этой модели на клиенте располагается и презентационная логика, и бизнес-логика приложения, то при повторении аналогичных функций в разных приложениях код соответствующей бизнес-логики должен быть повторен для каждого клиентского приложения. Это вызывает излишнее дублирование кода приложений;
  • сервер в этой модели играет пассивную роль, поэтому функции управления информационными ресурсами должны выполняться на клиенте. Действительно, например, если нам необходимо выполнять контроль страховых запасов товаров на складе, то каждое приложение, которое связано с изменением состояния склада, после выполнения операций модификации данных, имитирующих продажу или удаление товара со склада, должно выполнять проверку на объем остатка, и в случае, если он меньше страхового запаса, формировать соответствующую заявку на поставку требуемого товара. Это усложняет клиентское приложение, с одной стороны, а с другой — может вызвать необоснованный заказ дополнительных товаров несколькими приложениями.

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

Для того чтобы избавиться от недостатков модели удаленного доступа, должны быть соблюдены следующие условия:

  1. Необходимо, чтобы БД в каждый момент отражала текущее состояние предметной области , которое определяется не только собственно данными, но и связями между объектами данных. То есть данные, которые хранятся в БД, в каждый момент времени должны быть непротиворечивыми.
  2. БД должна отражать некоторые правила предметной области, законы, по которым она функционирует ( business rules ). Например, завод может нормально работать только в том случае, если на складе имеется некоторый достаточный запас (страховой запас) деталей определенной номенклатуры, деталь может быть запущена в производство только в том случае, если на складе имеется в наличии достаточно материала для ее изготовления, и т. д.
  3. Необходим постоянный контроль за состоянием БД, отслеживание всех изменений и адекватная реакция на них: например, при достижении некоторым измеряемым параметром критического значения должно произойти отключение определенной аппаратуры, при уменьшении товарного запаса ниже допустимой нормы должна быть сформирована заявка конкретному поставщику на поставку соответствующего товара.
  4. Необходимо, чтобы возникновение некоторой ситуации в БД четко и оперативно влияло на ход выполнения прикладной задачи.
  5. Одной из важнейших проблем СУБД является контроль типов данных. В настоящий момент СУБД контролирует синтаксически только стандартно-допустимые типы данных, то есть такие, которые определены в DDL ( data definition language ) — языке описания данных, который является частью SQL. Однако в реальных предметных областях у нас действуют данные, которые несут в себе еще и семантическую составляющую, например, это координаты объектов или единицы различных метрик, например рабочая неделя в отличие от реальной имеет сразу после пятницы понедельник.
Похожее:  Как правильно установить вентиляторы в корпус компьютера

Данную модель поддерживают большинство современных СУБД: Informix , Ingres, Sybase, Oracle, MS SQL Server. Основу данной модели составляет механизм хранимых процедур как средство программирования SQL-сервера, механизм триггеров как механизм отслеживания текущего состояния информационного хранилища и механизм ограничений на пользовательские типы данных, который иногда называется механизмом поддержки доменной структуры. Модель сервера баз данных представлена на рис. 10.6.

Модель активного сервера БД

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

Централизованный контроль в модели сервера баз данных выполняется с использованием механизма триггеров. Триггеры также являются частью БД.

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

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

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

И хранимые процедуры, и триггеры хранятся в словаре БД, они могут быть использованы несколькими клиентами, что существенно уменьшает дублирование алгоритмов обработки данных в разных клиентских приложениях.

Для написания хранимых процедур и триггеров используется расширение стандартного языка SQL, так называемый встроенный SQL . Встроенный SQL мы рассмотрим в «Встроенный SQL» .

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

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

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

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

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

Эта модель является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 10.7. Этот промежуточный уровень содержит один или несколько серверов приложений.

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

В этой модели компоненты приложения делятся между тремя исполнителями:

  • Клиент обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы; клиент может запускать локальный код приложения клиента, который может содержать обращения к локальной БД , расположенной на компьютере-клиенте. Клиент исполняет коммуникационные функции front-end части приложения, которые обеспечивают доступ клиенту в локальную или глобальную сеть. Дополнительно реализация взаимодействия между клиентом и сервером может включать в себя управление распределенными транзакциями, что соответствует тем случаям, когда клиент также является клиентом менеджера распределенных транзакций.
  • Серверы приложений составляют новый промежуточный уровень архитектуры. Они спроектированы как исполнения общих незагружаемых функций для клиентов. Серверы приложений поддерживают функции клиентов как частей взаимодействующих рабочих групп, поддерживают сетевую доменную операционную среду, хранят и исполняют наиболее общие правила бизнес-логики, поддерживают каталоги с данными, обеспечивают обмен сообщениями и поддержку запросов, особенно в распределенных транзакциях.
  • Серверы баз данных в этой модели занимаются исключительно функциями СУБД: обеспечивают функции создания и ведения БД, поддерживают целостность реляционной БД, обеспечивают функции хранилищ данных (warehouse services). Кроме того, на них возлагаются функции создания резервных копий БД и восстановления БД после сбоев, управления выполнением транзакций и поддержки устаревших (унаследованных) приложений (legacy application).

Отметим, что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные аналитические расчеты над базой данных, которые относятся к области OLAP-приложений. (On-line analytical processing .) В этой модели большая часть бизнес-логики клиента изолирована от возможностей встроенного SQL , реализованного в конкретной СУБД , и может быть выполнена на стандартных языках программирования, таких как C, C++, SmallTalk, Cobol. Это повышает переносимость системы, ее масштабируемость .

Функции промежуточных серверов могут быть в этой модели распределены в рамках глобальных транзакций путем поддержки XA-протокола (X/Open transaction interface protocol ), который поддерживается большинством поставщиков СУБД .

Источник



Распределенные системы: определение, особенности и основные принципы

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

Общее представление о системе

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

Примеры распространения системы:

  1. Традиционный стек. Эти базы данных хранятся в файловой системе одной машины. Всякий раз, когда пользователь хочет получить информацию, он напрямую общается с этой машиной. Чтобы распространить эту систему баз данных, нужно, чтобы она работала на нескольких ПК одновременно.
  2. Распределенная архитектура.

Распределенная система позволяет масштабироваться горизонтально и вертикально. Например, единственным способом обработки большего трафика будет обновление оборудования, на котором работает база данных. Это называется масштабированием по вертикали. Масштабирование по вертикали хорошо до определенного предела, после которого даже лучшее оборудование не справляется с обеспечением требуемого трафика.

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

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

Источник