DDBS. Distribuerte databasesystemer

UNIVERSITETET I OSLO DDBS Distribuerte databasesystemer Ragnar Normann INF5030 8. og 15.9.2005 Ragnar Normann 1

Støttelitteratur Özsu & Valduriez: Principles of Distributed Database Systems Second Edition Prentice Hall 1999 Denne forelesningen er i all hovedsak basert på fremstillingen i denne boken INF5030 8. og 15.9.2005 Ragnar Normann 2

Oversikt over relevante temaer Nødvendige og ønskede forkunnskaper Hensikten med DDBSer DDBMS arkitekturer Fragmentering og allokering (overfladisk) Spørringer (blir ikke behandlet i INF5030) Transaksjoner (hovedtema i resten av kurset) Distribuerte objektdatabaser Pålitelighet (reliability) (foreleses neste uke) INF5030 8. og 15.9.2005 Ragnar Normann 3

Ønskelig: Datanettverk Forkunnskaper Topologi (stjerne- og ringnett, buss-nett) Kommunikasjonsmåter (punkt-til-punkt, kringkasting) ISO/OSI 7-lagsmodell Nødvendig: Databaser og DBMSer tilsvarende pensum i INF3100/INF4100 I tillegg skal/kan vi få bruk for to avledbare relasjonsalgebraoperatorer: semijoin og divisjon INF5030 8. og 15.9.2005 Ragnar Normann 4

ISO/OSI-modellen 7 Applikasjonslaget (brukerprogrammer og -prosesser) 6 Presentasjonslaget (datarepresentasjon og kryptering) 5 Sesjonslaget (setter opp og tar ned forbindelser i full eller halv duplex, lager sjekkpunkter o.l.) 4 Transportlaget (transparent og pålitelig dataoverføring mellom to brukere/prosesser ved å styre rekkefølge og nødvendig retransmisjon av pakker (TCP)) 3 Nettverkslaget (overføring av pakker med variabel størrelse mellom to logiske adresser (IP, routere)) 2 Datalinklaget (overføring av «dataframes» mellom to nabonoder med fysisk (hardkodet) flat adressering (Ethernet, HDLC)) 1 Det fysiske laget (kabler, kontakter og transmisjonssignaler for overføring av bits (hub, SCSI)) INF5030 8. og 15.9.2005 Ragnar Normann 5

Litt databasehistorie - I Bachman & Williams: A General Purpose Programming System for Random Access Memories [1964] beskrev IDS IDS (Integrated Data Store) var det første kommersielle DBMS, en 2-skjemaarkitektur nettverksdatabase Ett skjema som ga en fullstendig beskrivelse av databasen Ett eller flere subskjema tilpasset hver enkelt applikasjon (applikasjonenes vindu mot databasen) Begrepet datauavhengighet stammer herfra INF5030 8. og 15.9.2005 Ragnar Normann 6

Litt databasehistorie - II Det ble fort klart at 2-skjemaarkitektur ikke var bra nok I 1971 foreslo CODASYL DBTG (Committee on Data Systems Languages, Data Base Task Group) å splitte det sentrale skjema i to: Et logisk (begrepsmessig) skjema Et fysisk (internt) skjema ANSI/SPARC (ANSI Standards Planning And Requirement Committee) foreslo dette som standard i 1978 Det begrepsmessige skjema ble ISO-standard i 1982 (sub-skjemaene ble her kalt eksterne skjemaer) Vi fikk dermed to former for datauavhengighet: Fysisk mellom internt og begrepsmesig skjema Logisk mellom begrepsmessig og eksternt skjema INF5030 8. og 15.9.2005 Ragnar Normann 7

3-skjemaarkitekturen INF5030 8. og 15.9.2005 Ragnar Normann 8

Semijoin La R og S være to relasjoner. Kall Rs skjema A og S skjema B. Semijoinen av R med S over et joinpredikat θ er de tuplene i R som ville ha deltatt i en θ-join med S. R " S = # A R " S ( ) = R " # A$B S ( ) INF5030 8. og 15.9.2005 Ragnar Normann 9

Divisjon La R og S være to relasjoner slik at S skjema er en delmengde av Rs skjema. Kall S skjema for B og la A være de attributtene i R som ikke er med i B. Da er R dividert på S de tuplene t i π A (R) hvor tu er et tuppel i R for alle tupler u i S R S = " A ( R) \ " " R A A (( ( ) # S) \ R) INF5030 8. og 15.9.2005 Ragnar Normann 10

