Samanaikaisuuden hallinta Snapshot Isolationin avulla

hyväksymispäivä arvosana arvostelija Samanaikaisuuden hallinta Snapshot Isolationin avulla Olli Korhonen Helsinki 4.3.2009 Seminaarityö HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Olli Korhonen Työn nimi Arbetets titel Title Tietojenkäsittelytieteen laitos Samanaikaisuuden hallinta Snapshot Isolationin avulla Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Seminaarityö 4.3.2009 12 sivua Tiivistelmä Referat Abstract Relaatiotietokantojen samanaikaisuuden hallintaan on SQL-standardissa asetettu tiettyjä vaatimuksia. Perinteisesti tietokannat ovat toteuttaneet vaatimukset 2-vaiheisen lukituksen avulla. Viime aikoina useat tietokannanhallintajärjestelmät ovat kuitenkin tehokkuusvaatimusten takia toteuttaneet eristyvyystason nimeltään Snapshot Isolation. Tässä työssä käydään läpi Snapshot Isolationin toiminta sekä sen yhteensopivuus SQL-standardin kanssa. Tämän lisäksi tutkitaan mahdollisia ratkaisuja esiin tulevien ongelmien ratkaisemiseksi. ACM Computing Classication System (CCS): H.2.4 [Database Management] Avainsanat Nyckelord Keywords Säilytyspaikka Förvaringsställe Where deposited Muita tietoja övriga uppgifter Additional information

Sisältö ii 1 Johdanto 1 2 Transaktioiden samanaikaisuus 1 2.1 Eristyvyys................................. 3 2.2 Eristyvyysanomaliat........................... 3 3 Snapshot Isolation 4 3.1 Määritelmä................................ 5 3.2 Eristyvyys................................. 5 3.3 Write Skew................................ 6 3.4 Transaktioiden sarjallistaminen..................... 8 3.5 Anomalioiden tunnistaminen....................... 9 4 Yhteenveto 10 Lähteet 12

1 Johdanto 1 Nykypäivänä tietokantoja löytyy yhä useammista paikoista. Yhä useammat järjestelmät käyttävät keskitettyjä, useiden käyttäjien, joskus useiden tuhansien, kymmenien tuhansien tai jopa miljoonien yhtäaikaisten käyttäjien tietokantoja. Relaatiotietokantojen valtakausi ei ole päättynyt, vaikka jotkut ovat aikojen saatossa niin ennustaneetkin. Samanaikaisuuden hallinta (concurrency control) on useiden käyttäjien tietokannoissa eräs merkittävä tekijä. Samanaikaiset, eri käyttäjien operaatiot täytyy naamioida niin, että käyttäjät kuvittelevat käyttävänsä tietokantaa yksin. Samaan aikaan täytyy pitää huoli siitä, etteivät käyttäjien tekemät operaatiot sotkeennu muiden tekemien operaatioiden kanssa. Relaatiotietokannoissa käytettävä SQL-standardi sisältää määrittelyn samanaikaisuuden hallinnalle ja luettelee vaatimukset, jotka tietokantamoottorin on toteutettava. Tämän työn aluksi esittelen lyhyesti, mitä standardissa määritellään. Standardin lähestymistapa ei ole ollut tehokas. Tämän vuoksi samanaikaisuuden hallintaan on kehitetty menetelmiä, jotka poikkeavat perinteisistä malleista. Eräs näistä menetelmistä on Snapshot Isolation, jonka useat nykyaikaiset tietokannanhallintajärjestelmät jo toteuttavat. Aion tässä työssäni kuvata, kuinka Snapshot Isolation toimii ja esitellä siihen liittyviä ongelmia mahdollisine ratkaisuineen. 2 Transaktioiden samanaikaisuus SQL-standardin (1992) [ANSI92] mukaan transaktio on tietokantaoperaatioiden suoritusten sarja, joka muodostaa atomisen kokonaisuuden. Transaktio on kokonaisuudessaan peruutettavissa niin, että kaikki sen aiheuttamat muutokset voidaan palauttaa.

