Begrepsforvirring i databaseverdenen?

Transkript

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

2 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 Ragnar Normann 2

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

4 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 Ragnar Normann 4

5 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 Ragnar Normann 5

6 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 % av Fortune-1000-firmaene bruker fortsatt IMS OMS-seminar Ragnar Normann 6

7 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 Ragnar Normann 7

8 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 Ragnar Normann 8

9 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 Ragnar Normann 9

10 Objektdatabaser vs objektlagre Tidligere ( ) 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 Ragnar Normann 10

11 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 Ragnar Normann 11

12 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 Ragnar Normann 12

13 Databasearkitektur Skjemaer og datauavhengighet OMS-seminar Ragnar Normann 13

14 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 Ragnar Normann 14

15 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 Ragnar Normann 15

16 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 Ragnar Normann 16

17 3-skjemaarkitekturen OMS-seminar Ragnar Normann 17

18 Distribuerte databaser OMS-seminar Ragnar Normann 18

19 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 Ragnar Normann 19

20 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 Ragnar Normann 20

21 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 Ragnar Normann 21

22 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 Ragnar Normann 22

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

24 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 Ragnar Normann 24

25 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 Ragnar Normann 25

26 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 Ragnar Normann 26

27 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 Ragnar Normann 27

28 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 Ragnar Normann 28

29 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 Ragnar Normann 29

30 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 Ragnar Normann 30

31 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 Ragnar Normann 31

32 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 Ragnar Normann 32

33 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 Ragnar Normann 33

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

35 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 Ragnar Normann 35

36 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 Ragnar Normann 36

37 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 Ragnar Normann 37

38 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 Ragnar Normann 38

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

40 Lineær 2PC Fase 1 Klar? VA/VC VA/VC VA/VC Initiator Node2 Node 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 Ragnar Normann 40

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

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

43 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 Ragnar Normann 43

44 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 Ragnar Normann 44

45 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 Ragnar Normann 45

46 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 Ragnar Normann 46

47 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 Ragnar Normann 47

48 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 Ragnar Normann 48

49 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 Ragnar Normann 49

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

51 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 Ragnar Normann 51

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

53 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 Ragnar Normann 53

54 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 Ragnar Normann 54

55 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 Ragnar Normann 55

56 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 Ragnar Normann 56