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

Здравейте на всички. Аз съм Владислав Родин. В момента съм ръководител на курса „Архитектор на високи натоварвания“ в OTUS и също така участвам в курсовете по архитектура на софтуера.

Освен преподаването, както можехте да забележите, пиша авторски материали за блога на OTUS в Хабр и днешната статия искам да посвятя на старта на курса «PostgreSQL», за който в момента е отворена регистрация.

Въведение

В миналия път Ние говорихме за това, че транзакциите в базите данни решават две задачи: осигуряване на отказоустойчивост и достъп до данните в конкурентна среда. За пълното изпълнение на тези задачи транзакцията трябва да притежава свойствата на ACID. Днес ще говорим подробно за буквата I (изолация) в тази абревиатура.

Изолация

Изолацията решава задачата за достъп до данните в конкурентна среда, фактически предоставяйки защита от race condition. В идеалния случай изолацията означава сериализация, което е свойство, осигуряващо, че резултатът от изпълнението на транзакциите паралелно е същият, какъвто би бил, ако те бяха изпълнявани последователно. Основният проблем с това свойство е, че е много трудно да бъде осигурено технически и следователно оказва значително влияние върху производителността на системата. Именно затова изолацията често се отслабва, приемайки рисковете от появата на определени аномалии, за които ще става дума по-долу. Възможността за възникване на тези аномалии точно така характеризира нивото на изолация на транзакциите.

Най-известните аномалии са: dirty read, non-repeatable read, phantom read, но всъщност има още 5: dirty write, cursor lost update, lost update, read skew, write skew.

Dirty write

Същността на аномалията е, че транзакциите могат да презаписват незакомичени данни.

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

Аномалията се лекува доста лесно: поставяме блокировка на записа преди началото на записа, което забранява на другите транзакции да променят записа, докато блокировката не бъде свалена.

Dirty read

Dirty read означава прочитане на незакомичени данни.

Проблемите възникват, когато на базата на извадка е необходимо да се предприемат действия или да се вземат решения.

За коригиране на аномалията може да се наложи да се сложи блокировка за четене, но това сериозно ще удари производителността. Много по-лесно е да се каже, че за rollback на транзакцията първоначалното състояние на данните (преди започването на записа) определено трябва да бъде запазено в системата. Защо да не четем от там? Това е достатъчно евтино, затова повечето бази данни по подразбиране премахват dirty read.

Lost update

Lost update означава загубени обновления, и преводът доста точно отразява същността на проблема:

Всъщност, резултатът от транзакцията Т2 беше отменен. Тази ситуация се коригира с явни или неявни блокировки на записа. Тоест, или просто актуализираме записа, и тогава възниква неявна блокировка, или изпълняваме select for update, предизвиквайки появата на блокировка за четене и запис. Обърнете внимание на това, че такава операция е достатъчно опасна: с нашето "невинно" четене, блокираме други четения. Някои бази предлагат по-безопасно select for share, позволяващо четене на данни, но не допускащо тяхната промяна.

Cursor lost update

За по-фин контрол базите могат да предлагат други инструменти, например курсор. Курсорът е структура, съдържаща набор от редове и позволяваща итерация по тях. declare cursor_name for select_statement. Съдържанието на курсора е описано с select.

Защо е нужен курсор? Работата е там, че някои бази данни предлагат блокировка на всички записи, избрани с select (read stability), или само на записа, на който в момента е курсорът (cursor stability). При cursor stability се извършва кратка блокировка, което намалява броя на блокировките, в случай че итерираме по голяма извадка от данни. Затова аномалията lost update се откроява за курсора отделно.

Non-repeatable read

Non-repeatable read се състои в това, че по време на изпълнението на нашата транзакция 2 последователни четения на една и съща запис водят до получаване на различни резултати, защото друга транзакция се намесила между тези две четения, променила е нашите данни и е била комитната.

Защо изобщо е проблем? Представете си, че целта на транзакцията T2 на изображението е да избере всички стоки, чиято цена е по-малка от 150 у.е. Някой друг е актуализирал цената до 200 у.е. Така зададеният филтър не е сработил.

Тези аномалии спират да се появяват при добавяне на двуфазни блокировки или при използване на механизма MVCC, за което бихме искали да говорим отделно.

Фантомно четене

Фантомно се нарича четене на данни, които са били добавени от друга транзакция.

Например, можем да наблюдаваме неправилна селекция на най-евтиния продукт при възникване на тази аномалия.

Да се избавим от фантомните четения вече е доста сложно. Обичайната блокировка не е достатъчна, тъй като не можем да блокираме това, което още не съществува. 2PL-системите използват предикативна блокировка, докато MVCC-системите отменят транзакции, които могат да бъдат нарушени от вставка. И двата механизма са доста тежки.

Четене с наклон

Четенето с наклон възниква, когато работим с няколко таблици, съдържанието на които трябва да се променя съгласувано.

Предположим, имаме таблици, представляващи публикации и тяхната метаинформация:

Една транзакция чете от таблиците, другата ги променя:

В резултат на изпълнението на транзакция T1, при публикацията title = Good, а updated_by = T2, което е някакво несъответствие.

Всъщност, това е non-repeatable read, но в рамките на няколко таблици.

За да се поправи, T1 може да наложи блокировки на всички редове, които ще чете, което няма да позволи на транзакция T2 да променя информацията. В случай на MVCC транзакция T2 ще бъде отменена. Защита от тази аномалия може да бъде важна, ако използваме курсори.

Писане с наклон

Тази аномалия също е по-лесно да се обясни с пример: предположим, че в нашата система поне един доктор трябва да бъде на дежурство, но и двамата доктори са решили да отменят дежурството си:

Аномалията довела до това, че нито един от докторите няма да излезе на дежурство. Защо се случи така? Защото транзакцията проверяваше условие, което може да бъде нарушено от друга транзакция, а поради изолацията не видяхме това изменение.

Това е същото non-repeatable read. Като вариант, select-ите могат да наложат блокировки на тези записи.

Записи на записване и записване с наклон са комбинации от предишни аномалии. Можем да разгледаме записването с наклон, което по същество е фантомно четене. Нека разгледаме таблица, в която има имена на служители, техните заплати и проектите, по които работят:

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

Причината за възникване на проблема е точно същата, както при фантомното четене.

Изводи

Снижаването на нивото на изолация на транзакциите в базата данни е компромис между безопасността и производителността, при избора на това ниво следва да се подходи в зависимост от потенциалните рискове за бизнеса при възникване на различни аномалии.

Научете повече за курса.

Източник: habr.com