Транзакция (информатика)

Перейти к навигацииПерейти к поиску

Транза́кция (англ. transaction) — группа последовательных операций с базой данных, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще, и тогда она не должна произвести никакого эффекта. Транзакции обрабатываются транзакционными системами, в процессе работы которых создаётся история транзакций.

Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование более чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit — двухфазный протокол фиксации транзакции). Также в некоторых системах реализованы автономные транзакции, или подтранзакции, которые являются автономной частью родительской транзакции.

Пример транзакции

Пример: необходимо перевести с банковского счёта номер 5 на счёт номер 7 сумму в 10 денежных единиц. Этого можно достичь, к примеру, приведённой последовательностью действий:

  1. Прочесть баланс на счету номер 5.
  2. Уменьшить баланс на 10 денежных единиц.
  3. Сохранить новый баланс счёта номер 5.
  4. Прочесть баланс на счету номер 7.
  5. Увеличить баланс на 10 денежных единиц.
  6. Сохранить новый баланс счёта номер 7.

Эти действия представляют собой логическую единицу работы «перевод суммы между счетами», и таким образом, являются транзакцией. Если прервать данную транзакцию, к примеру, в середине, и не аннулировать все изменения, легко оставить владельца счёта номер 5 без 10 единиц, тогда как владелец счета номер 7 их не получит.

Свойства транзакций

Основная статья: ACID

Одним из наиболее распространённых наборов требований к транзакциям и транзакционным системам является набор ACID (Atomicity, Consistency, Isolation, Durability). Требования ACID были в основном сформулированы в конце 1970-х годов Джимом Греем[1]. Вместе с тем существуют специализированные системы с ослабленными транзакционными свойствами[2].

Уровни изоляции транзакций

Основная статья: Уровни изолированности транзакций

В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции — единственный. Однако в реальности, по соображениям производительности и для выполнения некоторых специальных задач, СУБД предоставляют различные уровни изоляции транзакций.

