10
правок
Изменения
initial commit
В контексте баз данных параллельное исполнение возникает, когда два или более клиента пытаются обратиться к базе данных. При проектировании СУБД необходимо учесть проблемы, которые могут возникнуть при параллельной обработке транзакций. Транзакция {{---}} это логическая единица работы, в ходе которой может выполняться некоторый набор действий с объектами базы данных.
Очевидно, самое простое, что можно сделать {{---}} сделать исполнение всех наших запросов полностью упорядочиваемыми. К сожалению, у такого подхода есть большой минус {{---}} это слишком долго. Вследствие этого появились уровни изоляции, которые позволяют архитектору базы указать, при каких транзакциях нам действительно нужно, например, полное упорядочивание, а при каких нам будет выгоднее пожертовать некоторыми гарантиями для ускорения выполнения.
==Проблемы при параллельной обработке транзакций==
===Косая запись===
Аномалия "косой записи" {{---}} аномалия, которая возникает при ситуации когда мы из двух разных транзакций пытаемся изменить одни и те же данные (например, ячейки А и В) так, что общий первая транзакция затронет ячейку 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===
===Уровень изоляции Read committed===
===Уровень изоляции Read uncommitted===
==См. также==
* [[Транзакции. Параллельное исполнение. Блокировки]]
* [[Транзакции. Восстановление. Классический алгоритм]]
Очевидно, самое простое, что можно сделать {{---}} сделать исполнение всех наших запросов полностью упорядочиваемыми. К сожалению, у такого подхода есть большой минус {{---}} это слишком долго. Вследствие этого появились уровни изоляции, которые позволяют архитектору базы указать, при каких транзакциях нам действительно нужно, например, полное упорядочивание, а при каких нам будет выгоднее пожертовать некоторыми гарантиями для ускорения выполнения.
==Проблемы при параллельной обработке транзакций==
===Косая запись===
Аномалия "косой записи" {{---}} аномалия, которая возникает при ситуации когда мы из двух разных транзакций пытаемся изменить одни и те же данные (например, ячейки А и В) так, что общий первая транзакция затронет ячейку 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===
===Уровень изоляции Read committed===
===Уровень изоляции Read uncommitted===
==См. также==
* [[Транзакции. Параллельное исполнение. Блокировки]]
* [[Транзакции. Восстановление. Классический алгоритм]]
