Hallo iedereen. Hier is Vladislav Rodin. Momenteel ben ik de cursusleider van de cursus 'Architect van hoge belasting' bij OTUS en geef ik ook onderwijs in cursussen over softwarearchitectuur.
Naast het lesgeven, zoals je misschien hebt gemerkt, schrijf ik originele content voor de OTUS-blog op Habr en vandaag wil ik deze articel wijden aan de lancering van de cursus , waarvoor momenteel inschrijvingen open staan.
Inleiding
In We hebben gesproken over het feit dat transacties in databases dienen om twee doelen te bereiken: het waarborgen van fouttolerantie en toegang tot gegevens in een concurrerende omgeving. Om deze taken volledig uit te voeren, moet een transactie voldoen aan de ACID-eisen. Vandaag zullen we uitgebreid ingaan op de letter I (isolatie) in deze afkorting.
Isolatie
Isolatie lost het probleem van toegang tot gegevens in een concurrerende omgeving op, door feitelijk bescherming te bieden tegen race conditions. Idealiter betekent isolatie serialisatie, dat wil zeggen het vermogen om ervoor te zorgen dat het resultaat van transacties die parallel worden uitgevoerd hetzelfde is als wanneer ze sequentieel worden uitgevoerd. Het belangrijkste probleem met deze eigenschap is dat het technisch zeer moeilijk te waarborgen is en als gevolg daarvan een grote impact heeft op de systeemperformance. Daarom wordt isolatie vaak verzwakt, waarbij de risico's van bepaalde anomalieƫn die hieronder worden besproken, worden aanvaard. De mogelijkheid van het optreden van dergelijke anomalieƫn kenmerkt precies het niveau van isolatie van transacties.
De meest bekende anomalieƫn zijn: dirty read, non-repeatable read, phantom read, maar er zijn in feite nog 5 andere: dirty write, cursor lost update, lost update, read skew, write skew.
Dirty write
De kern van de anomalie is dat transacties niet-gecommitteerde gegevens kunnen overschrijven.
Deze anomalie is gevaarlijk omdat niet alleen gegevens na de commit van beide transacties kunnen conflicteren (zoals op de afbeelding), maar ook omdat de atomiciteit wordt geschonden: omdat we toestaan dat niet-gecommitteerde gegevens worden overschreven, is het onduidelijk hoe we Ć©Ć©n transactie kunnen terugdraaien zonder de andere aan te tasten.
De anomalie is vrij eenvoudig te verhelpen: we plaatsen een vergrendeling op de schrijfoperatie voordat we beginnen met schrijven, en verbieden andere transacties om de registratie te wijzigen totdat de vergrendeling is opgeheven.
Dirty read
Dirty read betekent het lezen van niet-gecommitteerde gegevens.
Problemen ontstaan wanneer op basis van een steekproef bepaalde acties moeten worden ondernomen of beslissingen moeten worden genomen.
Om een anomalie te corrigeren, kan een leeshindering worden ingesteld, maar dit heeft een grote impact op de prestaties. Het is veel eenvoudiger om te zeggen dat voor een rollback van de transactie de originele toestand van de gegevens (voordat de wijziging begon) essentieel moet worden bewaard in het systeem. Waarom niet daaruit lezen? Dit is redelijk goedkoop, daarom schakelen de meeste databases dirty reads standaard uit.
Verloren update
Verloren update betekent verloren updates, en de vertaling weerspiegelt behoorlijk nauwkeurig de kern van het probleem:
Feitelijk is het resultaat van transactie T2 geannuleerd. Deze situatie wordt gecorrigeerd met expliciete of impliciete recordvergrendelingen. Dit betekent dat we ofwel simpelweg de record bijwerken, wat een impliciete vergrendeling creƫert, of we voeren select for update, waardoor een lees- en schrijfvergrendeling wordt gecreƫerd. Let op dat deze operatie behoorlijk riskant is: met onze 'onschuldige' lezing blokkeren we andere lezingen. Sommige databases bieden een veiligere select for share, die het mogelijk maakt om gegevens te lezen, maar wijzigingen niet toestaat.
Verloren update met cursor
Voor meer verfijnde controle kunnen databases andere hulpmiddelen aanbieden, zoals een cursor. Een cursor is een structuur die een set rijen bevat en waarmee je door deze kunt itereren. declare cursor_name for select_statement. De inhoud van de cursor wordt beschreven door de select.
Wat is het nut van een cursor? Het punt is dat sommige databases een vergrendeling op alle rijen, gekozen door de select (read stability), of alleen op de rij waar de cursor zich momenteel bevindt (cursor stability), aanbieden. Bij cursor stability wordt een short lock toegepast, wat het aantal vergrendelingen vermindert wanneer we door een grote set gegevens itereren. Daarom wordt de anomalie verloren update apart voor de cursor belicht.
Niet-herhaalbare lezing
Niet-herhaalbare lezing betekent dat tijdens het uitvoeren van onze transactie 2 opeenvolgende lezingen van dezelfde record zullen resulteren in verschillende uitkomsten, omdat een andere transactie tussen deze twee lezingen is ingegaan, onze gegevens heeft gewijzigd en is gecommit.
Waarom is dit Ć¼berhaupt een probleem? Stel je voor dat het doel van transactie T2 op de afbeelding is om alle artikelen te selecteren met een prijs van minder dan 150 eenheden. Iemand anders heeft de prijs verhoogd naar 200 eenheden. Daardoor werkt de ingestelde filter niet.
Deze anomalieƫn stoppen wanneer er tweefasige vergrendelingen worden toegevoegd of wanneer er gebruik wordt gemaakt van het MVCC-mechanisme, waarover we apart willen praten.
Phantom read
Een phantom read is een lezing van gegevens die door een andere transactie zijn toegevoegd.
Een voorbeeld hiervan is het incorrect selecteren van het goedkoopste artikel wanneer deze anomalie zich voordoet.
Het is al behoorlijk moeilijk om van phantom reads af te komen. Gewone vergrendeling is niet voldoende, want we kunnen niet vergrendelen wat er nog niet is. 2PL-systemen maken gebruik van predicatieve vergrendeling, terwijl MVCC-systemen transacties annuleren die mogelijk worden verstoord door invoegen. Zowel de eerste als de tweede mechanismen zijn vrij zwaar.
Read skew
Read skew ontstaat wanneer we met meerdere tabellen werken waarvan de inhoud consistent moet veranderen.
Laten we aannemen dat we tabellen hebben die posts en hun metadata vertegenwoordigen:
De ene transactie leest uit de tabellen, terwijl de andere ze wijzigt:
Als resultaat van de uitvoering van transactie T1, heeft de post title = Good en updated_by = T2, wat een bepaalde inconsistentie is.
In feite is dit een non-repeatable read, maar in de context van meerdere tabellen.
Om dit op te lossen, kan T1 vergrendelingen leggen op alle rijen die ze zal lezen, waardoor transactie T2 de informatie niet kan wijzigen. In het geval van MVCC zal transactie T2 worden geannuleerd. Bescherming tegen deze anomalie kan belangrijk zijn als we cursors gebruiken.
Write skew
Deze anomalie is ook eenvoudiger uit te leggen aan de hand van een voorbeeld: stel dat er in ons systeem minimaal Ć©Ć©n dokter op dienst moet zijn, maar beide dokters besluiten hun dienst te annuleren:
De anomalie leidde ertoe dat geen enkele dokter op dienst verschijnt. Hoe kwam dit zo? Omdat de transactie een voorwaarde controleerde die door een andere transactie kan worden geschonden, en door isolatie zagen we deze wijziging niet.
Dit is dezelfde non-repeatable read. Als optie kunnen selects vergrendelingen leggen op deze records.
Write skew en read skew zijn combinaties van eerdere anomalieƫn. We kunnen write skew beschouwen, dat in feite een phantom read is. Laten we een tabel bekijken waarin de namen van medewerkers, hun salarissen en de projecten waaraan ze werken staan.
Uiteindelijk krijgen we het volgende beeld: elke manager dacht dat zijn wijziging niet zou leiden tot overschrijding van het budget, daarom maakten zij personeelswijzigingen die in totaal leidden tot overschrijding.
De oorzaak van het probleem is precies dezelfde als bij phantom reads.
Conclusies
Het verlagen van het isolatieniveau van transacties in de database is een compromis tussen beveiliging en prestaties; de keuze voor dit niveau moet worden benaderd op basis van de potentiƫle risico's voor het bedrijf bij het optreden van bepaalde anomalieƫn.
Bron: habr.com