Уровни описаны в порядке увеличения изолированности транзакций и, соответственно, надёжности работы с данными.

  • 0 — Чтение незафиксированных данных (Read Uncommitted) — чтение незафиксированных изменений как своей транзакции, так и параллельных транзакций. Нет гарантии, что данные, изменённые другими транзакциями, не будут в любой момент изменены в результате их отката, поэтому такое чтение является потенциальным источником ошибок. Невозможны потерянные изменения (lost changes), возможны грязное чтение (dirty read), неповторяемое чтение и фантомы.
  • 1 — Чтение зафиксированных данных (Read Committed) — чтение всех изменений своей транзакции и зафиксированных изменений параллельных транзакций. Потерянные изменения и грязное чтение не допускается, возможны неповторяемое чтение и фантомы.
  • 2 — Повторяемое чтение (Repeatable Read, Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесённые параллельными транзакциями после начала своей, недоступны. Потерянные изменения, грязное и неповторяемое чтение невозможны, возможны фантомы.
  • 3 — Сериализуемый (Serializable) — сериализуемые транзакции. Результат параллельного выполнения сериализуемой транзакции с другими транзакциями должен быть логически эквивалентен результату их какого-либо последовательного выполнения. Проблемы синхронизации не возникают.

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

В СУБД уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для одной конкретной транзакции. По умолчанию в большинстве баз данных используется уровень 1 (Read Committed). Уровень 0 используется в основном для отслеживания изменений длительных транзакций или для чтения редко изменяемых данных. Уровни 2 и 3 используются при повышенных требованиях к изолированности транзакций.

Реализация

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

Первые коммерческие СУБД (к примеру, IBM DB2), пользовались исключительно блокировкой доступа к данным для обеспечения свойств ACID. Но большое количество блокировок приводит к существенному уменьшению производительности. Есть два популярных семейства решений этой проблемы, которые снижают количество блокировок:

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

При упреждающей журнализации, используемой в Sybase и MS SQL Server до версии 2005, все изменения записываются в журнал, и только после успешного завершения — в базу данных. Это позволяет СУБД вернуться в рабочее состояние после неожиданного падения системы. Теневые страницы содержат копии тех страниц базы данных на начало транзакции, в которых происходят изменения. Эти копии активизируются после успешного завершения. Хотя теневые страницы легче реализуются, упреждающая журнализация более эффективна[4].

Дальнейшее развитие технологий управления базами данных привело к появлению безблокировочных технологий. Идея контроля над параллельным доступом с помощью временных меток (timestamp-based concurrency control) была развита и привела к появлению многоверсионной архитектуры MVCC. Эти технологии не нуждаются ни в журнализации изменений, ни в теневых страницах. Архитектура, реализованная в Oracle 7.х и выше, записывает старые версии страниц в специальный сегмент отката, но они все ещё доступны для чтения. Если транзакция при чтении попадает на страницу, временная метка которой новее начала чтения, данные берутся из сегмента отката (то есть используется «старая» версия). Для поддержки такой работы ведётся журнал транзакций, но в отличие от «упреждающей журнализации», он не содержит данных. Работа с ним состоит из трёх логических шагов:

  1. Записать намерение произвести некоторые операции
  2. Выполнить задание, копируя оригиналы изменяемых страниц в сегмент отката
  3. Записать, что всё сделано без ошибок

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

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

Firebird вообще не имеет ни журнала изменений, ни сегмента отката, а реализует MVCC, записывая новые версии строк таблиц прямо в активное пространство данных. Так же поступает MS SQL 2005. Теоретически это даёт максимальную эффективность при параллельной работе с данными, но ценой является необходимость «сборки мусора», то есть удаления старых и уже не нужных версий данных.

Обработка транзакций

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

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

Обработка транзакций позволяет нескольким отдельным операциям автоматически быть связанными друг с другом, как единая неделимая транзакция. Системы обработки транзакций гарантирует, что либо все операции в транзакции завершены без ошибок, либо ни одна из них. Если некоторые из операций завершены, но с ошибками, а другие без, системы обработки транзакций дает команду на «откат» всех операций транзакции (в том числе удачных), что означает стирание всех следов операции и восстановление системы до согласованного известного состояния, которое было до начала процесса транзакции. Если все операции транзакции завершены успешно, то транзакция фиксируется в системе, и все изменения в базе данных становятся «постоянными» (commited); транзакции не могут быть отменены, если они уже были сделаны.

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

Транзакции оформлены в строгом хронологическом порядке. Если сделка N+1 намерена коснуться той же части базы данных что и транзакция N, транзакция N+1 не начинается до момента совершения транзакции N. До совершения любых транзакций, все остальные транзакции, затрагивающие ту же часть системы, также должны быть завершены; не может быть никаких «дырок» в последовательности предыдущих транзакций.[6][5]

Методология

Основные принципы всех систем обработки транзакций одинаковы. Однако терминология может варьироваться от одной системы обработки транзакций до другой, и термины, используемые ниже, не обязательно являются универсальными.[7]

Откат (англ. rollback)

Системы обработки транзакций обеспечивают целостность базы данных при помощи записи промежуточного состояния базы данных перед её изменением, а затем, используя эти записи, восстанавливают базу данных до известного состояния, если транзакция не может быть совершена. Например, копии информации в базе данных до её изменения транзакцией, делаются системой перед транзакцией, которая может сделать любые изменения (иногда это называют before image). Если какая-либо часть транзакции не удается до её совершения, эти копии используются для восстановления базы данных в состояние, в котором она находилась до начала транзакции (Rollback).[6]

Прогон (англ. rollforward)

Кроме того, можно вести отдельный журнал всех изменений базы данных (иногда это называется after images); это не требует отката неудачных операций, но это полезно для обновления базы данных в случае отказа базы данных, поэтому некоторые системы обработки транзакций обеспечивают эту функцию. Если база данных отказывает совсем, она должна быть восстановлена из последней резервной. Резервные копии не будут отражать операции, совершенные после её создания. Однако, как только будет восстановлена база данных, журнал after images может быть применен к базе данных (rollforward), чтобы привести её в актуальное состояние. Любые транзакции, которые находятся в процессе на момент сбоя, могут быть свернуты. Результат представляет собой базу данных в известном согласованном состоянии, которое включает результаты всех транзакций, совершенных до момента отказа.[6]

Взаимная блокировка (англ. deadlocks)

В некоторых случаях, две транзакции могут в ходе их обработки пытаться получить доступ к одной и той же части базы данных в одно и то же время, таким образом, что это будет препятствовать их совершению. Например, транзакция А может получить доступ к части Х базы данных, и транзакция В может получить доступ к Y части базы данных. Если в этот момент транзакция А пытается получить доступ к части Y базы данных, в то время как транзакция B пытается получить доступ к части X, возникает ситуация взаимоблокировки, и ни одна транзакция не может быть произведена. Системы обработки транзакций предназначены для обнаружения таких ситуаций. Обычно обе транзакции отменяются и производится откат, а затем они автоматически запускаются в другом порядке, так что взаимоблокировка не повторится. Или иногда, только одна из транзакций, попавших в тупик, отменяется, производится откат, и автоматически повторяется после небольшой задержки.

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

См. также

Примечания

  1. ↑ Gray, Jim. The Transaction Concept: Virtues and Limitations. Proceedings of the 7th International Conference on Very Large Databases: pages 144—154, 1981 Архивная копия от 13 ноября 2008 на Wayback Machine (англ.)
  2. ↑ Advanced Transaction Models and Architectures Архивная копия от 6 января 2009 на Wayback Machine (англ.)
  3. ↑ Семейство алгоритмов ARIES Архивировано 20 сентября 2008 года.
  4. ↑ Gray, J., McJones, P., Blasgen, M., Lindsay, B., Lorie, R., Price, T., Putzolu, F., and Traiger, I. The recovery manager of the System R database manager. ACM Comput. Surv. 13, 2 (June 1981).
  5. ↑ 1 2 Ahmed K. Elmagarmid (Editor), Transaction Models for Advanced Database Applications, Morgan-Kaufmann, 1992, ISBN 1-55860-214-3
  6. ↑ 1 2 3 Gerhard Weikum, Gottfried Vossen, Transactional information systems: theory, algorithms, and the practice of concurrency control and recovery, Morgan Kaufmann, 2002, ISBN 1-55860-508-8
  7. ↑ Philip A. Bernstein, Eric Newcomer, Principles of Transaction Processing, 1997, Morgan Kaufmann, ISBN 1-55860-415-4