Isolasjon i postgres og mysql

Transkript

1 Isolasjon i postgres og mysql Evgenij Thorstensen V19 Evgenij Thorstensen Isolasjon i postgres og mysql V19 1 / 20

2 Isolasjonsnivåer Read uncommitted Read committed Repeatable read Serializable SELECT... FOR UPDATE; Evgenij Thorstensen Isolasjon i postgres og mysql V19 2 / 20

3 Standarden Tre anomalier: Dirty read Nonrepeatable read Phantom read I virkeligheten er alt mer komplisert. Evgenij Thorstensen Isolasjon i postgres og mysql V19 3 / 20

4 Spørringer i transaksjoner SELECT (lese) UPDATE INSERT og DELETE For hver av disse, spesifiserer isolasjonsnivå hva som kan skje i denne transaksjonen. Evgenij Thorstensen Isolasjon i postgres og mysql V19 4 / 20

5 Hovedide, både postgres og mysql Multiversjonskontroll (MVCC) med låsing. Serializable håndteres spesielt i postgres, og feil i mysql. transaction-iso.html innodb-transaction-isolation-levels.html Evgenij Thorstensen Isolasjon i postgres og mysql V19 5 / 20

6 MVCC, hovedtrekk Lesing blokkerer ikke skriving, og skriving blokkerer ikke lesing. Bare skriving tar lås, og bare annen skriving må evt. vente. Dette fordi systemet lagrer flere versjoner av tupler. Evgenij Thorstensen Isolasjon i postgres og mysql V19 6 / 20

7 Bakgrunn: Datarep i mysql Clusterindeks på primærnøkkel, B-tre. Løvnoder er datablokker, alt er i samme fil. Dette vil påvirke låsemekanismene. Evgenij Thorstensen Isolasjon i postgres og mysql V19 7 / 20

8 Read uncommitted (mysql) SELECT ser nyeste versjoner av tupler. Inkludert ikke-committede, som forventet. UPDATE og INSERT/DELETE som i read committed. Evgenij Thorstensen Isolasjon i postgres og mysql V19 8 / 20

9 Read committed, postgres Default i postgres. Hver SELECT ser siste versjon av tupler committed før SELECT startet. UPDATE/DELETE etc. ser samme versjon. Hva med samtidig oppdatering? Evgenij Thorstensen Isolasjon i postgres og mysql V19 9 / 20

10 Read committed, postgres Default i postgres. Hver SELECT ser siste versjon av tupler committed før SELECT startet. UPDATE/DELETE etc. ser samme versjon. Hva med samtidig oppdatering? Hvis noen (U) har skrevet et tuppel mens vår T holdt på, skjer følgende: T venter til U blir ferdig; ved abort kan T fortsette ved commit(u) dobbeltsjekkes tuppelet, og oppdateres på ny verdi. Venting via låser, for å sikre atomærhet ingen tapte oppdateringer. Evgenij Thorstensen Isolasjon i postgres og mysql V19 9 / 20

11 Read committed, mysql Nesten det samme som i postgres. Men, i mysql låses indeksposter og ikke tabelltupler. By default en clusterindeks, og alt som den peker på låses midlertidig for UPDATE. Låsene som ikke trengs slippes etter at WHERE evalueres, men noe mer låsing. Igjen, tupler som andre har oppdatert må ventes på. Evgenij Thorstensen Isolasjon i postgres og mysql V19 10 / 20

12 Read committed, eksempel BEGIN; UPDATE website SET hits = hits + 1; -- run from another session: DELETE FROM website WHERE hits = 10; COMMIT; DELETE finner t med hits(t)=10, og venter på lås. Når UPDATE er ferdig får DELETE lås, men da er hits(t)=11. Den ser ikke det nye tuppelet med hits=10. Evgenij Thorstensen Isolasjon i postgres og mysql V19 11 / 20

