Транзакции в PostgreSQL

Реляционная теория и SQL позволяет абстрагироваться от конкретной реализации СУБД, но есть одна непростая проблема: как обеспечить параллельную работу множества сессий (concurrency), которые модифицируют данные, так, чтобы они не мешали друг другу ни с точки зрения чтения, ни с точки зрения записи и обеспечивали целостность данных (consistency) и их надежность (durability)?

Ответ – транзакционные системы OLTP – OnLine Transaction Processing. Они отвечают следующему принципу ACID:

• Atomicity – атомарность
• Consistency – согласованность
• Isolation – изолированность
• Durability – долговечность

Соответственно, транзакция (transaction) это:

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

Всё было бы хорошо, но что делать с блокировками и сбоями?

Для этого придуманы следующие принципы:

ARIES – Algorithms for Recovery and Isolation Exploiting Semantics. Алгоритмы эффективного восстановления после сбоев.

Использует следующие механизмы:

• logging – логирование
• undo – сегменты отката транзакций
• redo – сегменты проигрывания транзакций после сбоя
• checkpoints – система контрольных точек

MVCC – MultiVersion Concurrency Control. Конкурентный контроль мультиверсионности. Использует следующие механизмы:

• copy-on-write – создаётся копия старых данных при записи или модификации
• каждый пользователь работает со снимком БД
• вносимые пользователем изменения не видны другим до фиксации транзакции
• практически не использует блокировок (только одна – писатель блокирует писателя, если они пытаются работать с одной записью)
• или ручная блокировка при вызове команды select for update

Механизм реализации MVCC в PostgreSQL.

Данные хранятся поблочно и посмотрим, из чего состоит один блок:

В самом начале идёт служебный блок, состоящий из:

• пары идентификаторов транзакций по 4 байта
• ряда информационных байтов
• пары информационных масок
• пустой битовой карты для будущего использования в следующих версиях PostgreSQL
• данных (более подробно будем рассматривать в следующих темах).

Если рассматривать подробно, то заголовок состоит из:

• xmin – идентификатор транзакции, которая создала данную версию записи
• xmax – идентификатор транзакции, которая удалила данную версию записи
• cmin – порядковый номер команды в транзакции, добавившей запись
• cmax – номер команды в транзакции, удалившей запись

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

• Insert – добавляется новая запись с xmin = txid_current() и xmax = 0
• Update – в старой версии записи xmax = txid_current(), то есть делается delete, добавляется новая запись с xmin = txid_current() и xmax = 0, то есть делается insert
• Delete – в старой версии записи xmax = txid_current()

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

Для фиксации или отмены транзакции нам нужно рассмотреть ещё дополнительные атрибуты строки – infomask содержит ряд битов, определяющих свойства данной версии:

• xmin_commited, xmin_aborted – xmin подтверждён или отменён
• xmax_commited, xmax_aborted – xmax подтверждён или отменён

Важно отметить поле ctid – ссылка на следующую, более новую, версию той же строки. У самой новой, актуальной, версии строки ctid ссылается на саму эту версию. Номера ctid имеют вид (x,y): здесь x – номер страницы, y – порядковый номер указателя в массиве

Каждая транзакция может завершиться:

•  успешно – после команды commit, для этого, в зависимости от типа операции, проставляются биты xmin_commited, xmax_commited
• неуспешно из-за, например, ошибки доступа к данным или вызове команды rollback.

При неуспешном завершении нам нужно откатить все изменения, выполненные этой транзакцией. При этом в случае с PostgreSQL нам практически не нужно ничего делать – будут установлены биты подсказки xmin_aborted, xmax_aborted. Сам номер xmax при этом остаётся в странице, но смотреть на него уже никто не будет.

Так что операции как коммита, так и роллбэка транзакции в PostgreSQL одинаково быстры.

В следующей статье мы посмотрим на практике, как работают транзакции.