PostgreSQL kommer med solide, tidstestede funktioner, der lader dig definere præcist, hvad der skal ske, når flere klienter forsøger at opdatere de samme data samtidigt. En af dem er isolationsniveauet for transaktioner.
Læs videre for at lære mere om, hvordan transaktionsisolering fungerer i PostgreSQL.
Transaktioner og isolationsniveau
Transaktioner er den grundlæggende måde at mutere data på i et RDBMS. Moderne RDBMS tillader mere end én transaktion at køre samtidigt og kommer følgelig med en række værktøjer - nogle standard, nogle RDBMS-specifikke - for applikationsudviklere til at specificere, hvordan deres transaktioner skal eller ikke skal interagere med andre transaktioner.
Transaktionsisolationsniveauer og pessimistiske låse er to sådanne værktøjer. Selvom disse er nødvendige for dataintegritet og ydeevne, er de desværre ikke intuitive at forstå eller bruge.
Isolationsniveauet for en transaktion i PostgreSQL kan være et af:
- Læs forpligtet
- Gentagelig læsning
- Serialiserbar
Hver transaktion har sit isolationsniveau indstillet til en af disse, når den oprettes. Standardniveauet er "læs committed".
Bemærk, at SQL-standarden også definerer "læs uforpligtet", som ikke understøttes i Postgres. Du skal bruge det nærmeste højere niveau af "læs forpligtet".
Lad os se, hvad disse niveauer betyder.
Læs forpligtet
Hvad sker der, når en (ufærdig) transaktion indsætter rækker i en tabel, og den anden (også ufærdige) transaktion forsøger at læse alle rækker i tabellen? Hvis denne anden transaktion er i stand til at se rækkerne indsat af den første, så kaldes den en dirty read – fordi den første transaktion kan rulle tilbage, og denne anden transaktion ville have læst "fantom"-rækker, der aldrig har eksisteret.
Den læste forpligtede isolationsniveau garanterer, at beskidte aflæsninger aldrig vil ske. Her er et eksempel:
Som du kan se, kunne den anden transaktion ikke læse den første transaktions endnu ikke-forpligtede data. I PostgreSQL er det ikke muligt at sænke isolationsniveauet til under dette niveau, så beskidte læsninger er tilladt.
Gentagelig læsning
Endnu et andet problem er læsninger, der ikke kan gentages. Disse sker, når en transaktion læser en række, og så læser den igen lidt senere, men får et andet resultat - fordi rækken blev opdateret ind imellem af en anden transaktion. Læsningen er blevet ikke-gentagelig , som vist i dette eksempel:
For at løse dette problem skal du indstille isolationsniveauet for transaktionen til "repeatableread". PostgreSQL vil derefter sikre, at den anden (eller en hvilken som helst) læsning også vil returnere det samme resultat som den første læsning. Her er det samme scenarie på det opgraderede isolationsniveau:
Bemærk, at isolationsniveauet blev angivet sammen med BEGIN-sætningen. Det er også muligt at angive dette på forbindelsesniveau (som en forbindelsesparameter), som en konfigurationsparameter (default_transaction_isolation )og ved at bruge SET TRANSACTION-sætningen.
Serialiserbar
Det næste isolationsniveau løser problemet med tabte opdateringer . Opdateringer, der udføres i én transaktion, kan gå tabt eller overskrives af en anden transaktion, der tilfældigvis kører samtidigt, som vist her:
Her blokerer den anden transaktions OPDATERING, fordi PostgreSQL låser for at forhindre en anden opdatering, indtil den første transaktion er færdig. Den første transaktions ændring går dog tabt, fordi den anden "overskrev" rækken.
Hvis denne form for adfærd ikke er acceptabel, kan du opgradere isolationsniveauet til at serialisere:
På dette niveau mislykkes commit af den anden transaktion. Den anden transaktions handlinger var baseret på fakta, der blev gjort ugyldige på det tidspunkt, hvor den skulle udføres.
Selvom serialisering giver det højeste sikkerhedsniveau, betyder det også, at applikationen skal opdage sådanne commit-fejl og prøve hele transaktionen igen.