2 Tietokantamoottori voi taata transaktioiden atomisuuden eri tavoin. Yksinkertaisimmillaan transaktiot suoritetaan peräkkäin niin, että vain yksi transaktio voi olla käynnissä kerrallaan. Tätä kutsutaan sarjalliseksi (serial) aikataulutukseksi. Tällainen tapa on monien käyttäjien tietokannoissa tehoton, joten transaktioiden suoritus yleensä limitetään. Tällöin aikataulutusta kutsutaan ei-sarjalliseksi (non-serial). Limitetyssä aikataulutuksessa kukin transaktio näkee tietokannan tilanteen kuten sarjallisessa, jos limitys toteuttaa sarjallistuvuuden (serializable) ehdon. Sarjallistuva transaktioiden suoritus tuottaa saman lopputuloksen kuin vastaavien transaktioiden sarjallinen suoritus. Kuvassa 1 ylhäällä olevien sarjallisten transaktioiden suoritus on transaktioiden kannalta sama kuin alla olevien samojen, mutta limitettyjen transaktioiden. Näin ollen alapuolella olevat transaktiot ovat sarjallistuvia. Kuva 1: Sarjallinen ja sarjallistuva transaktioiden suoritus

2.1 Eristyvyys 3 Transaktioiden ACID-mallin mukainen eristyvyys (isolation) tarkoittaa sitä, että kunkin transaktion T näkökulmasta tietokanta näyttää siltä, että muut transaktiot ovat suoritettuja kokonaan joko ennen T:n suorittamista tai että muut transaktiot suoritetaan kokonaisuudessaan T:n jälkeen. Eristyvyys voi kuitenkin rikkoontua transaktioiden ei-sarjallisen suorituksen yhteydessä. SQL-standardissa transaktioiden eristyvyydelle määritellään neljä tasoa: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ ja SE- RIALIZABLE, joista viimeinen on kaikkein tiukin ja standardin mukaan toteuttaa sarjallistuvuuden ehdon. Muut tasot eivät takaa täyttä sarjallistuvuutta, vaan voivat aiheuttaa virhetilanteita, joita kutsutaan eristyvyysanomalioiksi. Riippuen transaktioiden luonteesta, voidaan kullekin transaktiolle määrittää haluttu eristyvyystaso. Valinta tapahtuu aina tehokkuuden ja sarjallistuvuuden vaatimusten välillä. Mitä tiukempi eristyvyystaso vaaditaan, sitä tehottomampi systeemistä tulee. 2.2 Eristyvyysanomaliat Anomalioita, jotka rikkovat sarjallistuvuuden on useita. Yleisimmin mainitaan neljä anomaliaa, jotka voivat tapahtua transaktioiden suorituksen limittyessä: dirty write, dirty read, fuzzy read (non-repeatable read) ja phantom read. Näistä kolme viimeisintä mainitaan SQL-standardissa, mutta ensimmäinen, dirty write on myös merkityksellinen ja on mainittu jo Berensonin ja kumppaneiden vuonna 1995 ilmestyneessä kritiikissä SQL-standardin eristyvyyden tasoista [BBG95]. Eri eristyvyyden tasoilla estetään eri anomaliat. Taulukossa 1 on kuvattu eristyvyyksien ja anomalioiden suhteet. Perinteinen ratkaisu näiden anomalioiden estämiseen on ollut 2-vaiheisen lukituksen

4 Dirty Write Dirty Read Fuzzy Read Phantom Read READ UNCOMMITTED Ei Kyllä Kyllä Kyllä READ COMMITTED Ei Ei Kyllä Kyllä REPEATABLE READ Ei Ei Ei Kyllä SERIALIZABLE Ei Ei Ei Ei Taulukko 1: Eristyvyystasot ja anomaliat käyttö. Tällöin lukituksen avulla estetään anomalioiden toteutuminen transaktioiden suorituksen aikana. Anomalian aiheuttavan transaktion suoritus estetään niin pitkäksi aikaa, kunnes tarvittavat resurssit vapautuvat. 3 Snapshot Isolation Perinteistä, lukituksen avulla ratkaistua transaktioiden hallintaa kutsutaan pessimistiseksi samanaikaisuuden hallinnaksi. Tällöin ikään kuin oletetaan, että jotain menee luultavasti pieleen ja siihen varaudutaan etukäteen. Mahdolliset ongelmatilanteet pyritään estämään jo kantatasolla. Toisenlaista lähestymistapaa, jossa ei transaktiot eivät estä toistensa suoritusta, kutsutaan optimistiseksi. Optimistisessa hallintatavassa virhetilanteiden hoitaminen jätetään usein sovelluksen harteille. Tämän mallin mukaan oletetaan, että asiat menevät hyvin, joten niihin ei tarvitse puuttua etukäteen. Vasta transaktion lopuksi katsotaan, voidaanko haluttuja operaatioita suorittaa. Aion seuraavaksi esitellä optimistisen mallin mukaisen lähestymistavan nimeltä Snapshot Isolation.

