Ögonblicksbild isolering

I databaser och transaktionsbearbetning (transaktionshantering) är ögonblicksbildsisolering en garanti för att alla läsningar som görs i en transaktion kommer att se en konsekvent ögonblicksbild av databasen (i praktiken läser den de senast bekräftade värdena som fanns när den startade), och själva transaktionen kommer endast att genomföras framgångsrikt om inga uppdateringar som den har gjort är i konflikt med några samtidiga uppdateringar som gjorts sedan den ögonblicksbilden.

Snapshot-isolering har antagits av flera stora databashanteringssystem , såsom InterBase , Firebird , Oracle , MySQL , PostgreSQL , SQL Anywhere , MongoDB och Microsoft SQL Server (2005 och senare). Det främsta skälet till att det antas är att det tillåter bättre prestanda än serialisering , men ändå undviker de flesta samtidiga anomalier som serialiserbarhet undviker (men inte alla). I praktiken implementeras ögonblicksbildsisolering inom multiversion concurrency control (MVCC), där generationsvärden för varje datapost (versioner) bibehålls: MVCC är ett vanligt sätt att öka samtidighet och prestanda genom att generera en ny version av ett databasobjekt varje gång objektet skrivs och tillåter transaktioners läsoperationer av flera senaste relevanta versioner (av varje objekt). Snapshot-isolering har använts för att kritisera ANSI SQL -92-standardens definition av isoleringsnivåer , eftersom den inte uppvisar några av de "avvikelser" som SQL-standarden förbjöd, men ändå inte kan serialiseras (den anomalifria isoleringsnivån definierad av ANSI).

Trots sin distinktion från serialiserbarhet kallas ögonblicksbildsisolering ibland som serialiserbar av Oracle.

Definition

En transaktion som utförs under ögonblicksbildsisolering verkar fungera på en personlig ögonblicksbild av databasen, tagen i början av transaktionen. När transaktionen avslutas kommer den endast att utföras framgångsrikt om de värden som uppdaterats av transaktionen inte har ändrats externt sedan ögonblicksbilden togs. En sådan skriv-skrivkonflikt kommer att göra att transaktionen avbryts.

I en skrivskevningsavvikelse läser två transaktioner (T1 och T2) samtidigt en överlappande datamängd (t.ex. värdena V1 och V2), gör samtidigt osammanhängande uppdateringar (t.ex. T1-uppdateringar V1, T2-uppdateringar V2) och slutligen samtidigt commit, varken efter att ha sett uppdateringen utförd av den andre. Om systemet skulle serialiseras skulle en sådan anomali vara omöjlig, eftersom antingen T1 eller T2 måste inträffa "först" och vara synliga för den andra. Däremot tillåter ögonblicksbildisolering skrivavvikelser.

Som ett konkret exempel, föreställ dig att V1 och V2 är två balanser som innehas av en enda person, Phil. Banken kommer att tillåta att antingen V1 eller V2 får ett underskott, förutsatt att den totala summan i båda aldrig är negativ (dvs. V1 + V2 ≥ 0). Båda saldonen är för närvarande $100. Phil initierar två transaktioner samtidigt, T1 tar ut $200 från V1 och T2 tar ut $200 från V2.

Om databasen garanterade serialiserbara transaktioner är det enklaste sättet att koda T1 att dra av $200 från V1 och sedan verifiera att V1 + V2 ≥ 0 fortfarande gäller, avbryt om inte. T2 drar på liknande sätt $200 från V2 och verifierar sedan V1 + V2 ≥ 0. Eftersom transaktionerna måste serialiseras, sker antingen T1 först, lämnar V1 = -$100, V2 = $100, och hindrar T2 från att lyckas (eftersom V1 + (V2 - $200) är nu −$200), eller så händer T2 först och förhindrar på liknande sätt T1 från att begås.

