Нива на изолация на транзакция с примери за PostgreSQL
Въведение
Стандартът SQL описва четири нива на изолация на транзакциите - Read uncommited (Четене на некомитирани данни), Read committed (Четене на ангажирани данни), Repeatable read (Повтарящо се четене) и Serializable (Serializable). Тази статия ще разгледа жизнения цикъл на четири паралелни транзакции с нива на изолацияRead committed иSerializable.
Следните специални условия за четене на данни са разрешени за нивото на изолация, ангажирано за четене:
Неповтарящо се четене – Транзакцията чете отново същите данни като преди и открива, че са били променени от друга транзакция (която е приключила след първото четене).
Фантомно четене – Транзакцията изпълнява повторно заявка, която връща набор от редове за някакво условие, и установява, че наборът от редове, които отговарят на условието, се е променил поради транзакцията, която е приключила междувременно.
Що се отнася до Serializable, това ниво на изолация е най-стриктното и няма феномен на четене на данни.
ACID или 4 транзакционни свойства
Преди да започнем да разглеждаме нивата на изолация на транзакциите с няколко думи, нека си припомним основните изисквания за транзакционна система.
Атомарност (атомарност) - изразява се в това, че сделката трябва да бъде завършена като цяло или изобщо да не е завършена.
Постоянство (съгласуваност) - гарантира, че докато се извършват транзакциите, данните преминават от едно съгласувано състояние в друго, т.е. транзакцията не може да разруши взаимната съгласуваност на данните.
Изолация (изолация) - локализирането на потребителските процеси означава, че транзакциите, конкуриращи се за достъп до базата данни, се обработват физически последователно, изолирани една от друга, но запотребители, изглежда, че работят паралелно.
Издръжливост (трайност) - устойчивост на грешки - ако транзакцията е завършена успешно, тогава тези промени в данните, които са направени от нея, не могат да бъдат загубени при никакви обстоятелства.
Прочетете ангажираното ниво на изолация
Нивото на изолация на PostgreSQL по подразбиране е Read Committed. Това ниво на изолация винаги ви позволява да видите промените, направени от успешно завършени транзакции в останалите отворени транзакции паралелно. В транзакция, работеща на това ниво, заявката SELECT (без клаузата FOR UPDATE/SHARE) вижда само данните, които са били ангажирани преди началото на заявката; той никога няма да види необвързани данни или промени, направени по време на изпълнение на заявка от едновременни транзакции. По същество заявката SELECT вижда моментна снимка на базата данни в момента, в който заявката започне да се изпълнява. Въпреки това, SELECT вижда резултатите от промените, направени по-рано в същата транзакция, дори ако те все още не са ангажирани. Също така имайте предвид, че два последователни оператора SELECT може да видят различни данни дори в рамките на една и съща транзакция, ако някои други транзакции се ангажират след първия SELECT.
Същността на нивото на изолация Read Committed е показана на диаграма 1.
Забележка: Таблицата вече съдържа запис с първата версия на данните (v1). Моля, приемете командите SELECT v1; - като команда, връщаща v1 данни, и UPDATE v1 до v2; - като команда за актуализиране на данни от първата версия към втората.
Забележка. Диаграмата не показва действието на заявка INSERT. В рамките на тованиво на изолация, редовете, добавени, например, в стъпка 3, в първата транзакция, ще бъдат ВИДИМИ за други транзакции след завършването на първата транзакция.
Частичната изолация на транзакция, предоставена от режима Read Committed, е приемлива за много приложения. Този режим е бърз и лесен за използване, но не е подходящ за всички случаи. Приложенията, които извършват сложни заявки и промени, може да се нуждаят от по-последователно представяне на данни, като Serializable.
Сериализирано ниво на изолация
Изолацията на серийно ниво осигурява безпрепятствен достъп до базата данни за транзакции с SELECT заявки. Но за транзакции със заявки UPDATE и DELETE, нивото на изолация Serializable не позволява модифициране на един и същи ред в рамките на различни транзакции. С изолация на това ниво всички транзакции се обработват така, сякаш всички са стартирани последователно (една след друга). Ако две едновременни транзакции се опитат да актуализират един и същ ред, това няма да е възможно. В този случай PostgreSQL ще принуди транзакцията, втората и всички следващи, които се опитаха да променят реда, да бъдат отменени (връщане назад - ROLLBACK).
Същността на нивото на изолация на Serializable е показана на диаграма 2.
Забележка. Диаграмата не показва действието на заявка INSERT. В рамките на това ниво на изолация редовете, добавени например в стъпка 3, в първата транзакция, няма да бъдат достъпни за втората, третата и четвъртата транзакция след завършването на първата транзакция. Освен това диаграмата не показва резултата от ВЪРТАНЕ (стъпки 8 и 11). Ако Втората и Третата транзакции направиха нещопромени върху незаключени данни, тогава всички тези промени няма да бъдат ангажирани, тъй като транзакциите са неуспешни (същността на свойството е атомарност).
Нивото на изолация Serializable гарантира, че всички данни, засегнати от транзакция, няма да бъдат променени от други транзакции. На това ниво се изключва появата на "фантоми", така че стават възможни сложни конкурентни операции. На практика това ниво на изолация се изисква в счетоводните системи.
За транзакции, съдържащи само изрази SELECT, използването на ниво на изолация Serializable е оправдано, когато не искате да виждате промените, направени от едновременно завършени транзакции по време на операцията на текущата транзакция.
Аномалия в сериализацията (загубена актуализация)
Друг феномен на четене на данни се описва от факта, че резултатът от успешен ангажимент на група транзакции се оказва несъвместим с всички възможни опции за изпълнение на тези транзакции на свой ред.
Документацията на уебсайта на PostgreSQL PRO казва, че Read Committed позволява „Аномалия на сериализацията“. Вътрешната Wikipedia, без да настоява, че таблицата се отнася конкретно за PostgreSQL, пише, че Read Commited предотвратява аномалията на сериализацията. Английската Уикипедия мълчи за този феномен на четене на данни. Но немската Wikipedia цитира феномена „Загубени актуализации“ в тяхната версия на таблицата, което показва, че Read Committed може да не е обект на загубени актуализации с допълнителна защита чрез курсора (Стабилност на курсора). Украинската Уикипедия поддържа българската версия на статията, испанската Уикипедия поддържа английската версия на статията. Английската документация за PostgreSQL е същата като документацията от уебсайта на PostgreSQL PRO.
Стабилността на курсора разширява поведението на блокиране на нивото READ COMMITED доSQL курсори чрез добавяне на нова операция за четене (Fetch) към курсора rc (което означава четене на курсора, т.е. четене на курсора) и изискване заключването да бъде установено върху текущия елемент на курсора. Заключването се задържа, докато курсорът се премести (докато текущият му елемент се промени) или се затвори, евентуално чрез операция за ангажиране. Естествено, четене на транзакция на курсора може да промени текущия ред (wc е запис на курсора), в който случай заключването на запис на този ред ще бъде задържано, докато транзакцията се ангажира, дори след преместване на курсора и след това извличане на следващия ред.
Заключение
Разбирането на нивата на изолация на транзакциите е важен аспект от обработката на данни във всяка многопотребителска СУБД. Нивата на изолация имат добре дефинирани характеристики и поведение. По-високите нива на изолация намаляват възможността за паралелна обработка и увеличават риска от блокиране на процеса. Следователно правилното използване на нива в зависимост от задачите на приложенията винаги е избор на разработчика, в зависимост от изискванията за осигуряване на логическа цялост на данните, за скорост и за възможност за паралелна многопотребителска обработка.
Литература
В анкетата могат да участват само регистрирани потребители. Влез Моля.