3.1 Määritelmä 5 Määritelmän [BBG95] mukaan Snapshot Isolation takaa kullekin transaktiolle koko suorituksen ajaksi tilannevedoksen (snapshot) tietokannasta sellaisena, kuin se oli transaktion alkaessa. Pelkkiä lukuoperaatioita sisältävät transaktiot toteutuvat näin ollen aina. Kirjoitusoperaatioita tekevien transaktioiden kohdalla tutkitaan vasta sitoutumisen (commit) yhteydessä, voidaanko transaktion toteuttamat muutokset tehdä. Snapshot Isolationin määritelmän mukaan transaktiolle T annetaan sen suorituksen alkaessa aikaleima Tb. Kun transaktio pyytää sitoutumista (aikaleima Tc), tutkitaan, onko mikään muu transaktio päivittänyt muutettavaa tietoa transaktion T suorituksen aikana, eli toisin sanoen aikavälillä [Ta,Tb]. Jos ei ole, voidaan muutokset tehdä ja transaktio sitouttaa (kuva 2 T2). Jos muutoksia on tapahtunut niin, että toisen transaktion U aikaleima Ub on välillä [Ta,Tb], keskeytetään koko transaktio T ja palautetaan virheilmoitus (kuva 2 T1). Tätä kutsutaan myös nimellä First Committer Wins. Kuva 2: First Committer Wins 3.2 Eristyvyys SQL-standardissa määritellyt anomaliat estetään kokonaan Snapshot Isolationissa. Lukuanomaliat estyvät, koska transaktio näkee koko suorituksensa ajan saman tietokannan tilan, mikä oli voimassa sen alkaessa. Kirjoitusanomalia estyy, koska kir-

6 joitusta ei tehdä tapauksessa, jossa jokin muu transaktio on ehtinyt muuttaa tietoa transaktion suorituksen aikana. Snapshot Isolationin määritelmän mukaisesta heikosta eristyvyydestä (weak isolation) seuraa uusia anomalioita. Vaikka näyttää siltä, että kaikki lukuoperaatiot olisivat turvallisia, ei niin todellisuudessa ole (read only anomaly) [FOO04]. Tämä tapaus on tutkimuksen perusteella niin harvinainen, ettei sitä saatu tapahtumaan laajoissakaan testeissä. Jätän asian näin ollen käsittelemättä tässä tekstissä. Kirjoitusoperaatioita suorittavat transaktiot, jotka käsittelevät eri tietueita, joissa tietueille on asetettu rajoitteita (constraint), voivat aiheuttaa kirjoitusvääristymän (write skew). Tämä on yleisempi ja paljon enemmän harmia aiheuttava anomalia, joten paneudun siihen. 3.3 Write Skew Snapshot Isolationin määritelmästä seuraa uusi anomalia, kirjoitusvääristymä (write skew). Kun kaksi prosessia päivittää toisistaan rajoitteilla riippuvia tietoja, voi tapahtua kaksi toisistaan riippumatonta päivitystä, jotka rikkovat asetetun rajoituksen. Kuvitellaan esimerkiksi tilanne, jossa henkilöllä on kaksi pankkitiliä X ja Y. Pankki on asettanut rajoituksen, että tilien yhteenlaskettu saldo täytyy aina olla plussan puolella, toisin sanoen X + Y > 0. Oletetaan alkutilanne, jossa X=50 ja Y=50. Kaksi transaktiota T1 ja T2 suorittavat kuvan 3 mukaiset toimenpiteet. Suoritetaan T1(X, 50) ja T2(Y, 60). Tällöin suoritettavien operaatioiden järjestys voisi olla esimerkiksi seuraavanlainen (myös kuva 4). T1b, T2b, R1(x=50), R2(y=50), W1(X, 0), W2(Y, -10), R1(Y=50), R2(X=50), C1, C2.

