Snapshot -isolation - Snapshot isolation

I databaser og transaktionsbehandling (transaktionsstyring) er isolering af øjebliksbilleder en garanti for, at alle læsninger, der foretages i en transaktion, vil se et konsistent øjebliksbillede af databasen (i praksis læser de de sidste forpligtede værdier, der eksisterede på det tidspunkt, den startede), og selve transaktionen vil kun lykkes, hvis der ikke er foretaget nogen konflikter med eventuelle samtidige opdateringer siden det øjebliksbillede.

Snapshot -isolering er blevet vedtaget af flere større databasesystemer , såsom InterBase , Firebird , Oracle , MySQL , PostgreSQL , SQL Anywhere , MongoDB og Microsoft SQL Server (2005 og senere). Hovedårsagen til dens vedtagelse er, at den tillader bedre ydeevne end serialiserbarhed , men alligevel undgår de fleste af de samtidige anomalier, som serialiserbarhed undgår (men ikke altid alle). I praksis implementeres snapshot -isolering inden for multiversion samtidighedskontrol (MVCC), hvor generationsværdier for hvert dataelement (versioner) opretholdes: MVCC er en almindelig måde at øge samtidighed og ydeevne ved at generere en ny version af et databaseobjekt, hver gang objektet er skrevet, og giver transaktioner mulighed for at læse operationer af flere sidste relevante versioner (af hvert objekt). Snapshot -isolation er blevet brugt til at kritisere ANSI SQL -92 -standardens definition af isolationsniveauer , da den ikke udviser nogen af ​​de "anomalier", som SQL -standarden forbød, men alligevel ikke er serialiserbar (det anomalifrie isolationsniveau defineret af ANSI).

På trods af dets adskillelse fra serialiserbarhed kaldes øjebliksbilledeisolering undertiden som serialiserbar af Oracle.

Definition

En transaktion, der udføres under øjebliksbilledeisolering, ser ud til at fungere på et personligt øjebliksbillede af databasen, der blev taget ved transaktionens start. Når transaktionen afsluttes, forpligter den sig kun, hvis de værdier, der er opdateret af transaktionen, ikke er blevet ændret eksternt siden snapshotet blev taget. En sådan skrive -skriv -konflikt får transaktionen til at afbryde.

I en skrive -skæv anomali læser to transaktioner (T1 og T2) samtidigt et overlappende datasæt (f.eks. Værdierne V1 og V2), foretager samtidigt uensartede opdateringer (f.eks. T1 -opdateringer V1, T2 -opdateringer V2) og begår samtidig samtidig, uden at have set opdateringen udført af den anden. Hvis systemet kunne serieliseres, ville en sådan anomali være umulig, da enten T1 eller T2 skulle forekomme "først" og være synlig for den anden. I modsætning hertil tillader snapshot -isolering at skrive skævt anomalier.

Som et konkret eksempel kan du forestille dig, at V1 og V2 er to balancer, der er i besiddelse af en enkelt person, Phil. Banken vil tillade, at enten V1 eller V2 har et underskud, forudsat at det samlede beløb i begge dele aldrig er negativt (dvs. V1 + V2 ≥ 0). Begge saldi er i øjeblikket $ 100. Phil indleder to transaktioner samtidigt, hvor T1 hæver $ 200 fra V1, og T2 trækker $ 200 fra V2.

Hvis databasen garanterede serielle transaktioner, er den enkleste måde at kode T1 på at trække $ 200 fra V1 og derefter kontrollere, at V1 + V2 ≥ 0 stadig holder, hvis den afbrydes, hvis ikke. T2 trækker på samme måde $ 200 fra V2 og verificerer derefter V1 + V2 ≥ 0. Da transaktionerne skal serialiseres, sker enten T1 først og efterlader V1 = - $ 100, V2 = $ 100 og forhindrer T2 i at lykkes (siden V1 + (V2 - $ 200)) er nu - $ 200), eller T2 sker først og forhindrer på samme måde T1 i at begå.

