Карпова Т.С. Базы данных: модели, разработка, реализация

Подождите немного. Документ загружается.

Модели

серверов

баз

данных

211

ся как

независимый, поэтому если один клиент

сформировал

запрос, который

был

только

что

выполнен

другим серверным процессом

для

другого

клиента,

то

запрос

тем не

менее выполнялся повторно.

такой модели весьма сложно

обеспечить взаимодействие серверных

процессов.

Эта

модель самая простая,

исторически

она

появилась первой.

Рис.

10.8.

Взаимодействие

пользовательских

клиентских процессов

модели

«один-к-одному»

Проблемы,

возникающие

модели

«один-к*одному»,

решаются

архитектуре

«систем

выделенным

сервером»,

который способен обрабатывать

Запросы

от

многих

клиентов. Сервер единственный обладает монополией

на

управление

данными

взаимодействует одновременно

со

многими

клиентами

(рис. 10.9).

Логически

каждый клиент

связан

сервером

отдельной

нитью

(«thread»),

или

потоком,

по

которому пересылаются запросы. Такая архитектура получила

на-

звание многопотоковой

односерверной

(«multi-threaded»).

Она

позволяет значительно уменьшить нагрузку

на

операционную систему, воз-

никающую

при

работе большого числа пользователей

(«trashing»).

Рис.10.9.

Многопотоковая односерверная архитектура

Кроме

того, возможность взаимодействия

одним

сервером многих клиентов

позволяет

полной мере использовать разделяемые объекты (начиная

открытых

файлов

кончая

данными

из

системных

каталогов),

что

значительно уменьшает

потребности

памяти

общее

число

процессов

операционной

системы. Напри-

мер,

системой

архитектурой

«один-к-одному»

будет создано

100

копий

про-

цессов

СУБД

для

ЮО

пользователей, тогда

как

системе

многопотоковой,

архи-

тектурой

для

этого

понадобится только один

серверный

процесс,

Однако

такое

решение

имеет

свои

недостатки.

Так как

сервер

может

выполнять-

ся

только

на

одном

процессоре,

возникает естественное ограничение

на

примене-

212

Глава

10.

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

ние

СУБД

для

мультипроцессорных платформ. Если компьютер имеет,

напри-

мер,

четыре"

процессора,

то

СУБД

одним сервером используют только

один

из

них,

не

загружая

оставшиеся

три.

некоторых

системах

эта

проблема решается

вводом

промежуточного

диспет-

чера. Подобная архитектура называется архитектурой виртуального

сервера

(«virtual

server»)

(рис.

10.10).

этой

архитектуре

клиенты

подключаются

не

реальному

серверу,

а к

проме-

жуточному

звену,

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

функции

диспетчеризации запросов

актуальным серверам.

этом случае

нет

ограниче-

ний

на

использование многопроцессорных платформ. Количество

актуальных

серверов

может быть согласовано

количеством процессоров

системе.

Однако

и эта

архитектура

не

лишена

недостатков,

потому

что

здесь

систему

добавляется новый слой, который размещается между

клиентом

сервером,

что

увеличивает

трату

ресурсов

на

поддержку

баланса

загрузки

актуальных серве-

ров

(«load

balancing»)

ограничивает возможности управления взаимодействи-

ем

«клиент—сервер*.

Бо-первых,

становится

невозможным

направить запрос

от

конкретного

клиента конкретному серверу,

во-вторых,

серверы становятся рав-

ноправными

— нет

возможности устанавливать приоритеты

для

обслуживания

запросов.

Рис.

10.10. Архитектура

виртуальным сервером

Подобная

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

как

аналог

банка,

где

имеется несколько окон кассиров,

специальный

банков-

ский

служащий

—

администратор зала (диспетчер) направляет каждого

вновь

пришедшего

посетителя

(клиента)

свободному

кассиру (актуальному серверу).

Система работает нормально, пока

все

посетители

равноправны