7 parametrit @tili ja @summa BEGIN TRANSACTION R(@tili) jos tilisumma yli @summa W(@tili, tilisumma-@summa) if (R(X) + R(Y) > 0) COMMIT else ROLLBACK END TRANSACTION Kuva 3: Tilitapahtuman suorittava transaktio Kuva 4: Write Skew Ehto X + Y > 0 toteutuu molemmissa transaktioissa. T1:n mukaan tilanne on lopussa X + Y = 50 ja T2:n mielestä X + Y = 40. Tämä tapahtui siis, koska kumpikaan ei näe toisen tekemää muutosta. Toisaalta myöskin Snapshot Isolationin määritelmän mukainen First Committer Wins -ehto toteutuu, koska molemmat transaktiot käsittelevät eri tiliä ja näin ollen kumpikin transaktio voi sitoutua. Lopussa tilanne on kuitenkin X + Y = -10, mikä tarkoittaa, että asetettu rajoite on rikkoontunut. Write Skewn aiheuttavassa tilanteessa kahden transaktion välille muodostuu riippuvuus, jossa toinen lukee ja toinen päivittää tietoa samanaikaisesti käynnissä olevissa

transaktioissa. Tällöin puhutaan read write (rw) -riippuvuudesta. Edellä kuvatussa tilanteessa molemmat transaktiot ovat rw-riippuvaisia toisistaan. 8 3.4 Transaktioiden sarjallistaminen Snapshot Isolation ei itsessään takaa sarjallistuvia transaktioita. Jotkin tietokantamoottorit, kuten Oracle 1 ja PostgreSQL, 2 eivät takaa sarjallistuvuutta lainkaan tietokannoissaan, vaan jättävät rajoitteiden tarkastuksen sovellustason huoleksi. Esimerkiksi Microsoft SQL Server taas käyttää sarjallistuvuuden saavuttamiseksi perinteistä 2-vaihelukitusta sekoitettuna Snapshot Isolationiin. On olemassa menetelmiä, joiden avulla sarjallistuvuus voidaan saavuttaa myös aidossa Snapshot Isolationissa. Tämä toki saavutetaan osittain tehokkuuden kustannuksella. Jotkut ehdotetut menetelmät perustuvat koniktien materialisoimiseen [FLO05]. Näissä menetelmissä aiheutetaan tahallaan tilanne, josta seuraa virhe. Tämän jälkeen joku transaktioista keskeytetään First Committer Wins -ehdon perusteella. Tällaiset keinot täytyy ottaa huomioon järjestelmää suunnitellessa. Osa menetelmistä perustuu järjestelmän staattiseen analyysiin. Tällöin järjestelmä analysoidaan etukäteen ja esiin tulleet anomalioita aiheuttavat tilanteet ratkaistaan sovellustasolla jo suunnitteluvaiheessa. Tällainen järjestely kuvataan esimerkiksi Jorwerkarin ja kumppaneiden artikkelissa [JFR07]. Kyseisessä artikkelissa kuvataan myös työkalu, jonka avulla anomalioita aiheuttavat transaktiot voidaan löytää automaattisesti. Ehkäpä mielenkiintoisin ja monikäyttöisin lähestymistapa on tutkia transaktioita ajonaikaisesti ja yrittää tunnistaa mahdolliset vaaroja aiheuttavat tilanteet. Tällainen dynaaminen menetelmä, jossa anomalioita aiheuttavat tilanteet ratkaistaan 1 http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html 2 http://www.postgresql.org/docs/8.1/interactive/transaction-iso.html

9 suorituksen aikana on kuvattu Cahillin ja kumppaneiden artikkelissa.[crf08]. 3.5 Anomalioiden tunnistaminen Molemmat tavat, niin staattinen kuin dynaaminenkin anomalioita aiheuttavien transaktioiden tunnistaminen perustuvat transaktioiden riippuvuuksiin. Riippuvuuksista voidaan muodostaa kaavio, jonka perusteella tunnistetaan vaaralliset rakenteet ja näin ollen kohdat, joissa Write Skew voi tapahtua. Fekete ja kumppanit ovat todistaneet [FLO05], että vaarallisissa rakenteissa on sykli, jossa on kaksi rw-riippuvaista transaktiota. Tämä tilanne on kuvattu kuvassa 5. Tässä transaktiota T0 kutsutaan napatransaktioksi (pivot transaction). Navan poistaminen poistaa mahdollisen vaaratilanteen koko kaavioista. Kuva 5: Transaktioiden riippuvuuksista aiheutuva vaarallinen tilanne

