Транзакции базы данных - как они работают?

Question

Я пытаюсь узнать больше о транзакциях в базе данных, нашел эмпирическое правило ACID для записи транзакций и подумал над несколькими вопросами.

эмпирическое правило:

Транзакция должна быть:

1. Атомная - это одна единица работы и не зависит от предыдущей и следующие транзакции.
2. Согласовано - данные либо зафиксированы, либо откатаны, нет «Промежуточный» случай, когда что-то имеет обновлено, а что-то не так.
3. Изолировано - ни одна транзакция не видит промежуточные результаты текущего сделка.
4. Durable - значения сохраняются, если данные были зафиксированы, даже если система падает сразу после.

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

1. Как база данных обрабатывает параллельные транзакции, в то же время поддерживая правило Atomic?
   • Есть ли очередь транзакций, которая обрабатывается по порядку?
   • Как обрабатывается длительная транзакция, которая задерживает все остальные?
2. Выполняются ли обновления таблиц в памяти, поэтому, если перед фиксацией происходит сбой, база данных не изменяется?
   • Или есть какие-то промежуточные таблицы, которые обновляются, чтобы пережить такой сбой?
3. Во время выполнения транзакции все доступы для чтения и записи к уязвимым таблицам запрещены?
   • Или база данных разрешит запись, но транзакция перезапишет все изменения при фиксации?

Answer 1

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

   http://www.amazon.co.uk/Databases-Transaction-Processing-Application-Oriented-Approach/dp/0201708728/ref=sr_1_3?ie=UTF8&s=books&qid=1281609705&sr=8-3

2. Зависит от уровня входа в базу данных. Если сохраняются строгие журналы записи, то в случае сбоя системы база данных может быть возвращена в согласованное состояние.

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

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

Answer 2

Несколько недоразумений в ваших определениях:

Атомная - это одна единица работы и не зависит от предыдущих и последующих транзакций.

Более правильное определениеатомарности не будет упоминать какие-либо "предыдущие или последующие" транзакции.Атомарность - это свойство отдельной транзакции, взятой само по себе, а именно то, что при окончательном обратном отсчете либо все ее действия сохраняются, либо ни одного вообще.Другими словами, недопустимо, чтобы "только половина транзакции" сохранялась.

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

Согласованно - данные либо фиксируются, либо откатываются, нет «в«между», когда что-то было обновлено, а что-то нет.

Эта интерпретация совершенно неверна.Согласованный означает, что процессор транзакций (в данном случае ядро ​​СУБД) не может оставить систему (базу данных) в состоянии нарушения любого объявленного ограничения, о котором он (процессор транзакций) знает.См., Например, «Введение в системы баз данных», гл. 16.

Изолировано - никакая транзакция не видит промежуточных результатов текущей транзакции.

Nitpicking: нет транзакции кроме текущего разрешено видеть промежуточные состояния (состояния, на самом деле не результаты).Кроме того, обратите внимание, что «Уровни изоляции» механизмов обработки транзакций обычно определяют степень, в которой свойство I может быть нарушено!

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

Но это свойство тоже немного размыто из-за возможности вложенных транзакций.Даже если внутренняя транзакция зафиксирована и завершена, содержащая транзакция может отменить эту фиксацию сама по себе, полностью откатившись.

Answer 3

Фактические детали, вероятно, будут в некоторой степени зависеть от того, какой это сервер БД, но эта статья может вас заинтересовать: Шпаргалка по обработке транзакций

Answer 4

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

• A в конечном итоге основывается на блокировке или других элементарных операциях для обмена данными, измененными в транзакции (созданными в I solation) с исходными данными в общем представлении.

  Как база данных обрабатывает параллельные транзакции, в то же время поддерживая атомарное правило?

  См. I Солирование.

• C oncistency опирается на более фундаментальные A tomicity и I свойства и больше распространяется на прикладной уровень, а не внутренне относится к службе базы данных.

  Обеспечение правил (когда A tomicity и I solation на месте) довольно простое, если выполнить их для измененных данных.

  Это может вызвать философские споры. Но, на мой взгляд, в нетривиальных случаях проверка всех условий в связанных данных до их окончательной фиксации может быть реализована в логике приложения целиком или в прикладных процедурах на уровне базы данных, что не делает их специфичными для базы данных. Минимум, который должна обеспечить служба базы данных, - это возможность читать ранее записанные данные без ошибок.

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

  См. I Solation.

  Обратите внимание, что согласованность C в ACID является чисто логической, статической и не имеет уровней или уровней, связанных с распространением данных, предложенных позже по теореме CAP .

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

  Во время выполнения транзакции все права на чтение и запись в уязвимые таблицы запрещены?

  Как правило, если в одной транзакции изменяется только копия данных, другие тривиально не увидят этих изменений. Однако уровни изоляции могут отличаться.

  Это единственное свойство ACID , которое может иметь несколько уровней и степеней, не будучи просто черно-белым.

  В конечном счете, соляция I является самой глубокой в ​​своей реализации и возможными компромиссами среди всех свойств ACID . И в деталях об этом свойстве - первая самая важная тема о том, что сервис базы данных гарантирует (даже в контексте теорема CAP где компромиссы снова развиваются вокруг согласованности отдельных представлений распределенных данных).

• D Жизнеспособность на самом деле скорее SLA .

  Какой срок службы («записанный на поврежденный диск» или «избыточно распределенный по ОЗУ серверов, работающих на плутонии») обычно определяется вне обычной логики транзакций.

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

Два аспекта реализации, критически важных для производительности (о которых ACID явно не заботится):

• Обнаружение конфликта

  Должен быть способ (эффективно) обнаруживать конфликтующие изменения, сделанные одновременно в другой транзакции.

  Одной из крайних точек является блокировка всего, что не требует обнаружения конфликта (возможного параллелизма).

  Еще одна крайняя точка - оптимистичный параллелизм (по крайней мере, частично).Тогда необходимо знать, были ли одновременные изменения вообще.Это может быть реализовано с помощью счетчиков (номеров версий) или контрольных сумм для различных объектов в базе данных.Затем это становится тесно связанным с реализацией I Solation.

• Процедура отката

  Это требует поддержания структур данныхисходные значения и их измененные копии (журналы транзакций) для отмены изменений.Опять же, это очень сильно связано с реализацией I .

Некоторая дополнительная краткая информация:

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

Answer 5

Согласовано - данные либо фиксируются, либо откатываются, нет промежуточного случая, когда что-то было обновлено, а что-то нет.

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

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

1. Оба счета содержат свои начальные остатки;
2. Сумма вычитается из остатка на одном счете, но не добавляется к другому;
3. Сумма добавляется к остатку на одном счете, но не вычитается из другого;
4. Оба счета держат свои окончательные остатки.

Во всех четырех состояниях могут соблюдаться ограничения целостности системы.Но второе и третье не соответствуют разумному взгляду на систему - деньги должны быть где-то .Таким образом, это не согласованные состояния, в то время как начальное и конечное состояния согласованы.

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

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

Answer 6

"Каков вердикт по вложенным транзакциям"

Вердикта нет.Вложенные транзакции существуют.ACID свойства существуют.Они вынуждены сосуществовать.Там нет абсолютов.Конечно, не к кислоте.