(имеют

равные

приоритеты),

однако стоит лишь

появиться

посетителям

высшим

приоритетом,

которые

должны

обслуживаться

специальном

окне,

как

возникают

проблемы.

Учет

приоритета

клиентов

особенно

важен

системах оперативной

обработки

транзакций,

однако именно

эту

возможность

не

может

предоставить

архитекту-

ра

систем

диспетчеризацией.

Современное

решение

проблемы

СУБД

для

мультипроцессорных

платформ

за-

ключается

возможности запуска нескольких

серверов

базы

данных,

в-том

чис-

ле и на

различных

процессорах. "При этом каждый

из

серверов

должен

быть

многопотоковым. Если

эти два

условия

выполнены,

то

есть

основания

говорить

многопотоковой архитектуре

несколькими

серверами,

представленной

па

рис,

10,11.

Модели

серверов

баз

данных

213

Она

также может быть названа

многонитевой

мультисерверной

архитектурой.

Эта

архитектура связана

вопросами распараллеливания

выполнения

одного

пользовательского запроса

несколькими

серверными

процессами.

Рис.

10.11.

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

Существует

несколько возможностей

распараллеливания

выполнения

запроса.

этом случае пользовательский запрос разбивается

на ряд

подзапросов, кото-

рые

могут выполняться

параллельно,

результаты

их

выполнения

потом объе-

диняются

общий результат выполнения

запроса.

Тогда

для

обеспечения опе-

ративности

выполнения

запросов

их

подзапросы могут быть направлены

отдельным серверным

процессам,

потом полученные результаты

объединены

общий результат (см.

рис

10.12).

данном

случае

серверные

процессы

не яв-

ляются

независимыми

процессами,

такими,

как

рассматривались

ранее.

Эти

серверные

процессы

принято

называть нитями

(treads),

управление

нитями

множества запросов пользователей требует

дополнительных

расходов

от

СУБД,

однако

при

оперативной

обработке информации

хранилищах

данных

такой

подход

наиболее

перспективен.

214

Глава

10.

Распределенная

обработка

данных

Типы

параллелизма

Рассматривают несколько путей распараллеливания запросов.

Горизонтальный

параллелизм. Этот параллелизм возникает тогда, когда

храни-

мая

в БД

информация

распределяется

по

нескольким

физическим

устройствам

хранения

—

нескольким дискам.

При

этом информация

из

одного

отношения

разбивается

на

части

по

горизонтали (см. рис.

10.13).

Этот

вид

параллелизма

иногда называют

распараллеливанием

или

сегментацией

данных.

параллель-

ность

здесь

достигается путем выполнения одинаковых

операций,

например

фильтрации,

над

разными физическими хранимыми данными.

Эти

операции

мо-

гут

выполняться параллельно разными процессами,

они

независимы. Результат

выполнения

целого

запроса складывается

из

результатов выполнения отдель-

ных

операций.

Время

выполнения

такого

запроса

при

соответствующем

сегментировании

дан-

ных

существенно меньше,

чем

время

выполнения

этого

же

запроса традицион-

ными

способами одним процессом.

Вертикальный

параллелизм.

Этот

параллелизм

достигается

конвейерным

вы-

полнением

операций,

составляющих

запрос пользователя. Этот подход требует

серьезного усложнения

модели

выполнения

реляционных операций

ядром

СУБД.

Он

предполагает,

что

ядро

СУБД

может

произвести

декомпозицию

за-

проса,'базируясь

на его

функциональных компонентах,

и при

этом

ряд

подза-

просов

может выполняться

параллельно,

минимальной связью между

отдель-

ными

шагами

выполнения

запроса.

Действительно,

если

мы

рассмотрим,

например,

последовательность

операций

реляционной

алгебры:

R5-R1

[

A.CJ

R6-R2

[A.B.D]

R5CA

128]

R5CAJR6.

то

операции первую

третью можно объединить

выполнить параллельно

операцией два,