10 Järjestelmän sarjallistaminen perustuu näiden syklien tunnistamiseen ja poistamiseen. Staattisesti tämä tapahtuu jo järjestelmän suunnitteluvaiheessa joka automaattisesti tai suunnittelijan toimesta. Staattisessa lähestymistavassa on se ongelma, että järjestelmän muuttuessa analyysi täytyy tehdä uudelleen ja muuttaa kaikki mahdollisesti muodostuneet ongelmapaikat. Voi olla, että tämä ei aina ole edes mahdollista, joten on kehitettävä malli, jossa anomaliat etsitään ja korjataan ajonaikaisesti. Tällainen dynaaminen malli esitellään Cahillin ja kumppaneiden artikkelissa [CRF08]. Järjestelmä etsii samaan aikaan suorittettavien transaktioiden välisiä riippuvuuksia tallettamalla kuhunkin transaktioon tietoa mahdollisista vaaratilanteista. Vaaratilanteen huomatessaan järjestelmä keskeyttää napatransaktion ja näin ollen poistaa vaaran. Artikkelissa kuvattu järjestelmä ei ole täydellinen, vaan tietyissä tilanteissa aiheuttaa vääriä positiivisia havaintoja ja transaktioiden keskeytymisiä. Cahillin ja kumppaneiden artikkelissa [CRF08] on esitetty dynaamisen mallin toteutus ilmaisen Oracle Berkeley DB -tietokantamoottorin 3 päälle. Artikkelin analyysissa tultiin siihen tulokseen, että järjestelmä toimii suurinpiirtein yhtä hyvin kuin Snapshot Isolation ilman sarjallistuvuutta. Ero perinteiseen 2-vaihelukitukseen on huomattava. 4 Yhteenveto Snapshot Isolation on mielenkiintoinen ja useissa tietokantamoottoreissa toteutettu transaktioiden hallintamalli. On selkeästi osoitettu, että Snapshot Isolationin avulla saavutetaan tehokkaampi toiminta kuin perinteisen 2-vaihelukituksen kanssa, eristyvyystason karsimättä. Snapshot Isolation itsessään takaa melkein sarjallistuvan transaktioiden eristyvyyden. 3 http://www.oracle.com/technology/products/berkeley-db/

11 Nykyiset Snapshot Isolationin toteuttavat tietokantamoottorit joko eivät toteuta sarjallistuvia transaktioita tai toteuttavat ne perinteisen lukituksen avulla. On kehitetty malleja, joiden pohjalta todellinen sarjallistuvuus saadaan aikaiseksi myös käyttäen aitoa Snapshot Isolationia.

Lähteet 12 ANSI92 ANSI Information Systems Database Language SQL, 1992. http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt. [26.2.2009] BBG95 Berenson, H., Bernstein, P., Gray, J., Melton, J., O'Neil, E. ja O'Neil, P., A critique of ansi sql isolation levels. SIGMOD '95: Proceedings of the 1995 ACM SIGMOD international conference on Management of data, New York, NY, USA, 1995, ACM, sivut 110. CRF08 Cahill, M. J., Röhm, U. ja Fekete, A. D., Serializable isolation for snapshot databases. SIGMOD '08: Proceedings of the 2008 ACM SIGMOD international conference on Management of data, New York, NY, USA, 2008, ACM, sivut 729738. FLO05 Fekete, A., Liarokapis, D., O'Neil, E., O'Neil, P. ja Shasha, D., Making snapshot isolation serializable. ACM Trans. Database Syst., 30,2(2005), sivut 492528. FOO04 Fekete, A., O'Neil, E. ja O'Neil, P., A read-only transaction anomaly under snapshot isolation. SIGMOD Rec., 33,3(2004), sivut 1214. JFR07 Jorwekar, S., Fekete, A., Ramamritham, K. ja Sudarshan, S., Automating the detection of snapshot isolation anomalies. VLDB '07: Proceedings of the 33rd international conference on Very large data bases. VLDB Endowment, 2007, sivut 12631274.