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

Развитием RDA-модели стала модель сервера базы данных. Ее сердцевиной является механизм хранимых процедур. В отличие от RDA-модели, определенные для конкретной предметной области информационной системы события, правила и процедуры, описанные средствами языка SQL, хранятся вместе с данными на сервере системы и на нем же выполняются. Иначе говоря, прикладной компонент полностью размещается и выполняется на сервере системы. Схематично DBS-модель приведена на рис. 2.5.

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

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

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

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

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

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

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

В еще не устоявшейся до конца терминологии по моделям и технологиям “Клиент-сервер” RDA-модель характеризуют еще как модель с так называемыми “толстыми”, а DBS-модель и AS-модель как модели, соответственно, с “тонкими” клиентами. По критерию звеньев системы RDA-модель и DBS-модель называют двухзвенными (двухуровневыми) системами, а AS-модель трехзвенной (трехуровневой) системой.

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

Мониторы транзакций

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

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

потерянные изменения;

“грязные” данные;

неповторяющиеся чтения.

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

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

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

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

 синхронизационные захваты (блокировки) объектов базы данных;

 временные метки объектов базы данных.

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

Наиболее распространенным вариантом первого подхода является реализация двухфазного протокола синхронизационных захватов (блокировок) объектов базы данных – 2PL (Two-Phase Locks). В соответствии с данным протоколом выполнение транзакции происходит в два этапа. На первом этапе (первая фаза) перед выполнением любой операции транзакция запрашивает и накапливает захваты необходимых объектов в соответствующем режиме. После получения и накопления необходимых захватов (блокировок) осуществляется вторая фаза – фиксация изменений (или откат по соображениям целостности данных) и освобождение захватов.

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

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

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

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

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

 проверяется, не закончилась ли транзакция, первой “пометившая” объект;

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

 если первая транзакция не закончилась, то проверяется конфликтность операций (напомним, что конфликтно любое сочетание, кроме “чтение-чтение”);

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

 если операции конфликтны, то далее происходит откат более поздней транзакции и выполняется операция более ранней (старшей) транзакции, а после ее завершения объект помечается меткой более молодой транзакции и цикл действий повторяется.

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

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

Статьи к прочтению:

Лекция 22: Реляционная база и модель данных

Похожие статьи: