De fire isolationsniveauer

Når en interviewer spørger "nævn de fire isolationsniveauer", er den egentlige test, om du kan forklare afvejningen: Stærkere isolation betyder færre anomalier, men lavere samtidighed.

SQL-standarden definerer fire niveauer i rækkefølge fra svagest til stærkest:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

Hvert niveau tillader eller forbyder et bestemt sæt læseanomalier. Denne lektion gennemgår niveauerne; den næste gennemgår anomalierne i detaljer.

Du indstiller isolation pr. transaktion eller pr. session. Syntaksen er næsten identisk på tværs af databasemotorer.

Hvis du ikke indstiller niveauet, har alle databaser et standardniveau. At kende standardniveauerne er et hyppigt spørgsmål i jobsamtaler, så vi gennemgår dem til sidst.

READ UNCOMMITTED er det svageste niveau. En transaktion kan læse rækker, som en anden transaktion har ændret, men ikke gennemført endnu. Disse kaldes beskidte læsninger.

Hvis den anden transaktion rulles tilbage, har du læst data, der aldrig officielt eksisterede. Det er farligt for alt, der skal være korrekt.

Bemærk: Postgres behandler READ UNCOMMITTED på samme måde som READ COMMITTED, så den udfører aldrig rent faktisk beskidte læsninger. SQL Server og MySQL håndhæver niveauet.

READ COMMITTED garanterer, at du kun læser data, der er gennemført. Ingen beskidte læsninger.

Hver SQL-sætning ser dog det seneste gennemførte øjebliksbillede. Hvis du kører den samme forespørgsel to gange i én transaktion, kan en anden gennemført transaktion i mellemtiden ændre resultatet. Denne anomali er en ikke-gentagelig læsning.

Dette er standardniveauet i Postgres, Oracle og SQL Server, og det er en fornuftig balance for de fleste applikationer.

REPEATABLE READ sikrer, at du får den samme værdi begge gange, hvis du læser en række to gange i den samme transaktion. Niveauet tager et konsistent øjebliksbillede ved transaktionens start.

Det forhindrer beskidte læsninger og ikke-gentagelige læsninger. Standarden tillader stadig fantomlæsninger: nye rækker, der matcher din WHERE-betingelse, og som dukker op, når du udfører forespørgslen igen.

Vigtigt: Dette er standardniveauet i MySQL/InnoDB, og InnoDBs implementering blokerer også de fleste fantomlæsninger via låse på næste nøgle.

SERIALIZABLE er det strengeste niveau. Databasen garanterer, at resultatet af at køre transaktioner samtidigt er identisk med resultatet af at køre dem efter hinanden i en eller anden seriel rækkefølge.

Det forhindrer beskidte læsninger, ikke-gentagelige læsninger og fantomlæsninger. Prisen er flere låse eller, i Postgres, afbrydelser på grund af serialiseringsfejl, som du skal forsøge igen.

Formulering til jobsamtalen: "SERIALIZABLE giver indtrykket af, at alle transaktioner kørte alene, til gengæld for lavere samtidighed og mulige nye forsøg."

Det mest nyttige at lære udenad er, hvilken anomali hvert niveau tillader. "Ja" betyder, at anomalien kan forekomme.

• READ UNCOMMITTED: beskidt=Ja, ikke-gentagelig=Ja, fantom=Ja
• READ COMMITTED: beskidt=Nej, ikke-gentagelig=Ja, fantom=Ja
• REPEATABLE READ: beskidt=Nej, ikke-gentagelig=Nej, fantom=Ja (ifølge standarden)
• SERIALIZABLE: beskidt=Nej, ikke-gentagelig=Nej, fantom=Nej

Hvert trin op forbyder endnu en anomali. Det er hele svaret.

En vigtig forskel på seniorniveau er, at SQL-standarden definerer niveauerne ud fra, hvilke anomalier de skal forhindre, ikke hvordan de gør det. Virkelige databasemotorer forhindrer ofte flere anomalier.

• Postgres REPEATABLE READ bruger isolation med øjebliksbillede og blokerer også fantomlæsninger, selv om der stadig kan opstå skrive-skævhed.
• MySQL/InnoDB REPEATABLE READ blokerer fantomlæsninger med låse på næste nøgle.
• Postgres SERIALIZABLE bruger SSI (serialiserbar isolation med øjebliksbilleder) og afbryder ved konflikter i stedet for at bruge tunge låse.

Hvis du nævner dette, viser du, at du ved, at standarden er et minimumskrav og ikke beskriver den præcise adfærd.

Standardniveauer bliver nævnt hele tiden. Lær disse udenad:

• PostgreSQL: READ COMMITTED
• Oracle: READ COMMITTED (ingen beskidte læsninger nogensinde)
• SQL Server: READ COMMITTED
• MySQL (InnoDB): REPEATABLE READ

MySQLs særtilfælde er en yndlingsfælde. Hvis du bliver spurgt "hvad er standardniveauet for isolation?", skal du altid først afklare databasemotoren.

Hvordan beslutter du dig? Se det som en afvejning mellem risiko og gennemløb.

• Brug READ COMMITTED til typiske OLTP-systemer; det er hurtigt og undgår beskidte læsninger.
• Brug REPEATABLE READ, når en transaktion læser de samme data flere gange og skal holde dem stabile (rapporter og beregninger i flere trin).
• Brug SERIALIZABLE til logik, hvor korrekthed er afgørende, og design logik til nye forsøg ved afbrydelser.

Brug næsten aldrig READ UNCOMMITTED i produktion.

Når du har opremset niveauerne, følger interviewere ofte op med hurtige spørgsmål. Hav præcise svar klar:

• "Hvilket niveau forhindrer beskidte læsninger, men tillader ikke-gentagelige læsninger?" READ COMMITTED.
• "Hvilken er den eneste anomali, som REPEATABLE READ stadig tillader ifølge standarden?" Fantomlæsninger.
• "Hvorfor ikke altid bruge SERIALIZABLE?" Det reducerer samtidigheden og kan tvinge dig til at prøve transaktioner igen ved serialiseringsfejl.
• "Koster et højere niveau mere?" Ja, i form af låse eller omkostninger ved afbrydelse og nyt forsøg.

Hvis du kan svare med det samme, viser det, at du har forstået rangstigen og ikke bare lært den udenad.

De fire isolationsniveauer udgør en rangstige fra svagest til stærkest: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE. Hvert trin op forhindrer endnu en anomali (beskidt, ikke-gentagelig eller fantomlæsning) på bekostning af samtidighed.

Husk standardniveauerne (READ COMMITTED overalt undtagen MySQLs REPEATABLE READ), og bemærk, at virkelige databasemotorer ofte forhindrer mere, end standarden kræver. Derefter undersøger vi de tre læseanomalier, som disse niveauer er udformet til at forhindre.