Distribuerte databaser (DDBer) (Snever definisjon) En distribuert database er en samling av flere logisk relaterte databaser som er forbundet med et datanettverk «Logisk relatert» betyr at det skal finnes et overordnet (globalt) skjema som definerer (den semantiske) sammenhengen mellom de ulike databasene Merk at multiprosessorsystemer med felles hukommelse ikke regnes som DDBer INF5030 8. og 15.9.2005 Ragnar Normann 11

DDBMSer Et DDBMS er et program med to hovedoppgaver: Det skal håndheve de semantiske reglene gitt av det globale skjemaet Det skal gjøre distribusjonen av data transparent for brukerne INF5030 8. og 15.9.2005 Ragnar Normann 12

Fordeler med DDBSer Transparent håndtering av distribuerte og replikerte (kopierte) data Økt pålitelighet og tilgjengelighet med bruk av distribuerte transaksjoner replikater horisontal fragmentering Økt ytelse pga mindre nettverkstrafikk Forenklet håndtering av systemvekst INF5030 8. og 15.9.2005 Ragnar Normann 13

Problemer og forskningsområder INF5030 8. og 15.9.2005 Ragnar Normann 14

Taksonomi for DBMS-arkitekturer For å beskrive ulike DBMS-arkitekturer er det vanlig å bruke tre uavhengige (ortogonale) egenskaper: Autonomi Distribusjon Heterogenitet Arkitekturene klassifiseres altså som punkter i et tredimensjonalt ADH-rom INF5030 8. og 15.9.2005 Ragnar Normann 15

Autonomi Autonomi handler ikke om distribusjon av data, men om distribusjon av kontroll Vi opererer med tre klasser av autonomi: A0: Tett integrasjon (ingen autonomi) A1: Semiautonomi (delvis autonomi) A2: Total isolasjon (full autonomi) Det finnes andre inndelinger, men vi skal holde oss til disse tre i dette kurset INF5030 8. og 15.9.2005 Ragnar Normann 16

De tre autonomiklassene A0: Klassiske distribuerte databaser Alle brukere ser samme logiske database. Det finnes bare ett felles begrepsmessig skjema, men hver node har sitt eget interne skjema. A1: «Federated databases» Nodene har hvert sitt begrepsmessig skjema, men er enige om at visse data skal være felles. Disse fellesdataene distribueres via et felles eksternt skjema som gjerne kalles eksportskjemaet. A2: Multidatabaser De enkelte databasene vet ikke om hverandre, så all koordinering mellom nodene er applikasjonenes (eller mellomvarens) ansvar INF5030 8. og 15.9.2005 Ragnar Normann 17

Distribusjon Denne dimensjonen klassifiserer graden av fysisk distribusjon av dataene (Vi forutsetter distribusjontransparens, dvs at distribusjonen er usynlig for brukerne) Vi opererer med tre grader av distribusjon: D0: Ingen distribusjon De logiske nodene ligger på samme fysiske node D1: Delvis distribusjon Én sentral database, flere satelitter (client/server) D2: Full distribusjon Flere likeverdige databasenoder (peer-to-peer (P2P)) INF5030 8. og 15.9.2005 Ragnar Normann 18

Heterogenitet Heterogenitet kommer i mange varianter (som hardware, nettverk, spørrespråk, transaksjonsprotokoller, datamodeller og DBMSer) Vi forenkler til to klasser: H0: Homogene systemer Systemene har samme DBMS (og som oftest samme OS og hardware) H1: Heterogene systemer (alt annet enn H0) INF5030 8. og 15.9.2005 Ragnar Normann 19

Arkitekturrommet Vi har definert 18 mulige arkitekturer, men ikke alle er like relevante Homogene systemer på samme node er forholdsvis sjeldne, men (A2,D0,H0) forekommer INF5030 8. og 15.9.2005 Ragnar Normann 20

Bruk av multidatabaser (A2) Det er to måter å aksessere en multidatabase på: Brukerapplikasjonene håndterer selv all kontakt med (de autonome) databasenodene Brukerapplikasjonene kontakter databasenodene via et mellomvareprogram Et slikt mellomvareprogram forutsetter at det finnes et globalt begrepsmessig skjema som brukerne kan forholde seg til Mellomvaren vil tolke brukernes transaksjoner og generere subtransaksjoner til de berørte databasenodene INF5030 8. og 15.9.2005 Ragnar Normann 21

Fragmentering Vi skal ikke gå i detalj her, men det finnes algoritmer for å finne optimal fragmentering ut fra statistisk kunnskap om applikasjonene Merk at fragmentering innenfor samme node kan øke effektiviteten merkbart Eksempel: Anta at relasjonen R har en fremmednøkkel til relasjonen S med de horisontale fragmentene S 1,...,S m. Da vil en fragmentering R k = R S k kunne effektivisere en join av R med S betydelig. INF5030 8. og 15.9.2005 Ragnar Normann 22