затем выполнить

над

результатами последнюю четвертую

операцию.

Общее время выполнения

подобного

запроса,

конечно,

будет существенно

мень-

ше,

чем при

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

последовательности

из

четырех

операций (см. рис.

10.13).

третий

вид

параллелизма

является

гибридом двух ранее

рассмотренных

(см.

рис.

10,14).

Наиболее

активно

применяются

все

виды

параллелизма

OLAP-приложешях,

где эти

методы позволяют

существенно

сократить время

выполнения

сложных

запросов

над

очень большими объемами данных.

Модели серверов

баз

данных

215

ГЛАВА

Модели

транзакций

Транзакцией

называется последовательность

операций,

производимых

над ба-

зой

данных

переводящих базу данных

из^одного

непротиворечивого

(согласо-

ванного)

состояния

другое

непротиворечивое (согласованное) состояние.

Транзакция

рассматривается

как

некоторое неделимое действие

над

базой

дан-

ных,

осмысленное

точки зрения пользователя.

В то же

время

это

логическая

единица

работы

системы.

Рассмотрим несколько примеров.

Что

может быть

на-

звано

транзакцией?

Кем

определяется,

какая

последовательность

операций

над

базой данных составляет транзакцию?

Конечно,

однозначно именно разработ-

чик

определяет, какая

последовательность

операций составляет единое целое,

то

есть транзакцию. Разработчик приложений

или

хранимых

процедур определяет

это

исходя

из

смысла обработки данных, именно семантика совокупности опе-

раций

над

базой данных, которая моделирует

точки зрения разработчика

неко-

торую

одну

неразрывную работу,

составляет

транзакцию.

Допустим, выделим

работу

по

вводу

данных

поступивших

книгах,

новых книгах, которых

не

было

раньше

библиотеке.

Тогда

эту

операцию

можно

разбить

па две

последователь-

ные: сначала

ввод

данных

книге

— это

новая строка

таблице

BOOKS,

потом

ввод данных

обо

всех

экземплярах

новой книги

— это

ввод

набора

новых

строк

таблицу

EXEMPLAR

количестве,

равном

количеству поступивших экземпляров

книги. Если

эта

последовательность работ будет

прервана,

то

наша база

данных

не

будет соответствовать реальному

объекту,

поэтому желательно выполнять

ее

как

единую работу

над

базой

данных.

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

принятием заказа

фирме

па

изготовле-

ние

компьютера.

Компьютер состоит

из

комплектующих, которые сразу резер-

вируются

за

данным заказом

момент

его

формирования,

Тогда

транзакцией

будет

вся

последовательность

операций, включающая следующие операции;

впод

нового заказа

со

всеми реквизитами заказчика;

изменения

состояния

для

всех выбранных комплектующих

на

складе

на

«за-

нято»

привязкой

их к

определенному заказу;

подсчет стоимости заказа

формированием

платежного

документа типа

вы-

ставляемого счета

оплате;

включение

нового

заказа

производство.

Свойства

транзакций

Способы завершения транзакций

217

точки зрения

работника,

это

единая последовательность операций;

если,она

будет

прервана,

то

база данных потеряет свое

целостное

состояние.

Еще

один пример, который весьма характерен

для

учебных заведений.

При

дли-

тельной болезни преподавателя

или при его

увольнении перед администраци-

ей

кафедры

встает

задача

перераспределения

всей

нагрузки,

которую

ведет

пре-

подаватель,

по

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

несколь-

ко:

чтение лекций

проведение

занятий

по

текущему расписанию, руководство

квалификационными работами бакалавров, руководство дипломными проекта-

ми

специалистов,

руководство магистерскими диссертациями,

индивидуальная

научно-исследовательская

работа

со

студентами.

И для

каждого

вида

нагрузки

необходимо

найти

исполнителей

назначить

им

дополнительную нагрузку.

Свойства

транзакций.

Способы

завершения

транзакций

Существуют

