75,2.40 Сериализация транзакций в распределенных субд. Двухфазная фиксация изменений. Многоверсионный вариант двухфазного протокола синхронизации

Рассмотрим вариант широко известного двухфазного протокола синхронизации транзакций (multiversion two-phase locking protocol, MV2PL), адаптированного для применения в версионной базе данных. Будем различать три типа версии элемента данных:

• завершенные (commited) — версии, созданные транзакциями, которые уже успешно закончили свою работу;

• текущая версия (current) — последняя из завершенных версий;

• незавершенные (uncommited) — версии, созданные транзакциями, которые еще находятся в работе.

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

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

1. если операция не является финальной, то: a) операция r(x) выполняется незамедлительно; ей сопоставляется последняя из завершенных к данному моменту версий x (или последняя из незавершенных версий x во втором варианте алгоритма); b) операция w(x) выполняется только после завершения транзакции, записавшей последнюю версию x.

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

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

76,2.41 Сериализация транзакций в распределенных субд на основе временных меток. Временные метки

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

Временную метку, полученную транзакцией ti в начале ее работы, будем обозначать как ts(ti), операцию чтения транзакцией ti элемента данных x как ri(x). Для обозначения того, что транзакция ti читает версию элемента данных x, созданную транзакцией tk, будем писать ri(xk), для обозначения того, что транзакция ti записывает версию элемента данных x, будем использовать запись wi(x). Опишем алгоритм работы планировщика MVTO.

Планировщик преобразует операцию ri(x) в операцию ri(xk), где xk — это версия элемента x, помеченная наибольшей временной меткой ts(tk), такой что ts(tk) <= ts(ti).

1) Операция wi(x) обрабатывается планировщиком следующим образом:

a) если планировщик уже обработал действие вида rj(xk), такое что ts(tk) < ts(ti) < ts(tj), то операция wi(x) отменяется, а ti откатывается;

b) в противном случае wi(x) преобразуется в wi(xi).

3) Завершение транзакции ti (commit) откладывается до того момента, когда завершатся все транзакции, записавшие версии данных, прочитанные ti.

Последний шаг нужен только в том случае, когда хотят предотвратить «грязное» чтение.