Allokering Problem: Gitt en mengde noder, en mengde partisjoner og en mengde applikasjoner. Hva er den optimale plasseringen av partisjonene på nodene? Litteraturen opererer med tre optimaliseringsmål: Minimale kostnader Minimale svartider Maksimal gjennomstrømning av transaksjoner Merk at samme partisjon kan havne på flere noder (replikering) INF5030 8. og 15.9.2005 Ragnar Normann 23

Pålitelighet (Reliability) Formelt er pålitelighet et statistisk mål for hvor sjelden et system (eller komponent) feiler: R(t) = Pr{0 feil i tidsrommet [0,t] feilfri ved t=0} Vi skal bruke begrepet «pålitelighet» om et systems evne til å overleve feil Litteraturen omtaler fire feilkategorier. Transaksjonsfeil (abort) Mediefeil (disk-kræsj) Nodefeil (maskinstopp) Kommunikasjonsfeil INF5030 8. og 15.9.2005 Ragnar Normann 24

Transaksjons- og mediefeil Vi deler transaksjonsfeil i to grupper: Transaksjonen aborterer av egen vilje Slike feil er irrelevante for et DDBMS Transaksjonen aborteres av DBMSet Dette må vi ta hensyn til i vår behandling av globale transaksjoner Det er ingen forskjell på håndtering av mediefeil i et sentralisert DBMS og i et DDBMS INF5030 8. og 15.9.2005 Ragnar Normann 25

Node- og kommunikasjonsfeil Nodefeil må/bør DDBMSet ta hensyn til i håndteringen av globale transaksjoner Kommunikasjonsfeil deles i to grupper: Transmisjonsfeil som gjør at meldinger ikke kommer frem Dette håndteres av nettverksprogrammene og er DDBMSet uvedkommende Linjefeil som partisjonerer nettet DDBMSet behandler disse som nodefeil INF5030 8. og 15.9.2005 Ragnar Normann 26

Distribuerte pålitelighetsprotokoller For å oppnå pålitelighet opererer et DDBMS med protokoller for å håndtere tre oppgaver: Commit Terminering Gjenoppretting Commit og gjenoppretting må håndteres annerledes enn i et sentralisert DBMS Terminering er bare relevant for DDBSer INF5030 8. og 15.9.2005 Ragnar Normann 27

(Klassisk) To-fase commit (2PC) Initiator og koordinator Slaver Koordinator Slaver Koordinator Klar til commit? Vil abortere/ Vil committe Global abort/ Global commit Fase 1 Fase 2 Abortert/ Committed INF5030 8. og 15.9.2005 Ragnar Normann 28

Lineær 2PC Fase 1 Klar? VA/VC VA/VC VA/VC Initiator Node2 Node3..... NodeN GA/GC GA/GC GA/GC GA/GC Fase 2 VA/VC = Vil abortere/vil committe GA/GC = Global abort/global commit INF5030 8. og 15.9.2005 Ragnar Normann 29

Distribuert 2PC Andre noder Alle noder Initiator Initiator Klar til commit? Vil abortere/committe Global abort/commit Fase 1 Fase 2 INF5030 8. og 15.9.2005 Ragnar Normann 30

Tilstandsdiagram for 2PC INITIAL INITIAL WAIT READY ABORT COMMIT ABORT COMMIT Koordinator Slave INF5030 8. og 15.9.2005 Ragnar Normann 31

2PC er en synkron protokoll En protokoll hvor alle kommuniserende noder enten er i samme tilstand eller i nabotilstander, kalles synkron 2PC er synkron fordi Koordinatoren er første node som går ut av INITIAL-tilstanden Koordinatoren blir i WAIT-tilstanden helt til alle andre noder har forlatt INITIAL-tilstanden INF5030 8. og 15.9.2005 Ragnar Normann 32

Termineringsprotokoller for 2PC Vi skal begrense oss til klassisk 2PC Problem: Hva gjør vi når en eller flere noder feiler? Vi må skille mellom feil (timeout) oppdaget av koordinatoren og feil oppdaget av slaver Koordinatoren kan oppdage feil i WAITtilstanden og i ABORT- eller COMMIT-tilstanden Slaver kan oppdage feil i INITIAL-tilstanden og i READY-tilstanden INF5030 8. og 15.9.2005 Ragnar Normann 33

Timeout hos koordinatoren Timeout i WAIT-tilstanden Minst en slave har ikke svart ennå Kan ikke gjøre global commit Kan velge å gjøre global abort Timeout i ABORT- eller COMMIT-tilstanden Vet ikke om abort/commit er utført i alle slaver Send purringer (global abort/commit) i fall forrige melding ikke kom frem INF5030 8. og 15.9.2005 Ragnar Normann 35

