Presentasjon av doktorgradsprosjekt Fredag Jon Grov Tre deler Del 1 - litt om transaksjonshåndtering. Del 2 - om doktorgradsarbeidet. Del 3 - bittelitt om Python og SimPy (bare hvis vi har tid). 1 av 14
Del 1 Transaksjonshåndtering Transaksjoner brukes for å sikre konsistent lesing og skriving av kritiske data, og er en viktig komponent i systemer som håndterer bestillinger, penger, aksjer, logistikk osv. En transaksjon kan sees som en sekvens av lese- og skrivetransaksjoner. Eksempel: t = r(x), r(y), w(y). ACID: Atomicity, Consistency, Isolation and Durability. 2 av 14
Transaksjoner og replikering Vi ser på transaksjonshåndtering i store replikerte databaser, hvor det høye antallet skriveoperasjoner begrenser skaleringsevnen: Én node r(x) r(y) w(y) c Fire noder r(x) r(y) w(y) w(y) w(y) w(y) c c c c Skaleringsproblemet er knyttet til isolasjonskravet, som ofte innebærer krav om serialiserbarhet. Dvs. at for utførelsen av flere samtidige transaksjoner skal det finnes en seriell utførelse som gir samme sluttilstand. 3 av 14
Serialiserbarhet En eksekveringsplan beskriver rekkefølgen for utførelsen av operasjonene i flere transaksjoner. Eksempel: s = r 1 (x), r 2 (x), w 1 (x), c 1, w 2 (x), c 2 Vi er interessert i konfliktserialiserbarhet: Skriveoperasjoner fører til konflikter, og i s har vi konfliktene [r 1 (x), w 2 (x)], [r 2 (x), w 1 (x)] og [w 1 (x), w 2 (x)]. Generelt er en plan p konfliktserialiserbar dersom det finnes en seriell plan p s hvor vi for hver konflikt har at rekkefølgen av transaksjonene er den samme i p og p s. Vi ser av figuren at s ikke er serialiserbar. t i x x t j 4 av 14
Tofase låsing Leseoperasjoner krever leselåser og skriveoperasjoner skrivelåser. Leselåser kan deles, mens skrivelåser er eksklusive. Tofase-låsing garanterer serialiserbarhet ved at ingen låser kan slippes før transaksjonen har fått alle låsene den trenger. Sårbar for vranglåser. Ant. låser Serialiseringspunkter Tid 5 av 14
Tofase låsing og replikering Antall avbrudd på grunn av vranglåser blir utålelig i databaser replikert over mange noder. Ved full replikering øker frekvensen av vranglåser med noder 3. Jim Gray konkluderte i 1996 slik: «Simple replication (transactional update-anywhere-anytime-anyway) cannot be made to work with global serializability» 6 av 14
Alternativer til tofase låsing Optimistisk samtidighetskontroll, hvor transaksjonene valideres før committ. Dersom eksekveringen ikke valideres må transaksjonen restartes. Tidsstempling, hvor vi for en konflikt [o i, o j ] restarter t j dersom ts(t i ) > ts(t j ) Multiversjonsalgoritmer, hvor tidligere versjoner beholdes ved oppdatering. Vi unngår dermed låser for lesetransaksjoner ved å lese eldre versjoner om nødvendig. Replikeringsgrafbaserte algoritmer vedlikeholder en komprimert serialiseringsgraf. Dersom det for en gitt plan finnes en asyklisk replikeringsgraf, er planen serialiserbar. 7 av 14
Del 2 Doktorgradsprosjekt «Scalability and Transaction Isolation with Replication» Veiledes av Ragnar Normann, Stein Krogdahl og Ellen Munthe-Kaas. Mål: Få oversikt over «state of the art». Rangere effektiviteten til ulike metoder for samtidighetskontroll replikerte databaser ved hjelp av en simuleringsmodell. Implementere og måle den beste i MySQL eller PostgreSQL (muliggjør testing mot «offisielle» benchmarks). 8 av 14
Framdrift så langt Laget simulatoren «STIRSIM» Implementert og målt en låsbasert og en replikeringsgraf-basert protokoll for samtidighetskontroll. Begge ble målt med og uten multiversjonsstøtte. Tidligere publiserte resultater indikerer at replikeringsgraf-protokoller skalerer overlegent bedre enn låsbaserte. Målingene våre bekrefter at protokollen med replikeringsgraf skalerte best, men at forskjellene var mindre enn i tidligere målinger. I de valgte eksperimentene oppnådde vi dramatisk bedre ytelse ved å eliminere lesetransaksjoner ved hjelp av multiversjoner. 9 av 14
Utfordringer Replikeringsgraf-protokollen avhenger av at replikeringsgrafen lagres ved en node. Ingen av alternativene håndterer lange transaksjoner som inneholder oppdateringer. Simulatoren og simuleringsmodellen kan gjøres mer realistisk. 10 av 14
Del 3 Python og SimPy Om Python Interpretert «skriptspråk». Dynamisk typing. God støtte for objektorientering. Om SimPy http://simpy.sourceforge.net/ Gratis, Python-basert rammeverk for discrete-event simulering (sterk inspirert av Simula) NB Jeg er Python-novise, og har ingen tidligere erfaring med simuleringsverktøy! 11 av 14
Et bittelite SimPy program 1 #!/usr/bin/env python 2 3 from SimPy.Simulation import * 4 from random import expovariate,seed 5 6 class Source(Process): 7 """ Source generates customers randomly""" 8 9 def generate(self,number,interval): 10 for i in range(number): 11 c = Customer(name = "Customer%02d"%(i,)) 12 activate(c,c.visit(timeinbank=12.0)) 13 t = expovariate(1.0/interval) 14 yield hold,self,t 15 16 class Customer(Process): 17 """ Customer arrives, looks round and leaves """ 18 19 def visit(self,timeinbank=0): 20 print "%7.4f %s: Here I am"%(now(),self.name) 21 yield hold,self,timeinbank 22 print "%7.4f %s: I must leave"%(now(),self.name) 23 24 def model(): 25 seed(99999) 26 initialize() 27 s=source(name= Source ) 28 activate(s,s.generate(5,10.0),0.0) 29 simulate(until=400.0) 30 31 model() 12 av 14
Min mening om Python Positivt: Godt miljø for «vitenskapelig» bruk (Numerical Python, SimPy, matplotlib). Godt og robust runtime-miljø! Det enkle er enkelt, det vanskelige mulig. Negativt: Blokkavgrensning med whitespace er ikke bare fint. Lite utbredt i produksjonsmiljøer, selv om Google er svært aktive Python-brukere. 13 av 14
Min mening om SimPy Positivt: Opphavsmennene virker svært imøtekommende og kompetente. God kvalitetssikring. Negativt: Savner ferdige moduler for å simulere nettverk, disker o.l. Suboptimalt at for hver prosess må all venting skje i samme metode. 14 av 14