Dag Allemaal. Vladislav Rodin heeft contact opgenomen. Momenteel ben ik cursusleider voor de cursus High Workload Architect bij OTUS en geef ik ook software-architectuurcursussen.
Naast het lesgeven schrijf ik, zoals je misschien hebt gemerkt, origineel materiaal voor de OTUS-blog op Habré en ik wil het artikel van vandaag laten samenvallen met de lancering van de cursus , die momenteel openstaat voor inschrijving.
Introductie
В we hadden het over het feit dat transacties in databases dienen om twee problemen op te lossen: het garanderen van fouttolerantie en toegang tot gegevens in een competitieve omgeving. Om deze taken volledig uit te voeren, moet de transactie ACID-eigenschappen hebben. Vandaag zullen we in detail over de brief praten ik (isolatie) in deze afkorting.
Isolatie
Isolatie lost het probleem op van toegang tot gegevens in een competitieve omgeving en biedt in wezen bescherming tegen raceomstandigheden. Idealiter betekent isolatie serialisatie, een eigenschap die ervoor zorgt dat het resultaat van het parallel uitvoeren van transacties hetzelfde is als wanneer ze opeenvolgend zouden worden uitgevoerd. Het grootste probleem met deze eigenschap is dat deze technisch zeer moeilijk te realiseren is en als gevolg daarvan een aanzienlijke impact heeft op de systeemprestaties. Dat is de reden waarom het isolement vaak wordt verzwakt, waarbij de risico’s van bepaalde afwijkingen worden geaccepteerd, die hieronder zullen worden besproken. De mogelijkheid van het optreden van bepaalde anomalieën karakteriseert precies het niveau van transactie-isolatie.
De meest bekende afwijkingen zijn: vies lezen, niet-herhaalbaar lezen, fantoomlezen, maar in feite zijn er nog 5: vies schrijven, cursor verloren update, verloren update, lees-skew, schrijf-skew.
Vuil schrijven
De essentie van de anomalie is dat transacties niet-vastgelegde gegevens kunnen overschrijven.
Deze anomalie is niet alleen gevaarlijk omdat gegevens kunnen conflicteren na het uitvoeren van beide transacties (zoals in de afbeelding), maar ook omdat de atomiciteit wordt geschonden: aangezien we toestaan dat niet-vastgelegde gegevens worden overschreven, is het niet duidelijk hoe de ene transactie kan worden teruggedraaid zonder een andere te beïnvloeden. .
De anomalie kan heel eenvoudig worden verholpen: we bevestigen een vergrendeling aan de record voordat we met de opname beginnen, waardoor andere transacties de record niet kunnen wijzigen totdat de vergrendeling wordt verwijderd.
Vies lezen
Dirty read betekent het lezen van niet-vastgelegde gegevens.
Er ontstaan problemen wanneer acties of beslissingen moeten worden genomen op basis van de steekproef.
Om de afwijking te corrigeren, kunt u een leesvergrendeling bevestigen, maar dit heeft een grote invloed op de prestaties. Het is veel eenvoudiger om te zeggen dat voor een rollback-transactie de initiële status van de gegevens (vóór het begin van de opname) in het systeem moet worden opgeslagen. Waarom niet vanaf daar lezen? Het is zo goedkoop dat de meeste databases vuile leesbewerkingen standaard verwijderen.
Verloren update
Verloren update betekent verloren updates, en de vertaling geeft vrij nauwkeurig de essentie van het probleem weer:
In feite werd het resultaat van transactie T2 omgekeerd. Deze situatie kan worden gecorrigeerd door expliciete of impliciete schrijfvergrendelingen. Dat wil zeggen, we werken het record eenvoudigweg bij en er vindt dan een impliciete vergrendeling plaats, of we voeren het uit selecteer voor bijwerken, waardoor er een lees- en schrijfvergrendeling optreedt. Houd er rekening mee dat een dergelijke operatie behoorlijk gevaarlijk is: met onze “onschuldige” lezing blokkeren we andere metingen. Sommige databases bieden veiliger selecteren om te delen, waardoor gegevens kunnen worden gelezen maar niet kunnen worden gewijzigd.
Cursor verloren update
Voor een fijnere controle kunnen bases andere hulpmiddelen bieden, zoals een cursor. Een cursor is een structuur die een reeks rijen bevat en waarmee u deze kunt herhalen. declareer cursornaam voor select_statement. De inhoud van de cursor wordt beschreven door selecteren.
Waarom heb je een cursor nodig? Feit is dat sommige databases een vergrendeling bieden op alle door select geselecteerde records (leesstabiliteit), of alleen op het record waarop de cursor zich momenteel bevindt (cursorstabiliteit). Met cursorstabiliteit wordt korte vergrendeling geïmplementeerd, waardoor we het aantal vergrendelingen kunnen verminderen als we een grote hoeveelheid gegevens herhalen. Daarom wordt de verloren update-anomalie afzonderlijk geïsoleerd voor de cursor.
Niet-herhaalbaar lezen
Niet-herhaalbare lezing betekent dat tijdens de uitvoering van onze transactie twee opeenvolgende lezingen van hetzelfde record tot verschillende resultaten zullen leiden, omdat een andere transactie tussen deze twee lezingen tussenbeide kwam, onze gegevens veranderde en werd vastgelegd.
Waarom is dit überhaupt een probleem? Stel je voor dat het doel van transactie T2 op de afbeelding is om alle goederen te selecteren waarvan de prijs minder dan 150 USD bedraagt. Iemand anders heeft de prijs bijgewerkt naar $ 200. Het geïnstalleerde filter werkte dus niet.
Deze anomalieën komen niet meer voor als er tweefasige vergrendelingen worden toegevoegd of als het MVCC-mechanisme wordt gebruikt, wat ik afzonderlijk zou willen bespreken.
Fantoom gelezen
Phantom is een lezing van gegevens die door een andere transactie zijn toegevoegd.
We kunnen bijvoorbeeld de onjuiste selectie van het goedkoopste product waarnemen wanneer deze anomalie zich voordoet.
Het wegwerken van fantoomlezingen is al behoorlijk moeilijk. Regelmatig blokkeren is niet voldoende, omdat we niet iets kunnen blokkeren dat nog niet bestaat. 2PL-systemen maken gebruik van voorspellende vergrendeling, terwijl MVCC-systemen een transactieplanner hebben die transacties terugdraait die mogelijk worden verstoord door een tussenvoegsel. Zowel het eerste als het tweede mechanisme zijn behoorlijk zwaar.
Lees scheef
Leesscheefheid treedt op wanneer we met meerdere tabellen werken, waarvan de inhoud consistent moet veranderen.
Laten we zeggen dat we tabellen hebben die berichten en hun meta-informatie vertegenwoordigen:
De ene transactie leest uit de tabellen, de andere wijzigt ze:
Als gevolg van transactie T1 heeft het bericht titel = Goed, en bijgewerkt_door = T2, wat een inconsistentie is.
In feite is dit een niet-herhaalbare lezing, maar als onderdeel van verschillende tabellen.
Om dit op te lossen kan T1 vergrendelingen plaatsen op alle rijen die worden gelezen, waardoor wordt voorkomen dat transactie T2 de informatie verandert. In het geval van MVCC wordt de T2-transactie geannuleerd. Bescherming tegen deze anomalie kan belangrijk worden als we cursors gebruiken.
Schrijf scheef
Deze anomalie is ook gemakkelijker uit te leggen met een voorbeeld: stel dat in ons systeem minstens één arts dienst zou moeten hebben, maar beide artsen besloten hun dienst op te zeggen:
De anomalie betekende dat geen van de artsen dienst zou hebben. Waarom is dit gebeurd? Omdat de transactie een voorwaarde controleerde die door een andere transactie zou kunnen worden geschonden, en vanwege de isolatie hebben we deze verandering niet gezien.
Dit is dezelfde niet-herhaalbare lezing. Als alternatief kunnen geselecteerde selecties deze records vergrendelen.
Schrijf-skew en lees-skew zijn combinaties van de voorgaande afwijkingen. U kunt schrijfscheefheid overwegen, wat in wezen een fantoomlezing is. Beschouw een tabel met de namen van werknemers, hun salarissen en het project waaraan ze werken:
Als gevolg hiervan krijgen we het volgende beeld: elke manager dacht dat zijn verandering niet zou leiden tot overschrijding van het budget, dus voerden ze personeelswijzigingen door die samen tot kostenoverschrijdingen leidden.
De oorzaak van het probleem is precies dezelfde als bij fantoomlezen.
Bevindingen
Het versoepelen van het transactie-isolatieniveau in de database is een afweging tussen veiligheid en prestaties; de keuze voor dit niveau moet worden benaderd op basis van de potentiële risico's voor het bedrijf als zich bepaalde afwijkingen voordoen.
Bron: www.habr.com