Begrepsforvirring i databaseverdenen?

UNIVERSITETET I OSLO Begrepsforvirring i databaseverdenen? Om arkitektur og taksonomi for databasesystemer OMS-seminar 2.11.2005 Ragnar Normann 1

Disposisjon DBMS-arkitekturer Hvilke typer databasehåndteringssystemer har vi? DB-arkitekturer 2- og 3-skjemaarkitektur for (sentraliserte) databaser DDB-arkitekturer Hvordan klassifiserer vi de utallige variantene av distribuerte databaser? Klassifisering og håndtering av pålitelighet OMS-seminar 2.11.2005 Ragnar Normann 2

DBMS-arkitekturer En ufullstendig oversikt OMS-seminar 2.11.2005 Ragnar Normann 3

Begynnelsen Bachman & Williams: A General Purpose Programming System for Random Access Memories [1964] beskrev IDS IDS (Integrated Data Store fra General Electric) var det første kommersielle DBMS Dette var første gang to programmer kunne ha aksess til de samme dataene samtidig (kvasiparallell aksess) IDS ble videreutviklet og solgt til John Cullinane som markedsførte produktet under navnet IDMS (firmanavnet skiftet fra Cullinane til Cullinet) OMS-seminar 2.11.2005 Ragnar Normann 4

Nettverksdatabaser IDS var en nettverksdatabase, dvs at skjemaet besto av to typer datastrukturer: Posttyper (COBOL record type) Sett-typer (1:n relasjon mellom to posttyper kalt hhv eier- og medlemstype) Hver enkelt post kunne delta i vilkårlig mange sett, som eier i noen og medlem i andre, men bare en gang i hver sett-type Nettverksdatabaser ble standardisert av CODASYL i 1972 med en revisjon i 1978 OMS-seminar 2.11.2005 Ragnar Normann 5

Hierarkiske databaser Et hierarkisk databaseskjema har to datastrukturer: Posttyper 1:n relasjoner, kalt foreldre barn-relasjoner, mellom to posttyper Foreldre barn-relasjonene danner et hierarki (tre) Rotposter er ikke barn i noen foreldre barn-relasjon Andre poster er barn i eksakt én foreldre barn-relasjon I realiteten finnes bare ett kommersielt hierarkisk DBMS, IMS, som ble utviklet av IBM og Rockwell International (North American Aviation) og lansert av IBM i 1968 95% av Fortune-1000-firmaene bruker fortsatt IMS OMS-seminar 2.11.2005 Ragnar Normann 6

Relasjonsdatabaser Relasjonsdatabaser har én type datastruktur, relasjoner (tabeller), som tilsvarer posttyper Kolonnene har navn og kalles attributter Linjene er navnløse og kalles tupler (forekomster) Tuplenes attributtverdier er atomiske COBOLs repeterende grupper er ikke tillatt Alle logiske sammenhenger mellom relasjoner er basert på verdilikhet (fremmednøkler, join) SQL er ISO-standard for definisjon og bruk av relasjonsdatabaser OMS-seminar 2.11.2005 Ragnar Normann 7

Objektrelasjonelle databaser SQL:1999 tillater lob-attributter (lob=large object) Det er tre typer lob-er: Blob (Binary), bilder, lyd, video Clob (Character), fri tekst Row type (Attributter med indre struktur) Lob-er kan ikke indekseres og kan ikke inngå i nøkler eller fremmednøkler For databasen er en lob en atomisk verdi, så all indre struktur må håndteres av applikasjonen Objektrelasjonelle databaser er en generalisering (videreutvikling) av relasjonsdatabaser OMS-seminar 2.11.2005 Ragnar Normann 8

Objektdatabaser Dataelementene er objekter Objektene kan stå i relasjon (relationship) til hverandre; slike relasjoner er alltid toveis Applikasjonsgenererte objekter er i utgangspunktet transiente De kan gjøres persistente enten ved eksplisitt lagring eller ved å settes i relasjon med et persistent objekt Gjeldende standard er ODMG 3.0, men ingen har til nå laget en full implementasjon av denne Implementasjonsmessig er objektdatabaser en generalisering av nettverksdatabaser, mens spørrespråket OQL er en beregningskomplett SQL-etterligning (OQL returnerer et objekt; SQL returnerer en relasjon) OMS-seminar 2.11.2005 Ragnar Normann 9

