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

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

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

Распределение функций компонентов приложения в моделях клиент — сервер представлено на рис. 1.3.

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

Достоинство данной модели состоит в том, что приложение разделено на два взаимодействующих процесса. При этом сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки данной модели:

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

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

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

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

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

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

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

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

5. Совершенствование контроля типов данных СУБД. В насто­ящее время СУБД контролирует синтаксически только стандарт­но-допустимые типы данных, т. е. которые определены в DDL (Data Definition Language) — языке описания данных, являющемся ча­стью SQL. Однако в реальных предметных областях существуют данные, которые несут в себе еще и семантическую составляющую, например координаты объектов или единицы измерений.

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

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

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

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

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

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

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

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

• осуществляет мониторинг событий, связанных с выполнени­ем разработанных триггеров;

• обеспечивает автоматическое срабатывание триггеров при воз­никновении связанных с ними событий;

• обеспечивает исполнение внутренней программы каждого триггера;

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

• запускает хранимые процедуры из триггеров;

• возвращает требуемые данные клиенту;

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

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

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

Архитектура трехуровневой модели приведена на рис. 1.6. Про­межуточный уровень может содержать один или несколько серве­ров приложений.

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

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

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

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

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

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

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

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

Затем функции управления данными были выделены в само­стоятельную группу — сервер. Однако при этом модель взаимо­действия пользователя с сервером соответствовала структуре свя­зей между таблицами баз данных «один к одному» (рис. 1.7), т.е. сервер обслуживал запросы только одного пользователя (клиен­та), а для обслуживания нескольких клиентов нужно было запус­тить соответствующее число серверов.

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

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

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

единственный обладает монополией на управле­ние данными и взаимодействует одновременно со многими кли­ентами (рис. 1.8). Логически каждый клиент связан с сервером от­дельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура, получившая название многопотоко­вой односерверной (multi-threaded), позволяет значительно умень­шить нагрузку на операционную систему, возникающую при ра­боте большого числа пользователей (trashing).

Кроме того, обеспеченная в данной модели возможность вза­имодействия многих клиентов с одним сервером позволяет в пол­ной мере использовать разделяемые объекты (начиная с открытых файлов и заканчивая данными из системных каталогов), что зна­чительно уменьшает потребность в памяти и общее число процес­сов операционной системы. Например, в модели «один к одному» СУБД создает 100 копий процессов для 100 пользователей, а си­стеме с многопотоковой архитектурой для этого понадобится толь­ко один серверный процесс.

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

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

Однако и такая архитектура не лишена недостатков, так как здесь в систему добавляется новый слой, размещаемый между клиентом и сервером, что увеличивает потребность в ресурсах на поддержку баланса загрузки серверов (load balancing) и ограни­чивает возможности управления взаимодействием между клиен­том и сервером. Во-первых, становится невозможно направить запрос от конкретного клиента конкретному серверу; во-вторых, серверы становятся равноправными, так как нет возможности устанавливать приоритеты для обслуживания запросов.

Рис. 1.10. Многопотоковая мультисерверная архитектура

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

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

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

Типы параллелизма. Рассматривают следующие программно-аппаратные способы распараллеливания запросов: горизонталь­ный, вертикальный и смешанный (рис. 1.11).

Рис. 1.11. Типы параллелизма

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

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

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

Рис. 1.12. Схема выполнения запроса при вертикальном параллелизме

Рис. 1.13. Схема выполнения запроса при смешанном параллелизме

Действительно, рассмотрев для примера следующую последо­вательность операций реляционной алгебры:

1.R5 = Rl [А, С];

2.R6 = R2[A,B,D];

3.R7 = R5[A>12S];

4. RS = R5 [A]R6,

увидим, что первую и третью операции можно объединить и вы­полнить параллельно со второй операцией, а затем с полученными результатами выполнить последнюю — четвертую — операцию.

Общее время выполнения подобного запроса, конечно, будет существенно меньше, чем при традиционном способе выполне­ния последовательности из четырех операций (рис. 1.12).

Смешанный параллелизм является гибридом горизонтального и вертикального (рис. 1.13).

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

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