Salutare tuturor. Vladislav Rodin este în legătură. În prezent, sunt conducătorul de curs pentru cursul High Workload Architect la OTUS și predau și cursuri de arhitectură software.
Pe lângă predare, după cum probabil ați observat, scriu material original pentru blogul OTUS de pe Habré și vreau să coincidă cu articolul de astăzi pentru a coincide cu lansarea cursului , care este deschis pentru înscriere chiar acum.
Introducere
В am vorbit despre faptul că tranzacțiile în baze de date servesc la rezolvarea a două probleme: asigurarea toleranței la erori și accesul la date într-un mediu competitiv. Pentru a îndeplini pe deplin aceste sarcini, tranzacția trebuie să aibă proprietăți ACID. Astăzi vom vorbi în detaliu despre scrisoare eu (izolare) în această abreviere.
Izolație
Izolarea rezolvă problema accesării datelor într-un mediu competitiv, oferind în esență protecție împotriva condițiilor de cursă. În mod ideal, izolarea înseamnă serializare, care este o proprietate care asigură că rezultatul executării tranzacțiilor în paralel este același ca și cum ar fi executate secvențial. Principala problemă cu această proprietate este că este foarte dificil de furnizat din punct de vedere tehnic și, ca urmare, are un impact semnificativ asupra performanței sistemului. De aceea izolarea este adesea slăbită, acceptând riscurile anumitor anomalii, despre care se vor discuta mai jos. Posibilitatea apariției anumitor anomalii caracterizează tocmai nivelul de izolare a tranzacției.
Cele mai cunoscute anomalii sunt: citire murdară, citire nerepetabilă, citire fantomă, dar de fapt mai sunt 5: scriere murdară, actualizare pierdută prin cursor, actualizare pierdută, citire anormală, scriere înclinată.
Scrie murdară
Esența anomaliei este că tranzacțiile pot suprascrie datele necommitate.
Această anomalie este periculoasă nu numai pentru că datele pot intra în conflict după comiterea ambelor tranzacții (ca în imagine), ci și pentru că atomicitatea este încălcată: deoarece permitem suprascrierea datelor necommitate, nu este clar cum să anulăm o tranzacție fără a afecta alta. .
Anomalia poate fi tratată destul de simplu: atașăm un lacăt la înregistrare înainte de a începe înregistrarea, interzicând altor tranzacții să schimbe înregistrarea până când blocarea este eliminată.
Lectură murdară
Citirea murdară înseamnă citirea datelor necommitate.
Problemele apar atunci când acțiunile sau deciziile trebuie luate pe baza eșantionului.
Pentru a corecta anomalia, puteți atașa o blocare de citire, dar acest lucru va afecta foarte mult performanța. Este mult mai simplu să spunem că pentru o tranzacție rollback, starea inițială a datelor (înainte de începerea înregistrării) trebuie salvată în sistem. De ce să nu citești de acolo? Este suficient de ieftin încât majoritatea bazelor de date să elimine în mod implicit citirea murdară.
Actualizare pierdută
Actualizare pierdută înseamnă actualizări pierdute, iar traducerea reflectă destul de exact esența problemei:
De fapt, rezultatul tranzacției T2 a fost inversat. Această situație poate fi corectată prin blocări de scriere explicite sau implicite. Adică fie pur și simplu actualizăm înregistrarea și apoi apare o blocare implicită, fie executăm selectați pentru actualizare, provocând blocarea citirii și scrierii. Vă rugăm să rețineți că o astfel de operațiune este destul de periculoasă: cu citirea noastră „nevinovată”, blocăm alte citiri. Unele baze de date oferă mai multă siguranță selectați pentru distribuire, permițând citirea datelor, dar nemodificate.
Actualizarea cursorului a pierdut
Pentru un control mai fin, bazele de date pot oferi alte instrumente, cum ar fi un cursor. Un cursor este o structură care conține un set de rânduri și vă permite să treceți peste ele. declara cursor_name pentru select_statement. Conținutul cursorului este descris prin selectare.
De ce ai nevoie de un cursor? Cert este că unele baze de date oferă o blocare asupra tuturor înregistrărilor selectate prin selectare (stabilitatea citirii), sau numai asupra înregistrării pe care se află în prezent cursorul (stabilitatea cursorului). Cu stabilitatea cursorului, este implementată blocarea scurtă, ceea ce ne permite să reducem numărul de blocări dacă repetăm un eșantion mare de date. Prin urmare, anomalia de actualizare pierdută este izolată separat pentru cursor.
Lectură nerepetabilă
Citirea nerepetabilă este că în timpul executării tranzacției noastre, 2 citiri consecutive ale aceleiași înregistrări vor duce la rezultate diferite, deoarece între aceste două citiri a intervenit o altă tranzacție, ne-a schimbat datele și a fost comisă.
De ce este chiar aceasta o problemă? Imaginați-vă că scopul tranzacției T2 din imagine este de a selecta toate bunurile al căror preț este mai mic de 150 USD. Altcineva a actualizat prețul la 200 USD. Astfel, filtrul instalat nu a funcționat.
Aceste anomalii încetează să apară atunci când se adaugă interblocări în două faze sau când se folosește mecanismul MVCC, despre care aș dori să discut separat.
Citirea fantomă
Phantom este o citire a datelor care au fost adăugate de o altă tranzacție.
Ca exemplu, putem observa selecția incorectă a celui mai ieftin produs atunci când apare această anomalie.
A scăpa de citirile fantomă este deja destul de dificilă. Blocarea regulată nu este suficientă, pentru că nu putem bloca ceva ce încă nu există. Sistemele 2PL folosesc blocarea predictivă, în timp ce sistemele MVCC au un planificator de tranzacții care anulează tranzacțiile care ar putea fi perturbate de o inserare. Atât primul, cât și cel de-al doilea mecanism sunt destul de grele.
Citiți înclinat
Declinul de citire apare atunci când lucrăm cu mai multe tabele, al căror conținut trebuie să se schimbe constant.
Să presupunem că avem tabele care reprezintă postările și meta informațiile acestora:
O tranzacție citește din tabele, cealaltă le modifică:
Ca urmare a tranzacției T1, postarea are titlu = Bun și updated_by = T2, ceea ce este un fel de inconsecvență.
De fapt, aceasta este o lectură nerepetabilă, dar ca parte a mai multor tabele.
Pentru a remedia acest lucru, T1 poate pune blocări pe toate rândurile pe care le va citi, ceea ce va împiedica tranzacția T2 să modifice informațiile. În cazul MVCC, tranzacția T2 va fi anulată. Protecția împotriva acestei anomalii poate deveni importantă dacă folosim cursoare.
Scrie înclinat
Această anomalie este, de asemenea, mai ușor de explicat cu un exemplu: să presupunem că în sistemul nostru cel puțin un medic ar trebui să fie de gardă, dar ambii medici au decis să-și anuleze serviciul:
Anomalia însemna că niciunul dintre medici nu va fi de gardă. De ce s-a întâmplat asta? Pentru că tranzacția verifica o condiție care ar putea fi încălcată de o altă tranzacție și, din cauza izolării, nu am văzut această schimbare.
Aceasta este aceeași lectură irepetabilă. Alternativ, selectii pot plasa blocări pe aceste înregistrări.
Declinul de scris și declinul de citire sunt combinații ale anomaliilor anterioare. Puteți lua în considerare scrierea înclinată, care este în esență o lectură fantomă. Luați în considerare un tabel care conține numele angajaților, salariile acestora și proiectul la care lucrează:
Drept urmare, obținem următoarea imagine: fiecare manager a crezut că schimbarea sa nu va duce la depășirea bugetului, așa că a făcut schimbări de personal care împreună au dus la depășiri de costuri.
Cauza problemei este exact aceeași ca în citirea fantomă.
Constatări
Relaxarea nivelului de izolare a tranzacțiilor în baza de date este un compromis între securitate și performanță; alegerea acestui nivel ar trebui abordată pe baza riscurilor potențiale pentru afacere în cazul în care apar anumite anomalii.
Sursa: www.habr.com