Objektdatabaser vs objektlagre Tidligere (1980-90) var persistente objektorienterte programmeringsspråk et hett forskningstema Fra dette miljøet ble det foreslått en databasearkitektur som vi i dag kaller objektlagre Her ble objektenes tilstand lagret, og ved lesing ble objektet bygget opp i applikasjonens adresserom I en (ekte) objektdatabase er objektene aktive det vil si at applikasjonene kommuniserer med objektene i databasen med meldinger, og at objektenes metoder (i det minste logisk) utføres i databasens adresserom OMS-seminar 2.11.2005 Ragnar Normann 10

Semistrukturerte databaser Semistrukturerte data er skjemaløse og selvbeskrivende data Desidert største bruk er XML-dokumenter tilgjengelig på internett (eller intranett) XML 1.0 (Extensible Markup Language) er en W3C-standard fra 1998 I XML definerer «tag»-er semantikken (i HTML definerer de formatering) Strengt tatt er det bare skjemafri («standalone») XML som er semistrukturert OMS-seminar 2.11.2005 Ragnar Normann 11

XML-skjemaer XML-dokumenter kan ha et skjema (angis med «standalone = no») Et slikt skjema kalles en DTD (Document Type Definition) En DTD beskriver hva som er en lovlig nøsting av «tag»-er Det legges for tiden ned et betydelig arbeid for å få definert DTD-er som kan fungere som internasjonale bransjestandarder for informasjonsutveksling OMS-seminar 2.11.2005 Ragnar Normann 12

Databasearkitektur Skjemaer og datauavhengighet OMS-seminar 2.11.2005 Ragnar Normann 13

2-skjemaarkitektur IDS var en 2-skjemaarkitektur database Ettskjema ga en fullstendig beskrivelse av databasen Ettsubskjema tilpasset applikasjonen fungerte som applikasjonens vindu mot databasen Hver database hadde bare ett skjema, men kunne ha vilkårlig mange subskjemaer OMS-seminar 2.11.2005 Ragnar Normann 14

Datauavhengighet 2-skjemaarkitekturen tilbød datauavhengighet: Skjemaet definerte både struktur og lagringsformat for dataene Subskjemaet definerte navn og format på de dataene applikasjonen brukte Det ble dermed mulig å forandre lagringsformatet uten å forandre programmene OMS-seminar 2.11.2005 Ragnar Normann 15

Litt mer databasehistorie 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 OMS-seminar 2.11.2005 Ragnar Normann 16

3-skjemaarkitekturen OMS-seminar 2.11.2005 Ragnar Normann 17

Distribuerte databaser OMS-seminar 2.11.2005 Ragnar Normann 18

Litteratur Den følgende fremstilling er basert på boken M. Tamer Özsu & Patrick Valduriez: Principles of Distributed Database Systems Second Edition Prentice Hall 1999 OMS-seminar 2.11.2005 Ragnar Normann 19

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 OMS-seminar 2.11.2005 Ragnar Normann 20

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 OMS-seminar 2.11.2005 Ragnar Normann 21

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 OMS-seminar 2.11.2005 Ragnar Normann 22

Problemer og forskningsområder OMS-seminar 2.11.2005 Ragnar Normann 23

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 OMS-seminar 2.11.2005 Ragnar Normann 24

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 denne er den mest brukte i faglitteraturen OMS-seminar 2.11.2005 Ragnar Normann 25

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. OMS-seminar 2.11.2005 Ragnar Normann 26

Distribusjon Denne dimensjonen klassifiserer graden av fysisk distribusjon av dataene (Distribusjontransparens er en forutsetning, 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)) OMS-seminar 2.11.2005 Ragnar Normann 27