различные модели

транзакций,

которые могут быть классифициро-

ваны

на

основании различных

свойств,

включающих

структуру

транзакции,

па-

раллельность внутри

транзакции,

продолжительность

и т. д,

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

чипы

транзакций; плоские

или

клас-

сические транзакции, цепочечные транзакции

вложенные

транзакции.

Плоские,

или

традиционные,

транзакции,

характеризуются четырьмя

классиче-

скими

свойствами:

атомарности,

согласованности,

изолированности, долговеч-

ности (прочности)

—

ACID

(Atomicity,

Consistency, Isolation, Durability).

Ино

гда

традиционные

транзакции

называют

ACID-транзакциями.

Упомянутые выше

свойства означают следующее:

Свойство

атомарности

(Atpmicity) выражается

том,

что

транзакция

долж-

на

быть выполнена

целом

или

не

выполнена

вовсе.

Свойство

согласованности

(Consistency)

гарантирует,

что по

мере

выполнения

транзакций

данные переходят

из

одного согласованного

состояния

другое

-»

транзакция

не

разрушаег

взаимной

согласованности

данных,

Свойство

изолированности

(Isolation) означает,

что

конкурирующие

за до-

ступ

базе данных

транзакции

физически обрабатываются

последовательно,

изолированно друг

от

друга,

но для

пользователей

это

выглядит

так,

как

буд-

то они

выполняются параллельно.

Свойство

долговечности

(Durability) трактуется следующим образом: если

транзакция

завершена успешно,

то те

изменения

данных,

которые были

ею

произведены,

не

могут быть потеряны

ни

при

каких обстоятельствах (даже

случае

последующих

ошибок).

Возможны

два

варианта завершения

транзакции.

Если

все

операторы выполне-

ны

успешно

и в

процессе

выполнения

транзакции

не

произошло

никаких

сбоев

программного

или

аппаратного обеспечения, транзакция

фиксируется,

Фиксация транзакции

—

ото

действие,

обеспечивающее

запись

на

диск

измене-

нии

базе

данных,

которые были сделаны

процессе выполнения

транзакции,

218

Глава

11.

Модели

транзакций

До тех пор

пока транзакция

не

зафиксирована, допустимо аннулирование этих

изменений,

восстановление базы данных

в то

состояние,

котором

она

была

на

момент

начала транзакции. Фиксация транзакции означает,

что все

результаты

выполнения

транзакции становятся постоянными.

Они

станут видимыми дру-

гим

транзакциям только после того,

как

текущая транзакция будет зафиксиро-

вана.

До

этого момента

все

данные, затрагиваемые транзакцией, будут «видны»

пользователю

состоянии

на

начало текущей транзакции.

Если

процессе выполнения транзакции

случилось

нечто такое,

что

делает

не-

возможным

ее

нормальное

завершение,

база данных

должна

быть возвращена

исходное состояние. Откат транзакции

— это

действие,

обеспечивающее

анну-

лирование

всех

изменений

данных,

которые были

сделаны

операторами

SQL

теле текущей незавершенной транзакции.

Каждый

оператор

транзакции выполняет свою

часть

работы,

но для

успешно-

го

завершения

всей

работы

целом требуется безусловное завершение всех

их

операторов. Группирование операторов

транзакции сообщает СУБД,

что вся

эта

группа должна быть выполнена

как

единое целое, причем такое выполнение

должно

поддерживаться автоматически.

стандарте

ANSI/ISO

SQL

определены модель транзакций

функции операто-

ров

COMMIT

ROLLBACK,

Стандарт определяет,

что

транзакция начинается

первого

SQL-оператора, инициируемого пользователем

или

содержащегося

программе,

изменяющего текущее состояние

базы

данных.

Все

последующие SQL-операто-

ры

составляют

тело

транзакции. Транзакция завершается одним

из

четырех воз-

можных путей (рис.

11.1);

оператор

COMMIT

означает успешное завершение транзакции;

