Транзакции. Параллельное исполнение. Уровни изоляции

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

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

Проблемы при параллельной обработке транзакций

Косая запись

Аномалия "косой записи" — аномалия, которая возникает при ситуации когда мы из двух разных транзакций пытаемся изменить одни и те же данные (например, ячейки А и В) так, что общий первая транзакция затронет ячейку A, а вторая — ячейку В и мы получим неконсистентный результат.

Пример возникновения аномалии:

Было:

t_1 = 50
t_2 = 50
Δ = 60

Транзакция Т1:

if t_1 + t_2 ≥ Δ begin
  t_1 = t_1 − Δ
end if

Транзакция Т2:

if t_1 + t_2 ≥ Δ begin
  t_2 = t_2 − Δ
end if

Стало:

t_1 = -10
t_2 = -10

В таком примере видно, что мы не могли выполнить обе транзакции так, чтобы сохранился инвариант данных, следовательно мы получаем аномалию. При этом стоит отметить, что такая пара транзакций успешно завершится, поскольку каждая из них проверит неизменность данных только в тех ячейкх базы, которые были изменены в ходе транзакции (t_1 для T1, t_2 для T2).

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

Уровень изоляции Serializable

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

create transaction isolation level serializable;
-- your query goes here
commit;

Уровень изоляции Snapshot

Название этого уровня изоляции на русский язык можно перевести как слепок, что, на самом деле, приводит к тому, что если две транзакции совершаются прааллельно, то каждой из них выдают свой "слепок" базы данных в какой-то определенный момент. После выполнения всех операций со слепком базы данных (удаление/запись/изменение/чтение) все изменения "вливаются" в основную версию базы. Транзакция будет завершена успешно, если в основной версии базы данных к моменту окончания транзакции не было изменений ни в одной из ячеек базы, измененных в ходе транзакции, не было изменений за время ее выполнения. Таким образом, если две транзакции выполняли операции над разными частями базы данных, то конфликтов у нас не возникнет и соответствующее слияние произойдет безболезненно. Если же изменялись одни и те же данные, мы можем получить аномалию "косой записи" (см. выше). Стоит отметить, что формально такого уровня изоляции нет в стандарте языка SQL.

Уровень изоляции Repeatable read

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

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

См. также

• Транзакции. Параллельное исполнение. Блокировки
• Транзакции. Восстановление. Классический алгоритм