Heterogenitet Heterogenitet kommer i mange varianter (som hardware, nettverk, spørrespråk, transaksjonsprotokoller, datamodeller og DBMSer) Det er vanlig å forenkle til to klasser: H0: Homogene systemer Systemene har samme DBMS (og som oftest samme OS og hardware) H1: Heterogene systemer (alt annet enn H0) OMS-seminar 2.11.2005 Ragnar Normann 28

Arkitekturrommet Vi har definert 18 mulige arkitekturer, men ikke alle er like relevante Homogene systemer på samme node er forholdsvis sjeldne (A2,D0,H0) forekommer oftere, men er heller ikke særlig vanlig (A1,D0,H0) er (var i hvert fall tidligere) vanlig Eksempel: UiOs gamle lønns- og personalsystem gikk på samme maskin og DBMS som økonomisystemet med felles kontoplan, artskoder og kostnadsstedregister OMS-seminar 2.11.2005 Ragnar Normann 29

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 OMS-seminar 2.11.2005 Ragnar Normann 30

Semijoin (en nødvendig digresjon) La R og S være to relasjoner. Kall Rs skjemaa 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. Formel: R θ S = π A R θ S ( )= R θ π A B S ( ) OMS-seminar 2.11.2005 Ragnar Normann 31

Fragmentering 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 (fragmenter som ligger på ulike noder). Da vil en fragmentering R k = R S k kunne effektivisere en join av R med S betydelig. OMS-seminar 2.11.2005 Ragnar Normann 32

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) OMS-seminar 2.11.2005 Ragnar Normann 33

UNIVERSITETET I OSLO Pålitelighet i distribuerte databasesystemer OMS-seminar 2.11.2005 Ragnar Normann 34

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} Databaseverdenen bruker begrepet «pålitelighet» om et systems evne til å overleve feil Litteraturen omtaler fire feilkategorier: Transaksjonsfeil (abort) Mediefeil (disk-kræsj) Nodefeil (maskinstopp) Kommunikasjonsfeil OMS-seminar 2.11.2005 Ragnar Normann 35

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 OMS-seminar 2.11.2005 Ragnar Normann 36

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 OMS-seminar 2.11.2005 Ragnar Normann 37

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 OMS-seminar 2.11.2005 Ragnar Normann 38

(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 OMS-seminar 2.11.2005 Ragnar Normann 39

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 OMS-seminar 2.11.2005 Ragnar Normann 40

Distribuert 2PC Andre noder Alle noder Initiator Initiator Klar til commit? Vil abortere/committe Global abort/commit Fase 1 Fase 2 OMS-seminar 2.11.2005 Ragnar Normann 41

Tilstandsdiagram for 2PC INITIAL INITIAL WAIT READY ABORT COMMIT ABORT COMMIT Koordinator Slave OMS-seminar 2.11.2005 Ragnar Normann 42

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 OMS-seminar 2.11.2005 Ragnar Normann 43

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 OMS-seminar 2.11.2005 Ragnar Normann 44

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 OMS-seminar 2.11.2005 Ragnar Normann 45

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 OMS-seminar 2.11.2005 Ragnar Normann 46

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 OMS-seminar 2.11.2005 Ragnar Normann 47

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 OMS-seminar 2.11.2005 Ragnar Normann 48

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 OMS-seminar 2.11.2005 Ragnar Normann 49

Tilstandsdiagram for 2PC INITIAL INITIAL WAIT READY ABORT COMMIT ABORT COMMIT Koordinator Slave OMS-seminar 2.11.2005 Ragnar Normann 50

Tre-fase commit (3PC) 2PC bryter begge kriteriene i Skeens 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) OMS-seminar 2.11.2005 Ragnar Normann 51

Tilstandsdiagram for 3PC INITIAL INITIAL WAIT READY ABORT PRE- COMMIT ABORT PRE- COMMIT Koordinator COMMIT Slave COMMIT OMS-seminar 2.11.2005 Ragnar Normann 52

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) OMS-seminar 2.11.2005 Ragnar Normann 53

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 OMS-seminar 2.11.2005 Ragnar Normann 54

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å OMS-seminar 2.11.2005 Ragnar Normann 55

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 alle blokkerende OMS-seminar 2.11.2005 Ragnar Normann 56