его

использова-

ние

делает

постоянными

изменения, внесенные

базу данных

рамках теку-

щей

транзакции;

оператор

ROLLBACK

прерывает транзакцию,

отменяя

изменения, сделанные

базе

данных

рамках этой транзакции; новая транзакция начинается непосредст-

венно

после

использования

ROLLBACK;

успешное завершение программы,

которой была инициирована текущая

транзакция, означает успешное завершение транзакции (как будто

был ис-

пользован

оператор

COMMIT);

ошибочное завершение программы прерывает

транзакцию

(как будто

был ис-

пользован

оператор

ROLLBACK).

этой модели каждый оператор, который изменяет состояние

БД,

рассматрива-

ется

как

транзакция,

поэтому

при

успешном завершении этого оператора

БД пе-

реходит

новое устойчивое состояние.

первых версиях коммерческих

СУБД

была реализована модель

транзакций

ANSI/ISO,

дальнейшем

СУБД

SYBASE была реализована

расширенная

мо-

дель транзакций, которая включает

еще ряд

дополнительных

операций.

моде-

ли

SYBASE

используются

следующие

четыре

оператора;

Оператор

BEGIN TRANSACTION

сообщает

начале

транзакции,

отличие

от

ми-

дели

стандарте

ANSI/ISO,

где

начало транзакции

неявно

задастся

первым

Свойства

транзакций.

Способы завершения транзакций

219

оператором

модификации

данных,

модели

SYBASE

начало

транзакции

за-

дается

явно

помощью

оператора

начала

транзакции.

Оператор

COMMIT

TRANSACTION

сообщает

об

успешном

завершении

транзакции.

Он

эквивалентен

оператору

COMMIT

модели стандарта

ANSI/ISO.

Этот

опе-

ратор,

как и

оператор

COMMIT,

фиксирует

все

изменения, которые производи-

лись

в БД в

процессе

выполнения транзакции.

Оператор

SAVE TRANSACTION

создает внутри

транзакции

точку

сохранения,

ко-

торая

соответствует

промежуточному состоянию

БД,

сохраненному

на мо-

мент

выполнения этого оператора.

операторе

SAVE

TRANSACTION

может стоять

имя

точки сохранения. Поэтому

Ходе

выполнения

транзакции

может быть

запомнено

несколько

точек

сохранения,

соответствующих нескольким

про-

межуточным

состояниям.

Оператор

ROLLBACK

имеет

две

модификации. Если

этот

оператор используется

без

дополнительного параметра,

то он

интерпретируется

как

оператор отката

всей

транзакции,

то

есть

этом случае

он

эквивалентен

оператору отката

ROLLBACK

модели ANSI/ISO. Если

же

оператор отката

имеет

параметр

и за-

писан

виде

ROLLBACK

В,

то он

интерпретируется

как

оператор

частичного

от-

ката транзакции

точку сохранения

В.

Принципы

выполнения

транзакций

расширенной

модели

транзакций

пред-

ставлены

на

рис,

11.2.

На

рисунке

операторы

помечены номерами, чтобы

нам

удобнее было проследить

ход

выполнения транзакции

во

всех допустимых

слу-

чаях.

Транзакция

начинается

явным оператором начала транзакции, который

имеет

нашей

схеме

номер

идет

оператор

который

является

оператором

поиска

и не

меняет текущее состояние

БД,

следующие

за ним

операторы

3 и

переводят

базу

данных

уже в

новое состояние. Оператор

сохраняет

это

новое

промежуточное

состояние

БД и

помечает

его как

промежуточное

состояние

точке

А,

следуют

операторы

6 и 7,

которые переводят базу

данных

в по-

вое

состояние.

оператор

сохраняет

это

состояние

как

промежуточное

со-

стояние

точке

В.

Оператор

выполняет

ввод

новых

данных»

оператор

проводит

некоторую

проверку

условия

если

условие

выполнено,

то

пылал-