Om databasen är under ögonblicksbildsisolering (MVCC), fungerar T1 och T2 på privata ögonblicksbilder av databasen: var och en drar $200 från ett konto och verifierar sedan att den nya summan är noll, med hjälp av det andra kontovärdet som hölls när ögonblicksbild togs. Eftersom ingendera uppdateringskonflikten kommer igång, commit framgångsrikt, vilket lämnar V1 = V2 = −$100, och V1 + V2 = −$200.

Vissa system byggda med multiversion concurrency control (MVCC) kan stödja (endast) ögonblicksbildsisolering för att tillåta transaktioner att fortsätta utan att oroa sig för samtidiga operationer, och ännu viktigare utan att behöva verifiera alla läsoperationer igen när transaktionen slutligen genomförs. Detta är bekvämt eftersom MVCC upprätthåller en serie konsekventa tillstånd i den senaste historien. Den enda information som måste lagras under transaktionen är en lista över gjorda uppdateringar, som kan skannas efter konflikter ganska enkelt innan de begås. Emellertid kommer MVCC-system (som MarkLogic) att använda lås för att serialisera skrivningar tillsammans med MVCC för att erhålla några av prestandavinsterna och fortfarande stödja den starkare "serialiseringsbarhetsnivån" av isolering.

Lösningar

Potentiella inkonsekvensproblem som uppstår på grund av skrivavvikelser kan fixas genom att lägga till (annars onödiga) uppdateringar till transaktionerna för att upprätthålla serialiseringsegenskapen .

Materialisera konflikten
Lägg till en speciell konflikttabell, som båda transaktionerna uppdaterar för att skapa en direkt skriv-skrivkonflikt.
Kampanj
Låt en transaktion "uppdatera" en skrivskyddad plats (ersätt ett värde med samma värde) för att skapa en direkt skriv-skrivkonflikt (eller använd en motsvarande marknadsföringskampanj, t.ex. Oracles SELECT FOR UPDATE).

I exemplet ovan kan vi materialisera konflikten genom att lägga till en ny tabell som gör den dolda begränsningen explicit och mappar varje person till deras totala balans . Phil skulle börja med ett totalt saldo på $200, och varje transaktion skulle försöka subtrahera $200 från detta, vilket skapade en skriv-skrivkonflikt som skulle hindra de två från att lyckas samtidigt. Detta tillvägagångssätt bryter dock mot den normala formen .

Alternativt kan vi främja en av transaktionens läsningar till en skrivning. Till exempel kan T2 ställa in V1 = V1, skapa en konstgjord skriv-skrivkonflikt med T1 och återigen förhindra att de två lyckas samtidigt. Denna lösning kanske inte alltid är möjlig.

Generellt sett lägger därför ögonblicksbildsisolering en del av problemet med att upprätthålla icke-triviala begränsningar för användaren, som kanske inte uppskattar vare sig de potentiella fallgroparna eller de möjliga lösningarna. Fördelen med denna överföring är bättre prestanda.

Terminologi

Snapshot-isolering kallas "serialiserbart"-läge i Oracle- och PostgreSQL -versioner före 9.1, vilket kan orsaka förvirring med läget "verklig serialiserbarhet ". Det finns argument både för och emot detta beslut; Det som är tydligt är att användare måste vara medvetna om skillnaden för att undvika eventuellt oönskat anomalt beteende i deras databassystemlogik.

Historia

Isolering av ögonblicksbilder uppstod från arbetet med samtidighetskontrolldatabaser för flera versioner , där flera versioner av databasen underhålls samtidigt för att tillåta läsare att köra utan att kollidera med skribenter. Ett sådant system tillåter en naturlig definition och implementering av en sådan isoleringsnivå. InterBase , som senare ägs av Borland , erkändes för att tillhandahålla SI snarare än full serialiseringsbarhet i version 4, och troligen tillåtit skrivavvikelser sedan dess första release 1985.