Hvis databasen er under øjebliksbilledeisolering (MVCC), fungerer T1 og T2 imidlertid på private øjebliksbilleder af databasen: hver fratrækker $ 200 fra en konto og verificerer derefter, at den nye total er nul ved hjælp af den anden kontoværdi, der var i behold, når øjebliksbillede blev taget. Da ingen af opdateringerne er i konflikt, begår begge succes med at efterlade V1 = V2 = - $ 100 og V1 + V2 = - $ 200.

Nogle systemer bygget ved hjælp af multiversion samtidighedskontrol (MVCC) understøtter muligvis (kun) øjebliksbilledeisolering for at tillade transaktioner at fortsætte uden at bekymre sig om samtidige operationer og endnu vigtigere uden at skulle genbekræfte alle læste operationer, når transaktionen endelig begår. Dette er praktisk, fordi MVCC opretholder en række nylige historiske konsekvente tilstande. De eneste oplysninger, der skal gemmes under transaktionen, er en liste over foretagne opdateringer, som kan scannes for konflikter ret let, før de begås. MVCC -systemer (f.eks. MarkLogic) vil dog bruge låse til at serialisere skriverier sammen med MVCC for at opnå nogle af præstationsgevinsterne og stadig understøtte det stærkere isoleringsniveau "serialiserbarhed".

Løsninger

Potentielle inkonsekvensproblemer, der opstår som følge af skrive -skævheder, kan afhjælpes ved at tilføje (ellers unødvendige) opdateringer til transaktionerne for at håndhæve egenskaben serialiserbarhed .

Materialisere konflikten
Tilføj en særlig konflikttabel, som begge transaktioner opdaterer for at oprette en direkte skrive -skrive -konflikt.
Forfremmelse
Få en transaktion til at "opdatere" et skrivebeskyttet sted (erstatte en værdi med den samme værdi) for at oprette en direkte skrive-skrive-konflikt (eller bruge en tilsvarende kampagne, f.eks. Oracles SELECT FOR UPDATE).

I eksemplet ovenfor kan vi materialisere konflikten ved at tilføje en ny tabel, der gør den skjulte begrænsning eksplicit og kortlægge hver person til deres samlede saldo . Phil ville starte med en samlet saldo på $ 200, og hver transaktion ville forsøge at trække $ 200 fra dette og skabe en skrive -skrive konflikt, der ville forhindre de to i at lykkes samtidigt. Denne tilgang krænker imidlertid den normale form .

Alternativt kan vi promovere en af ​​transaktionens læsninger til en skrivning. For eksempel kan T2 indstille V1 = V1, hvilket skaber en kunstig skrive -skriv -konflikt med T1 og igen forhindrer de to i at lykkes samtidigt. Denne løsning er muligvis ikke altid mulig.

Generelt sætter snapshot-isolering derfor nogle af problemerne med at opretholde ikke-trivielle begrænsninger på brugeren, som måske ikke værdsætter hverken de potentielle faldgruber eller de mulige løsninger. Fordelen ved denne overførsel er bedre ydeevne.

Terminologi

Snapshot -isolation kaldes "serialiserbar" tilstand i Oracle- og PostgreSQL -versioner før 9.1, hvilket kan forårsage forvirring med "reel serialiserbarhed " -tilstand. Der er argumenter både for og imod denne beslutning; det, der er klart, er, at brugerne skal være opmærksomme på sondringen for at undgå mulig uønsket unormal adfærd i deres databasesystemlogik.

Historie

Snapshot -isolation opstod fra arbejde med multiversion samtidige kontroldatabaser , hvor flere versioner af databasen vedligeholdes samtidigt for at give læsere mulighed for at udføre uden at kollidere med forfattere. Et sådant system tillader en naturlig definition og implementering af et sådant isolationsniveau. InterBase , senere ejet af Borland , blev anerkendt for at levere SI snarere end fuld serialiserbarhed i version 4 og sandsynligvis tilladt skrive-skævt anomalier siden dens første udgivelse i 1985.

Desværre, ANSI SQL-92 blev standard skrevet med en lås -baseret database i tankerne, og derfor er temmelig vag, når den anvendes til MVCC systemer. Berenson et al. skrev et papir i 1995, hvor han kritiserede SQL-standarden og nævnte snapshot-isolation som et eksempel på et isolationsniveau, der ikke udviste standardanomalierne beskrevet i ANSI SQL-92-standarden, men alligevel havde en unormal adfærd sammenlignet med serieliserbare transaktioner.