13 Repeatable read, postgres Alle SELECT i T ser bare data committed før T begynte. Ser ikke oppdateringer og ikke inserts (fantomer) som skjer underveis. Evgenij Thorstensen Isolasjon i postgres og mysql V19 12 / 20

14 Repeatable read, postgres Alle SELECT i T ser bare data committed før T begynte. Ser ikke oppdateringer og ikke inserts (fantomer) som skjer underveis. UPDATE ser det samme som SELECT, men venting er FUW. Hvis noen (U) har skrevet et tuppel mens vår T holdt på, skjer følgende: T venter til U blir ferdig; ved abort kan T fortsette ved commit(u) rulles T tilbake fordi vi kan ikke få se den nye verdien! Evgenij Thorstensen Isolasjon i postgres og mysql V19 12 / 20

15 Repeatable read, mysql Pessimistisk strategi! Hver spørring ser bare data committed før den kjørte. I motsetning til postgres! UPDATE låser alle tupler den matcher/venter på å låse dem (i lesefasen). UPDATE med range condition (x < 100) låser gapet (!!) for INSERT. Men, ingen rollback. Evgenij Thorstensen Isolasjon i postgres og mysql V19 13 / 20

16 Rep. read, postgres vs. mysql Postgres: Skriving blokkerer ikke like mye låsing ved oppdatering. Men rollbacks mulig. MySQL: Ingen rollback, låsing ved lesing for oppdatering. Og låsing av gaps samtidig insert ikke tillatt. MySQL låser på indeks, hvis UPDATE-betingelse er ikke-indeksert låses index range scanned. Altså kan ikke samtidig UPDATE eller INSERT/DELETE skje i mysql men en samtidig insert kan skje mellom spørringer i en transaksjon (aaargh!) understanding-mysql-isolation-levels-repeatable-read/ Evgenij Thorstensen Isolasjon i postgres og mysql V19 14 / 20

17 Serializable, mysql Ikke helt serializable, men derom strides standard-tolkningene. Alle SELECT blir som om de er UPDATE, altså lås på gaps og rader. Men hvor er ekvivalensen til en seriell plan?? mysql-interprets-serializable-less-strenuously-than-po Evgenij Thorstensen Isolasjon i postgres og mysql V19 15 / 20

18 Serializable, mysql, mer Ikke helt serializable. Samtidig INSERT kan lykkes uten å bli sett. Samtidig oppdatering av forskjellige tupler feiler bare av og til... Så ikke egentlig serializable. Evgenij Thorstensen Isolasjon i postgres og mysql V19 16 / 20

19 Serializible, postgres Ekvivalent til en seriell plan. Håndteres med en slags presedensgraf (men lur). Kan føre til rollback. Rollback kan oppstå selv om to transaksjoner oppdaterer hver sine tupler (obligoppgave). Evgenij Thorstensen Isolasjon i postgres og mysql V19 17 / 20

20 SELECT FOR UPDATE Dette er en finkornet låsemekanisme. BEGIN; SELECT * FROM purchases WHERE processed = false FOR UPDATE; -- * application is now processing the purchases * UPDATE purchases SET...; COMMIT; Radene som ble selected låses for andres oppdateringer og for andres select for update. Evgenij Thorstensen Isolasjon i postgres og mysql V19 18 / 20

21 Isolasjonsnivåer, oppsummert Ved Read Committed vil samtidig oppdatering på samme tuppel fortsette hvis tuppelet matcher, med ny verdi tilgjengelig. Dette går bra hvis oppdateringen er x = f(x), og dårlig hvis den er basert på annen info. Ved Repeatable Read vil den feile/vente på alle låser. Serializable hindrer alt av interaksjoner (men ikke i mysql). Evgenij Thorstensen Isolasjon i postgres og mysql V19 19 / 20

22 Når bruke hva? I postgres: Read committed vs. repeatable read. I mysql: Repeatable read låser mye. Serializable koster, men kan garantere for store viktige ting. For enkel select-process-write er select for update bra. Evgenij Thorstensen Isolasjon i postgres og mysql V19 20 / 20