Timeout hos en slave I Timeout i INITIAL-tilstanden: Koordinatoren har feilet i sin INITIAL-tilstand, og transaksjonen aborteres Hvis det senere kommer en «Klar til commit?», har noden to muligheter Svare «Vil abortere» Ikke svare, og la koordinator få en timeout INF5030 8. og 15.9.2005 Ragnar Normann 36

Timeout hos en slave II Timeout i READY-tilstanden: Noden har sagt den vil committe, men kan ikke gjøre det uten mer informasjon Velg en ny koordinator Alternativt: Spør alle andre noder om deres tilstand (dette kan øke meldingsmengden) Hvis minst en node svarer ABORT eller COMMIT, vet noden hva den skal gjøre Hvis alle svarer READY, kan noden hverken abortere eller committe transaksjonen INF5030 8. og 15.9.2005 Ragnar Normann 37

Blokkering I det siste tilfellet på forrige lysark vil transaksjonen «henge igjen» i serialiseringsgrafen og blokkere for andre transaksjoner Vi sier at 2PC er en blokkerende protokoll Som det fremgår av det følgende teoremet, er det bevist at 2PC ikke kan endres til å bli ikke-blokkerende uten å innføre flere tilstander INF5030 8. og 15.9.2005 Ragnar Normann 38

Ikke-blokkerende protokoller En (lokal) tilstand kalles committbar hvis noder i denne tilstanden vet at alle andre noder vil committe Teorem (Skeen og Stonebraker): En synkron protokoll er ikke-blokkerende hvis, og bare hvis, følgende to betingelser er oppfylt: Ingen tilstand er «nabo» til både ABORT- og COMMIT-tilstanden Ingen ikke-committbar tilstand er «nabo» til COMMIT-tilstanden INF5030 8. og 15.9.2005 Ragnar Normann 39

Tre-fase commit (3PC) 2PC bryter begge kriteriene i forrige teorem Den minste endringen vi kan gjøre for å oppfylle kriteriene, er å legge inn en ny tilstand mellom WAIT/READY og COMMIT Den nye tilstanden kalles PRECOMMIT Vi får da tre tilstandsskifter på veien fra INITIAL til COMMIT En slik protokoll kalles tre-fase commit (3PC) INF5030 8. og 15.9.2005 Ragnar Normann 41

Tilstandsdiagram for 3PC INITIAL INITIAL WAIT READY ABORT PRE- COMMIT ABORT PRE- COMMIT Koordinator COMMIT Slave COMMIT INF5030 8. og 15.9.2005 Ragnar Normann 42

3PC Koordinator timeout Timeout i WAIT-tilstanden Som i 2PC: Send «Global abort» til alle Timeout i PRECOMMIT-tilstanden (alle må minst ha kommet til READY-tilstanden) Send «Forbered commit» til alle (det flytter dem til PRECOMMIT-tilstanden) Commit og send «Global commit» til alle Timeout i COMMIT- (ABORT-) tilstanden (alle er minst i PRECOMMIT- (READY-) tilstanden) Bruk termineringsprotokollen (om to lysark) INF5030 8. og 15.9.2005 Ragnar Normann 43

3PC Timeout i slaver Timeout i INITIAL-tilstanden Behandles som i 2PC Timeout i READY-tilstanden (Vil committe, men vet ikke hva koordinator vil) Velg en ny koordinator Følg termineringsprotokollen på neste lysark Timeout i PRECOMMIT-tilstanden (Meldingen «Forbered commit» er mottatt) Håndteres som forrige punkt INF5030 8. og 15.9.2005 Ragnar Normann 44

3PC Termineringsprotokollen Hvis den nye koordinatoren er i WAIT-tilstanden, gjør en global abort NB I dette ene tilfellet er det lov for noder i PRECOMMIT-tilstanden å abortere Hvis den nye koordinatoren er i PRECOMMITtilstanden, gjør en global commit Hvis den nye koordinatoren er i ABORTtilstanden, vil de andre nodene automatisk komme i ABORT-tilstanden de også INF5030 8. og 15.9.2005 Ragnar Normann 45

3PC varianter Avhengig av nettverkstopologien finnes det flere ikke-blokkerende 3PC-protokoller Distribuert 3PC er lett å få til Lineær 3PC lar seg også gjøre, men er ikke helt triviell å få til Det finnes også 3PC-varianter for å håndtere nettverkspartisjoner (behandles som om minst to noder er gått ned), men de er blokkerende INF5030 8. og 15.9.2005 Ragnar Normann 46