skrevs ANSI SQL-92- standarden med en låsbaserad databas i åtanke, och är därför ganska vag när den tillämpas på MVCC-system. Berenson et al. skrev en artikel 1995 som kritiserade SQL-standarden och citerade ögonblicksbildsisolering som ett exempel på en isoleringsnivå som inte uppvisade de standardavvikelser som beskrivs i ANSI SQL-92-standarden, men som ändå hade ett onormalt beteende jämfört med serialiserbara transaktioner .

År 2008, Cahill et al. visade att skrivskeva anomalier kunde förhindras genom att upptäcka och avbryta "farliga" trillingar av samtidiga transaktioner. Denna implementering av serialiserbarhet är väl lämpad för samtidighetskontrolldatabaser med flera versioner och har antagits i PostgreSQL 9.1, där den hänvisas till som "Serializable Snapshot Isolation", förkortat till SSI. När det används konsekvent eliminerar detta behovet av ovanstående lösningar. Nackdelen med ögonblicksbildsisolering är en ökning av avbrutna transaktioner. Detta kan fungera bättre eller sämre än ögonblicksbildsisolering med ovanstående lösningar, beroende på arbetsbelastning.

  1. ^ "MySQL :: MySQL 8.0 Referensmanual :: 15.5.2.3 Konsekventa icke-låsande läsningar" . dev.mysql.com . Hämtad 2018-08-27 .
  2. ^ Multiversion samtidighetskontroll i MongoDB, MongoDB CTO: Hur vår nya WiredTiger-lagringsmotor kommer att få sina ränder
  3. ^ a b c d    Berenson, Hal; Bernstein, Phil; Gray, Jim; Melton, Jim; O'Neil, Elizabeth ; O'Neil, Patrick (1995), "A Critique of ANSI SQL Isolation Levels", Proceedings of the 1995 ACM SIGMOD International Conference on Management of Data , s. 1–10, arXiv : cs/0701157 , doi : 10.113785/4223785/5223785/5223785/5223785/5223785 / 5,2237 ISBN 978-0897917315 , S2CID 2316540
  4. ^     Fekete, Alan; Liarokapis, Dimitrios; O'Neil, Elizabeth ; O'Neil, Patrick ; Shasha, Dennis (2005), "Making Snapshot Isolation Serializable", ACM Transactions on Database Systems , 30 (2): 492–528, CiteSeerX 10.1.1.503.3169 , doi : 10.1145/1071610 , S10716101, S10716101 , S1071610 , 5107161. 2CID 1815415
  5. ^ Oracle Database Concepts 10g Release 1 (10.1) Kapitel 13: Datakonsekvens och konsistens – Oracle-isoleringsnivåer
  6. ^ Fråga Tom: Om transaktionsisoleringsnivåer
  7. ^ Fråga Tom: "Serialiserbar transaktion"
  8. ^ PostgreSQL 9.0 Dokumentation: 13.2.2.1. Serialiserbar isolering kontra sann serialiserbarhet
  9. ^ a b Pressmeddelande för PostgreSQL 9.1
  10. ^ a b PostgreSQL 9.1.14 Dokumentation: 13.2.3. Serialiserbar isoleringsnivå
  11. ^ Stuntz, Craig. "Multiversion samtidighetskontroll före InterBase" . Hämtad 30 oktober 2014 .
  12. ^   Michael J. Cahill, Uwe Röhm, Alan D. Fekete (2008) "Serialiserbar isolering för ögonblicksbildsdatabaser", Proceedings of the 2008 ACM SIGMOD international conference on Management of data, s. 729–738, ISBN 978-1-60558- 102-6 (SIGMOD 2008 pris för bästa papper)
  13. ^    Hamnar, Dan RK; Grittner, Kevin (2012). "Serialiserbar ögonblicksbildsisolering i PostgreSQL" (PDF) . Handlingar av VLDB-fonden . 5 (12): 1850–1861. arXiv : 1208.4179 . CiteSeerX 10.1.1.294.3803 . doi : 10.14778/2367502.2367523 . S2CID 16006111 .

Vidare läsning

Hämtad från " https://en.wikipedia.org/w/index.php?title=Snapshot_isolation&oldid=1139525606 "