Indvirkningen af transaktionsisoleringsniveauer

SQL-databaser definerer forskellige isolationsniveauer for at styre, hvor meget én transaktion påvirkes af andre transaktioner, der kører samtidigt.

Disse niveauer er et kompromis: Højere isolation betyder færre samtidighedsanomalier, men medfører ofte større belastning eller lavere samtidighed, fordi transaktioner kan være nødt til at vente på hinanden.

PostgreSQL understøtter tre standardisolationsniveauer: READ COMMITTED, REPEATABLE READ og SERIALIZABLE. (Teknisk set har PostgreSQL også READ UNCOMMITTED, men det fungerer som READ COMMITTED).

READ COMMITTED er PostgreSQL's standardisolationsniveau og det mest anvendte. Det giver en god balance mellem samtidighed og konsistens for mange programmer.

Med READ COMMITTED:

• Du kan ikke se ændringer fra andre transaktioner, som endnu ikke er bekræftet (forhindrer urene læsninger).
• Du kan se ændringer, som andre transaktioner har bekræftet, efter at din aktuelle sætning er begyndt.

Det betyder, at du kan få forskellige resultater, hvis du kører den samme SELECT-forespørgsel flere gange i en transaktion, og en anden transaktion bekræfter ændringer mellem dine SELECT-kommandoer.

Lad os illustrere READ COMMITTED med to sessioner:

1. Session A starter en transaktion.
2. Session A læser balance = 100.
3. Session B starter, opdaterer balance til 90 og bekræfter ændringen.
4. Session A læser balance igen. Fordi Session B har bekræftet ændringen, ser Session A nu balance = 90.

Denne adfærd er generelt acceptabel for mange programmer, fordi du altid ser bekræftede data, selv hvis de ændres under din transaktion.

Prøv at køre disse kommandoer i en PostgreSQL-klient. Vær opmærksom på resultatet af de to SELECT-sætninger.

Hvis du kørte UPDATE products SET price = 950 WHERE id = 1; COMMIT; i en separat klientsession mellem de to SELECT-sætninger nedenfor, ville den anden SELECT vise den opdaterede pris (950), mens den første ville vise den oprindelige pris (1000).

Isolationsniveauet REPEATABLE READ giver stærkere garantier end READ COMMITTED. Det sikrer, at data, som en transaktion læser, forbliver uændrede, så længe transaktionen varer.

Med REPEATABLE READ:

• Du kan ikke se ændringer, som endnu ikke er bekræftet (forhindrer urene læsninger).
• Du kan ikke se bekræftede ændringer fra andre transaktioner efter at din transaktion er startet (forhindrer ikke-gentagelige læsninger).

Det betyder, at du er garanteret at få det samme resultatsæt, hvis du kører den samme SELECT-forespørgsel flere gange, selv hvis andre transaktioner bekræfter ændringer i disse rækker.

SERIALIZABLE er det højeste isolationsniveau. Det garanterer, at resultatet af transaktioner, der udføres samtidigt, er det samme, som hvis de var blevet udført én efter én i rækkefølge.

Med SERIALIZABLE:

• Det forhindrer alle samtidighedsanomalier (urene, ikke-gentagelige og fantomlæsninger).
• Det giver den stærkeste datakonsistens.

Det har dog en pris. Transaktioner kan blive tvunget til at vente eller endda blive rullet tilbage (en serialiseringsfejl), hvis de er i konflikt med en anden transaktion, hvilket medfører større belastning og potentielt behov for nye forsøg.

Det er afgørende at vælge det rigtige isolationsniveau:

• READ COMMITTED: Godt til de fleste programmer, hvor der er behov for høj samtidighed, og mindre dataændringer under en transaktion er acceptable. Det er PostgreSQL's standard af en grund.
• REPEATABLE READ: Brug dette, når du skal sikre, at data, du har læst, ikke ændres under din transaktion, f.eks. ved komplekse rapporter eller dataanalyse, hvor det er vigtigt med et konsistent øjebliksbillede.
• SERIALIZABLE: Reserver dette til kritiske handlinger, der kræver absolut datakonsistens, f.eks. finansielle transaktioner eller lagersystemer, hvor ingen anomali kan accepteres. Vær forberedt på at håndtere serialiseringsfejl i programmets logik.

Godt gået! I denne lektion har du udforsket PostgreSQL's isoleringsniveauer for transaktioner.

• Du har lært om samtidighedsanomalier som beskidte læsninger, ikke-gentagelige læsninger og fantomlæsninger.
• Du har forstået, hvordan READ COMMITTED (standardindstillingen) forhindrer beskidte læsninger, men tillader de øvrige anomalier.
• Du har set, at REPEATABLE READ også beskytter mod ikke-gentagelige læsninger.
• Endelig giver SERIALIZABLE den stærkeste garanti ved at forhindre alle anomalier, men det kan medføre serialiseringsfejl.

Det er afgørende at vælge det rigtige isoleringsniveau for at afveje datakonsistens, programmets ydeevne og samtidighed.