Базы данных и СУБД

Поддержка согласованности
Транзакции, Корректность
конкуррентного выполнения
Восстановление после отказов
Согласованность в базах данных
• Целостность, согласованность и
безопасность (integrity, consistency, security)
• Конкурентное использование ресурсов
корректными программами может
привести к некорректным результатам
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
2
Согласованность
• Отказы при выполнении программклиентов, СУБД, операционной системы и
оборудования могут привести к
нарушениям согласованности
• Функция СУБД - гарантировать
согласованность при конкурентном
выполнении и восстановление
согласованности после всех видов отказов
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
3
Пример: конкурентное снятие денег
Read balance
-100
Write balance
БД - Поддержка
согласованности
950
Read balance
950
-200
750
Write balance
750
850
850
http://WWW.math.spbu.ru/user/boris
novikov/courses/
4
Свойства транзакций: ACID
ACID = Atomicity, Consistency, Isolation, Durability
• Атомарность: транзакция либо выполняется
полностью, либо не оставляет никаких
изменений (фиксация или обрыв)
• Согласованность: сохранение согласованного
состояния данных
• Изолированность: Результаты незавершенной
транзакции недоступны для других транзакций
• Постоянство: результаты успешно
завершенной (зафиксированной) транзакции
не могут быть потеряны
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
5
Транзакции, истории и расписания
• База данных: x, y, z, …
• Операции: r(x), w(x)
• Транзакции: конечное частично
упорядоченное множество операций
– r1(x)r1(y) w1(z)
• История: (частично) упорядоченное
множество операций нескольких транзакций
– r1(x)r2(x)w1(x) w2(x) с1 с2
– Операции над одним элементом данных должны
быть упорядочены
• Расписание: префикс истории
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
6
Фиксация и обрыв
• После успешного выполнения всех операций
транзакции приложение должно выполнить
фиксацию (commit)
• Транзакция может быть оборвана явной
операцией приложения (abort) или по
инициативе СУБД
• Фиксации и обрывы реализуют принцип
атомарности
• Каждая транзакция заканчивается ровно
одной из операций commit, abort
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
7
Проблемы, вызванные
конкурентностью выполнения
• Потеря обновлений
– R1(x) r2(x) w1(x) w2(x)
• Несогласованное чтение
– r1(x) r2(x) r2(y) w2(x) w2(y) r1(y)
• Грязное чтение
– R1(x) w1(x) r2(x) w2(y) a1
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
8
Серийное расписание
Расписание, в котором все операции любой
транзакции либо предшествуют, либо
следуют за операциями любой другой
транзакции
Серийное расписание всегда корректно
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
9
Семантика Эрбрана
• Операция чтения возвращает значение, записанное
последней предшествующей операцией записи
• Записанное значение зависит от предшествующих
операций чтения той же транзакции
• H(ri(x)) = H(wj(x)), Tj < Ti
• H(wi(x)) = f(H(ri(x1)), H(ri(x)2)…)
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
10
Эквивалентность и сериализуемость
по конечному состоянию - FSR
• Расписания эквивалентны по конечному
состоянию, если семантики Эрбрана для всех
элементов данных совпадают
• Сериализуемость = эквивалентность серийному
расписанию
• Не предотвращает грязное и несогласованное
чтение
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
11
Эквивалентность и сериализуемость
по видимому состоянию VSR
• Эквивалентность  совпадение видимых и
конечных состояний всех элементов данных
• Сериализуемость  эквивалентность
серийному
• Предотвращает все аномалии
• Проверка на основе отношения «читает из»
• Высокая вычислительная сложность
проверки сериализуемости
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
12
Конфликты
• Пара операций из расписания, такая, что
– Операции принадлежат разным транзакциям
– Работают с одним элементом данных
– По крайней мере одна из двух – операция
записи
Конфликты присутствуют в любом
нетривиальном расписании
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
13
Эквивалентность и сериализуемость
по конфликтам - CSR
• Множество конфликтов расписания содержит
пары, в которых первая операция
предшествует второй (и пары находятся в
конфликте)
• Расписания эквивалентны, если их множества
конфликтов совпадают
• Расписание называется сериализуемым, если
оно эквивалентно по конфликтам серийному
Сериализуемые расписания корректны
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
14
Критерий сериализуемости
• Граф конфликтов (граф сериализуемости)
– Вершины соответствуют транзакциям
– Дуги проводятся для каждого конфликта в
направлении конфликта
• Расписание сериализуемо по конфликтам
тогда и только тогда, когда граф
сериализуемости не содержит контуров
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
15
План доказательства
• Граф конфликтов серийного расписания не
может иметь контуров, потому что
транзакции упорядочены и все дуги
направлены от начала к концу расписания
• Если граф не имеет контуров, эквивалетное
серийное расписание можно построить с
помощью топологической сортировки
графа
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
16
Сериализуемость по
коммутативности
• Любые операции чтения коммутируют
• Любые операции над разными элементами
коммутируют
• Расписание сериализуемо по
коммутативности, если его можно
преобразовать в серийное перестановками
соседних операций
• Сериализуемость по коммутативности
эквивалентна сериализуемости по
конфликтам
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
17
Диспетчер транзакций
• Модель СУБД: диспетчер (транзакций) и
исполнитель запросов
• Требования к диспетчеру транзакций:
– корректность
– производительность
• Фактический уровень (псевдо)паралеллизма
• Процент оборванных транзакций
• Пессимистические и оптимистические протоколы
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
18
Использование замков
• Операции установки lr(x), lw(x) и снятия замка ur(x), uw(x)
• Cовместимость замков: замки для одного элемента
данных несовместимы, если они
– устанавливаются разными транзакциями
– по крайней мере один из них является замком на запись.
• Попытка установки несовместимого замка переводит
транзакцию в состояние ожидания
• Проблемы, связанные с использованием замков:
корректность, тупики, производительность
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
19
Протокол блокирования 2PL
• Для каждой операции необходимо
предварительно установить замок, все
замки должны быть сняты до завершения
транзакции
• Транзакция не может устанавливать новые
замки после того, как она сняла какой-либо
из замков
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
20
Корректность 2PL
• Двухфазный протокол генерирует
расписания, сериализуемые по конфликтам
• Lp1(x) < p(x) <up(x)
• P1(x) < q2(x), r2(y) < s3(y) – конфликты
• Lq2(x) < ur2(y) < ls3(y)
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
21
Тупики
• W2(x) w2(y) r1(y) r2(x)
• Транзакции, попавшие в тупик, должны быть
оборваны
• Граф ожиданий
– Вершины – активные транзакции
– Дуги проводится из ожидающей транзакции в
транзакцию, установившую несовместимые замки
• Тупик имеет место тогда и только тогда, когда в
графе ожиданий имеется контур
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
22
Протокол для деревьев WTL
• База данных структурирована как дерево
• Протокол:
– Все замки – на запись
– Для установки замка необходимо иметь
установленный замок на родительскую
вершину (кроме корня дерева)
– Снятие замков возможно в любое время и не
препятствует установке новых замков
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
23
Корректность WTL
• Граф сериализуемости ацикличен
• Пусть y – родитель x, и w1(x) < w2(x), тогда
w1(y) < w2(y)
• Транзакции сериализуются в том порядке, в
котором они устанавливают замки на корень
• Протокол WTL свободен от тупиков
– Последовательность установки замков
определяется последовательностью их установки
на корень
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
24
Мультигранулярные замки
• База данных представляется как дерево
вложенных объектов
• Замки
–
–
–
–
–
S: совместное использование
X: монопольное использование
IS: совместное использование вложенных гранул
IX: монопольное использование вложенных гранул
SIX: совместное использование гранулы, монопольное
для вложенных гранул
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
25
Мультигранулярный 2PL
• Для установки S/X необходимо иметь IS/IX
на охватывающую гранулу
• Правила совметсимости замков основаны
на коммутативности
• Обычные правила 2PL для всех замков
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
26
Уровни изоляции SQL
•
•
•
•
Read uncommitted
Read committed
Repeatable read
Serializable
• Snapshot isolation- не определяется в
стандарте, но используется в промышелнных
СУБД, иногда вместо сериализуемости
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
27
Проектирование транзакций в
приложении
• Атомарность: вывод результатов только
после фиксации транзакции
• Замки не должны удерживаться в течение
длительного времени
• Недопустимо взаимодействие с
пользователем, пока транзакция не
завершена
• Ослабленные критерии согласованности
при вычислении агрегированных значений
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
28
Optimistic locking
• Управление согласованностью на уровне приложений
• Предотвращает потери обновления в интернетприложениях
• Каждый объект данных (например, строка таблицы)
дополняется атрибутом, хранящим время последнего
обновления
• Данные читаются в режиме read committed и
отображаются пользователю
• Перед обновлением проверяется время обновления
объекта данных, если оно отличается от прочитанного
ранее, операция обновления отвергается
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
29
Optimistic locking: уточнения
• При проверке корректности необходимо
считывать метку всех данных, которые
были использованы или показаны
пользователю
• Проверка только меток обновляемых строк
таблиц недостаточна
• Вместо меток можно проверять значения
всех атрибутов
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
30
Многоверсионные протоколы
• Основаны на временном хранении
нескольких версий элементов данных
• Версии прозрачны для приложения
• Обеспечивают нормальное выполнение
«опоздавших» операций чтения
• Только читающие транзакции никогда не
обрываются
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
31
Сериализуемость для
многоверсионных расписаний
• Многоверсионное расписание должно быть
эквивалентно моноверсионному серийному
расписанию
• Разные версии одного элемента данных не
вызывают конфликты
• Граф сериализуемости пополняется дугами,
описывающими упорядоченность операций
записи разных версий одного элемента
• Сериализуемость по конфликтам 
ацикличность пополненного графа
сериализуемости
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
32
Snapshot Isolation
• Замки только для операций записи
• Попытка установки несовместимого замка приводит
к обрыву транзакции
• Многоверсионность
• Не обеспечивает даже сериализуемость по
конечному состоянию
• Предотвращает наиболее тяжелые виды аномалий
• Обладает свойством монотонности
r(1(x) r2(x) r1 (y) r2 (y) w1 (x) w2 (y) – snapshot, ноне FSR
r1 (x) r1 (y) r2 (x) w1 (y) r2 (y) w2 (y) – CSR, но не snapshot
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
33
Оптимистический протокол
управления транзакциями
• Фазы выполнения транзакции
– Чтение
– Проверка
– запись
• Проверка назад: проверяются конфликты с
зафиксированными транзакциями
• Проверка вперед: проверяются конфликты с
активными транзакциями
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
34
Объектная модель транзакций
• Абстрактные операции над объектами
• Транзакция: конечное дерево с помеченными
вершинами
• > Корень помечен идентификатором
транзакции
• > Некорневые вершины помечены
операциями и параметрами
• > Листья помечены операциями read/write
страничной модели.
Определен частичный порядок на листьях (как
в страничной модели).
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
35
Пример объектной транзакции
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
36
Пример объектного расписания
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
37
Серийные объектные расписания
• Расписание называется серийным, если его корни
полностью упорядочены и вершины на каждом
уровне полностью упорядочены и изолированы.
• Вершина р и ее поддерево называются
изолированными, если:
– (1)
все вершины, кроме предков и потомков р
либо предшествуют,
либо следуют за потомками р и
– (2)
каждый уровень в поддереве р полностью
упорядочен.
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
38
Расслаиваемые расписания
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
39
Пример корректного расписания
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
40
Расписание на слоях
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
41
Достаточное условие корректности
Если расписания на всех слоях расслоенного
объектного расписания s сериализуемы по
конфликтам с сохранением порядка (е OCSR),
то s редуцируемо по коммутативности.
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
42
Использование объектной модели
• Страницы и логические записи
– Замки и защелки
• Строки таблиц и индексы
• Вложенные транзакции
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
43
Восстановление
после отказов
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
44
Типы отказов
• Отказы приложений/транзакции:
транзакции обрываются
• Отказы системы: функционирование
возобновляется после рестарта и
восстановления согласованности БД
• Разрушение носителя: рестарт,
восстановление с резервной копии,
восстановление согласованности
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
45
Восстановление оборванных
транзакций: откат
• Обрывы транзакций могут быть вызваны
ошибками при выполнении приложений
или невозможностью выполнить
транзакцию сериализуемым образом
• Операции обрыва $a$ можно заменить на
выполнение отката для всех операций
записи w-1, включаемых в расписание в
обратном порядке с последующей
фиксацией
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
46
Восстановимость
• Восстановимость расписаний: транзакции
должны фиксироваться до того, как их
результаты используются другими
транзакциями
• Пример невосстановимого расписания
– W1(x) w2(x) c2 a1
• S2L (Двухфазный протокол с удержанием
замков на запись до конца транзакции)
гарантирует восстановимость
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
47
Восстановление после системных
отказов
• Необходим рестарт сервера БД
• Для того, чтобы восстановление было
возможным, необходимо вести журнал
обновлений
• При нормальной работе БД все изменения
записываются в журнал
• При рестарте журнал используется для
повторения операций и для отката
незавершенных транзакций
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
48
Ведение журнала
• Журнал ведется последовательно
• Опережающая запись в журнал (WAL, writeahead log)
• Регистрируются операции записи, начала и
конца транзакций
• Каждая запись может (должна) содержать
данные отката (undo) и «наката» (redo)
• При фиксации запись журнала обязательно
выталкивается на диск
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
49
Что нужно сделать при
восстановлении
• Определить, какие транзакции были
зафиксированы до отказа и какие были
активными (не завершены)
• Если необходимо, повторить изменения
зафиксированных транзакций
• Оборвать незавершенные до отказа
транзакции (выполнить откат)
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
50
Запись обновлений базы данных
• Только при фиксации (force, no steal)
– Данные undo и redo не нужны
• Только после фиксации (no force, no steal)
– Необходимы только данные redo
• Обязательно до фиксации (force, steal)
– Требуются только undo
• Полностью асинхронно (no force, steal)
– Требуются undo и redo
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
51
Алгоритм восстановления при
рестарте
• Фаза просмотра: найти все
зафиксированные и активные транзакции
(прямой просмотр журнала)
• Фаза наката (redo): при прямом просмотре,
выполнить все операции зафиксированных
транзакций
• Фаза отката (undo): обратный просмотр
журнала, откат всех операций
незавершенных транзакций
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
52
Завершение восстановления
• После завершения фазы отката необходимо
– Записать на диск все измененные блоки БД
– После записи БД можно очистить журнал
• Возобновить нормальную работу системы
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
53
Корректность алгоритма
восстановления
• Восстанавливает согласованное состояние
(такое, как после всех зафиксировнных
транзакций)
• Допускает многократные рестарты
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
54
Алгоритм восстановления Redo
History
• Анализ: обнаружение транзакций,
подлежащих обрыву
• Redo: повторное выполнение всех
операций , записанных в журнал
• Undo: откат незафиксированных
транзакций
• Первые две фазы можно совместить
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
55
Сравнение алгоритмов
восстановления
• Redo History : выполняется больше
операций наката
• Фаза отката может быть совмещена с
нормальной обработкой новых транзакций
(необходимы замки на обновления
оборванных транзакций)
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
56
Контрольные точки
• Для сокращения времени восстановления
записываются контрольные точки
• При записи контрольной точки все
измененные блоки записываются на диск и
делается запись о контрольной точке в
журнале
• При рестарте фазу наката можно начинать с
последней контрольной точки
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
57
Контрольные точки малого веса
• Запись журнала содержит информацию об
активных транзакциях и список грязных
страниц
• Запись грязных страниц выполняется
асинхронно
• Все страницы, включенные в контрольную
точку, должны быть записаны до следующей
контрольной точки
• Восстановление можно начинать с
предпоследней контрольной точки
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
58
Характеристики защищенности
• Доступность
• Надежность
• Выживаемость
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
59
Защита от разрушения носителя
• Создание резервных копий
– Экспорт данных
– Offline backup
– Копирование средствами операционной
системы
– Online backup
• Специальное оборудование (зеркальные
дисковые системы)
• Серверы в горячем резерве (stand-by)
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
60
Копии в горячем резерве
• Основной и дополнительные серверы
• Распространение изменений
– Синхронное внесение изменений
– Повторение транзакций
– Пересылка и повторение журнала
– Накат по журналу с задержкой
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
61
Кластер с зеркальными дисками
Сервис базы данных
Экземпляр
сервера БД
Экземпляр
сервера БД
БД
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
62
Сервер в горячем резерве
Основной
сервер БД
Запасной сервер
БД
БД
БД
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
63
Распределенные базы данных
• Цели создания распределенных систем:
– Доступность
– Надежность
• Типы распределенных систем:
– Фрагментация
• Вертикальная
• Горизонтальная
– Раскопирование (replication)
Select * from dept@remote.server
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
64
Горизонтальная фрагментация:
разделы
• Большая таблица может быть распределена
на несколько серверов
• Фрагмент, размещенный на одном сервере
– partition
• Разделы полезны и в централизованных
системах
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
65
Транзакции в распределнных
системах
• Глобальная транзакция состоит из
нескольких локальных подтранзакций
• Для обеспечения корректности необходима
координация локальных диспетчеров
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
66
Недостаточность локальной
сериализуемости
• Все локальные подтранзакции должны
фиксироваться в одном и том же порядке
• Локальные транзакции могут изменить
упорядоченность
r2(x) r1 (x) w1(x) c1 r3 (y) w3(y) c3
T3 < T2 < T1
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
r2 (y) c2
67
Протокол 2PL в распределенных
системах
• Ведение замков
– Центральный сервер
– Раскопированный сервер
• Необходима доступность управления
замками
• Низкая производительность
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
68
Протокол на основе меток времени
TS
• Транзакции помечаются метками времен
своего начала
• Каждый элемент хранит метки записавшей
и последней читавшей транзакций
• Чтение запрещается, если элемент данных
записан после начала транзакции
• Запись отвергается, если элемент прочитан
после начала транзакции
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
69
Корректность протокола TS
• Транзакции сериализуются в порядке меток
времени начала транзакций
• В распределенных системах
– Метки времени для данных можно проверять
локально
– Применение протокола затруднено из-за
необходимости синхронизации часов
• Leslie Lamport
– LaTeX
– Часы для распредленных систем
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
70
Протокол двухфазной фиксации 2PC
(two-phase commit)
• Координатор транзакции
• Для обрыва глобальной транзкции достаточно
обрава любой из локальных
• Фиксация (нормальная работа)
– Фаза подготовки
• Координатор рассылает сообщение «подготовиться»
• ответ «готов к фиксации»
– Фаза завершения
• Координатор рассылает «фиксируем»
• Ответ: «Зафиксирована»
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
71
2PC - восстановление
• После рестарта необходимо обработать
транзакции в состоянии «готова», но не
«зафиксирована»
• Для выяснения судьбы транзакции
необходимо обратиться к координатору
• Если координатор не отвечает, может знать
любой из участников
• В некоторых случаях решение невозможно
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
72
Раскопированные БД
• Каждая копия предоставляет
согласованную версию базы данных
• Простейший протокол: одновременное
обновление всех копий
• Высокая доступность по чтению, низкая по
обновлениям
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
73
Мажоритарный протокол
• При нарушении связности обновления
разрешаются в том случае, если компонента
связности содержит больше половины копий
• Чтение разрешается в любом случае, для
обновления необходимо предварительно
получить последнее состояние элемента
данных
• Корректность: для любого элемента данных
последнее состояние имеется не менее чем на
половине копий
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
74
Отложенная согласованность
(eventual consistency)
• Асинхронное отложенное распространение
обновлений раскопированных данных
• Выполнение обновлений и фиксация
транзакций выполняются без задержек
• Любые обновления могут быть потеряны,
последний записавший выигрывает
• Ответственность за согласованность
перекладывается на приложение
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
75
Схемы распределенных БД
• В SQL можно использовать только объекты,
определенные в схеме
• Построение глобальной схемы затруднено
из-за ее сложности
• В распределенной системе не должно быть
централизованных структур
• Решение: в схему любого узла
распределенной системы могут включаться
объекты, определенные в других системах
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
76
Распределенные системы на основе
промышленных СУБД
• Связи между серверами баз данных
Select * from person@remote.db
• Прозрачность: использование синонимов и
представлений
• Фрагментация: partitioned tables
• Раскопирование: материализованные
представления, триггеры
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
77
Ограниченность классической
модели транзакций
• ACID свойства могут быть слишком
ограничительны
• Атомарность: нет возможности сохранить
хотя бы часть результатов больших
вычислений
• изоляция: невозможно получить результаты
до окончания транзакции
• В распределенных системах необходима
доступность всех участников транзакции
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
78
Примеры классов приложений
• Продолжительные активности с участием
человека
• Совместная работа над общими данными
• Распределенные системы с мобильными
компонентами
• Системы очень большого размера
(требуются другие критерии
согласованности)
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
79
Расширенные модели транзакций
• Вложенные (nested) транзакции
– Подтранзакции выполняются конкурентно
– Обрыв подтранзакции не влечет обрыва
родительской
– Понятие компенсации: при отсутствии
изоляции откат невозможен
• Долгоживущие транзакции и саги
– цепочки атомарных транзакций, компенсации
• Потоки работ (workflow)
БД - Поддержка
согласованности
http://WWW.math.spbu.ru/user/boris
novikov/courses/
80