I 2008 udtalte Cahill et al. viste, at skrå-skævheder kunne undgås ved at opdage og afbryde "farlige" trillinger af samtidige transaktioner. Denne implementering af serialiserbarhed er velegnet til multiversion samtidige kontroldatabaser og er blevet vedtaget i PostgreSQL 9.1, hvor den omtales som "Serializable Snapshot Isolation", forkortet til SSI. Når det bruges konsekvent, eliminerer dette behovet for ovenstående løsninger. Ulempen ved isolering af øjebliksbilleder er en stigning i afbrudte transaktioner. Dette kan udføre bedre eller dårligere end isolering af øjebliksbilleder med ovenstående løsninger, afhængigt af arbejdsbyrden.

I 2011 Jimenez-Peris et al. indgav et patent, hvor det blev vist, hvordan det var muligt at skalere til mange millioner opdateringstransaktioner i sekundet med en ny metode til at opnå snapshot -isolation på en distribueret måde. Metoden er baseret på iagttagelsen af, at det bliver muligt at foretage transaktioner fuldt ud parallelt uden koordinering og derfor fjerne flaskehalsen af ​​traditionelle transaktionsbehandlingsmetoder. Metoden anvender en commit -sequencer, der genererer commit -tidsstempler og en snapshot -server, der fremmer det aktuelle snapshot, efterhånden som huller udfyldes i serialiseringsrækkefølgen. Denne metode er grundlaget for databasen LeanXcale. Den første implementering af denne metode blev foretaget i 2010 som en del af CumuloNimbo European Project.

Referencer

  1. ^ "MySQL :: MySQL 8.0 Reference Manual :: 15.5.2.3 Konsistente læsninger uden låsning" . dev.mysql.com . Hentet 2018-08-27 .
  2. ^ Multiversion samtidighedskontrol i MongoDB, MongoDB CTO: Hvordan vores nye WiredTiger -lagermotor vil tjene sine striber
  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.1145/223784.223785 , ISBN  978-0897917315
  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.1071615 , ISSN 0362-5915   
  5. ^ Oracle Database Concepts 10g Release 1 (10.1) Kapitel 13: Datalighed og konsistens - Oracle Isolation Levels
  6. ^ Spørg Tom: Om transaktionsisolationsniveauer
  7. ^ Spørg Tom: "Serialiserbar transaktion"
  8. ^ PostgreSQL 9.0 dokumentation: 13.2.2.1. Serialiserbar isolation kontra sand serialiserbarhed
  9. ^ a b PostgreSQL 9.1 pressemeddelelse
  10. ^ a b PostgreSQL 9.1.14 Dokumentation: 13.2.3. Serialiserbart isolationsniveau
  11. ^ Stuntz, Craig. "Multiversion samtidighedskontrol før InterBase" . Hentet 30. oktober 2014 .
  12. ^ Michael J. Cahill, Uwe Röhm, Alan D. Fekete (2008) "Serializable isolation for snapshot databases" , Proceedings of the 2008 ACM SIGMOD international Conference on Management of data , s. 729–738, ISBN  978-1-60558- 102-6 (SIGMOD 2008 bedste papirpris)
  13. ^ Havne, Dan RK; Grittner, Kevin (2012). "Serialiserbar snapshot -isolation i PostgreSQL" (PDF) . Procedurer for VLDB -begavelsen . 5 (12): 1850–1861. arXiv : 1208.4179 . CiteSeerX 10.1.1.294.3803 . doi : 10.14778/2367502.2367523 .  
  14. ^ EP 2780832 , Jiménez-Peris, Ricardo & Patiño-Martinez, Marta, "System og metode til stærkt skalerbar decentraliseret og transaktionsbehandling med lav strid", offentliggjort 25. maj 2016 
  15. ^ "LeanXcale" . leanxcale.com . Hentet 2017-08-20 .
  16. ^ Jimenez-Peris, Ricardo; Patiño-Martinez, Marta; Magoutis, Kostas; Bilas, Angelos; Brondino, Ivan (april 2012). "CumuloNimbo: En meget skalerbar transaktionsbehandlingsplatform som en tjeneste" . Ercim News .

Yderligere læsning