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

Здравейте всички. Владислав Родин е във връзка. В момента съм ръководител на курса за High Workload Architect курс в OTUS и също така преподавам курсове по софтуерна архитектура.

В допълнение към преподаването, както може би сте забелязали, пиша оригинален материал за блога OTUS на Habré и ​​искам да съвпадна с днешната статия, за да съвпадне със стартирането на курса "PostgreSQL", който е отворен за записване в момента.

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

въведение

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

Изолация

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

Най-известните аномалии са: мръсно четене, неповтарящо се четене, фантомно четене, но всъщност има още 5: мръсно записване, загубена актуализация на курсора, загубена актуализация, изкривяване на четене, изкривяване на запис.

Мръсно писане

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

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

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

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

Мръсно четиво

Мръсното четене означава четене на незадължителни данни.

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

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

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

Загубена актуализация

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

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

Всъщност резултатът от транзакция T2 беше обърнат. Тази ситуация може да бъде коригирана чрез явни или неявни блокировки за запис. Тоест, ние или просто актуализираме записа и след това възниква имплицитно заключване, или изпълняваме изберете за актуализация, което води до блокиране на четене и запис. Моля, имайте предвид, че такава операция е доста опасна: с нашето „невинно“ четене ние блокираме други четения. Някои бази данни предлагат по-сигурни изберете за споделяне, което позволява данните да бъдат четени, но не и модифицирани.

Курсорът загуби актуализация

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

Защо ви е необходим курсор? Факт е, че някои бази данни предлагат заключване на всички записи, избрани от select (стабилност на четене), или само на записа, върху който в момента се намира курсорът (стабилност на курсора). Със стабилността на курсора се реализира кратко заключване, което ни позволява да намалим броя на заключванията, ако повторим голяма извадка от данни. Следователно загубената аномалия на актуализацията е изолирана отделно за курсора.

Неповторяемо четене

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

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

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

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

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

Phantom е четене на данни, добавени от друга транзакция.

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

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

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

Прочетете изкривяване

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

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

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

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

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

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

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

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

Напишете накриво

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

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

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

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

Това е същото неповторимо четене. Като алтернатива избраните могат да поставят ключалки върху тези записи.

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

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

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

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

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

Данни

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

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

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

Добавяне на нов коментар