Parallelle og distribuerte databaser del II

Transkript

1 UNIVERSITETET I OSLO Parallelle og distribuerte databaser del II CAP-teoremet (kursorisk) Databaser i mobile ad-hoc-nettverk (kursorisk) Paxos algoritmer for å oppnå konsensus i distribuerte systemer (ikke pensum i 2014) Datamodeller i NoSQL (ikke pensum i 2014) Institutt for Informatikk INF Ellen Munthe-Kaas 1

2 CAP-teoremet CAP-teoremet: I et distribuert system er det ikke alltid mulig å tilby samtlige av følgende tre garantier: Consistency en forespørsel vil på et gitt tidspunkt gi samme svar/respons uansett hvilken node den eksekveres på Availability hver forespørsel resulterer i en respons Partition tolerance systemet fortsetter å være virksomt selv om meldinger kan gå tapt (deler av nettverket feiler) eller deler av nodene feiler/går ned INF Ellen Munthe-Kaas 2

3 CAP-teoremet utdypet I Med consistency menes det som dekkes av A+C i ACID, dvs. at en enkelt forespørsel+respons skal utføres atomært og bevare konsistens. Med availability menes at enhver forespørsel til en ikkefeilet node skal resultere i en respons. (Den opprinnelige formuleringen av CAP-teoremet sier at «så godt som alle» forespørsler skal motta en respons, for i praksis kan man ikke garantere 100% tilgjengelighet.) INF Ellen Munthe-Kaas 3

4 CAP-teoremet utdypet II CAP-teoremet ble opprinnelig formulert med tanke på web service-systemer, men ideene er gyldige uansett hvilket formål det distribuerte systemet har En populær, men overforenklet fremstilling av CAPteoremet sier at man i ethvert distribuert system må velge «to av tre», dvs. CA, CP eller AP. Men CA er ikke egentlig en opsjon i et tjenesteytende distribuert system man må designe ethvert slikt system med tanke på at nettverket kan feile. INF Ellen Munthe-Kaas 4

5 CAP-teoremet utdypet III Når en nettverkspartisjon oppstår, må man velge mellom konsistens og tilgjengelighet, man kan ikke tilby begge. CP: Hvis man velger konsistens fremfor tilgjengelighet, kan operative noder måtte avslå å yte tjenester (dvs. forespørsler må kanskje besvares med «prøv igjen senere» eller liknende) AP: Hvis man velger tilgjengelighet fremfor konsistens, kan det være at når nettverket igjen virker som det skal, er det inkonsistenser i systemet der systemet ikke selv kan rydde opp i/bli kvitt alle inkonsistensene INF Ellen Munthe-Kaas 5

6 Eksempel: Bestilling av hotellrom To personer ønsker å bestille samme rom i samme hotell for samme tidsrom. Bestillingssystemet er distribuert over to noder med replikater på begge. Nettverket mellom nodene er nede. Alternativer: CP: Ingen rom kan bestilles (hver av forespørslene besvares med «ikke tilgjengelig/prøv senere» selv om hver av nodene er fullt operativ). AP: Begge bestillingene går igjennom (inkonsistens/overbooking). Inkonsistensen rettes når personene ankommer hotellet (ved at hotellet har et ekstra rom som er avsatt til å håndtere overbooking). INF Ellen Munthe-Kaas 6

7 CAP-teoremet i praksis I praksis er det ikke et enten-eller, men en glidende overgang/tradeoff mellom de to altermativene. Man kan f.eks. velge forskjellig tilnærming (CP/AP) for forskjellige funksjoner/operasjoner I praksis er det dessuten en tradeoff mellom konsistens og responstid. Jo mer konsistens man krever, desto flere noder må involveres i arbeidet med å gjennomføre dette, og jo lenger tid tar det å respondere på en forespørsel Denne formen for tradeoff gjelder selv om det ikke er noen nettverkspartisjoner INF Ellen Munthe-Kaas 7

8 Mobile ad-hoc-nettverk Mobile ad-hoc-nettverk (MANETs) er (lokale) trådløse nettverk som settes opp mellom noder som kommer i kommunikasjonsavstand til hverandre MANETs er karakterisert ved hyppige endringer i den underliggende topologien noder forflytter seg naboskap endres nettverk partisjoneres og smelter sammen kommunikasjon skjer via radiobåndet stor feilrate (kollisjoner av meldinger i eteren) lav båndbredde hver nettverkspartisjon består av i høyden noder mer enn dette er ikke praktisk håndterbart (pga. feilraten) INF Ellen Munthe-Kaas 8

9 Databaser i mobile ad-hoc-nettverk Krav til databasesystemet er omtrent som for P2P-nettverk. I tillegg er det ytterligere utfordringer knyttet til begrensninger i nettverkskapasitet og hyppige endringer i nettverkstopologien: Distribuert: Data er fordelt mellom nodene. Optimalt antall og opimal plassering av replikater avhenger av nettverkstopologien. Desentralisert: Nodene må kollektivt ivareta det administrative ansvaret for databasen. Ved nettverkspartisjoner må databasen overleve i hver av partisjonene. Ved sammensmelting av nettverk må databasepartisjonene samordnes. Feiltolerant: Systemet må være pålitelig selv om noder feiler, naboskap endres, nettverket partisjoneres eller nettverk smelter sammen. Skalerbart: Størrelsen på hver nettverkspartisjon er begrenset, derfor er ikke dette kravet like fremtredende som i P2P-nettverk. Konsistent: Kan ikke holde replikater konsistente på tvers av nettverkspartisjoner. Må gjøre avveiinger mellom CP og AP i CAP-teoremet INF Ellen Munthe-Kaas 9

10 Eksempel: MIDAS Dataspace EU-prosjekt med åtte internasjonale partnere. Fra Ifi: Forskningsgruppen DMMS (Distribuerte multimediasystemer) Formål: Mellomvare som støtter utvikling av applikasjoner for MANETs Applikasjonsscenarier: Redningsaksjoner og store sportsarrangementer Prototyp som ble testet ut i emuleringsomgivelse og på små håndholdte enheter (PDAer) Proof-of-concept-applikasjoner: Det 32. internasjonale sykkelcrossløpet i Gieten, Nederland, 2007 De Nijmegen Vierdaagse, 2008 (firedagers turmarsj i Nijmegen, Nederland) INF Ellen Munthe-Kaas 10

11 Datahåndtering i MIDAS I Dataelementer er replikert på tvers av noder for at noder skal beholde sin funksjonalitet ved nettverkspartisjoner systemet prioriterer tilgjengelighet (AP) fremfor konsistens (CP): noder kan fortsette å jobbe på sin lokale kopi Replikater må likevel så langt som mulig holdes konsistente (de skal representere samme logiske enhet) Antall replikater må balanseres mot økt nettverkstrafikk oppdateringer av et dataelement krever meldingsutveksling mellom alle replikatene INF Ellen Munthe-Kaas 11

12 Datahåndtering i MIDAS II Konsistens på tvers av nettverkspartisjoner kan ikke garanteres noder i forskjellige nettverkspartisjoner kan ikke kommunisere replikater i forskjellige nettverkspartisjoner kan derfor utvikle seg ulikt Når to partisjoner smelter sammen, må konsistens gjenopprettes Løsning: Versjonering ingen sletting eller endring av gamle data to replikater samordnes ved å utveksle alle versjoner av dataelementet applikasjoner må selv velge hvordan semantiske konflikter skal løses (hvilken versjon av et dataelement som er den rette når dette f.eks. ikke kan avledes fra tidsstempler på versjonene) selv med versjonering (ingen data slettes) forblir datamengden overkommelig i de gitte applikasjonsscenariene INF Ellen Munthe-Kaas 12

13 Oppslagstjenester i MIDAS Hver node vedlikeholder en oversikt (metadata) over hvilke replikater som befinner seg på hvilke noder Når nye replikater opprettes, propageres metadata om dette til alle noder i nettverkspartisjonen Radiobølger betyr at meldinger kringkastes (alle i lytteavstand lytter på alle meldinger som sendes). Dette utnyttes i valg av algoritmer for metadatapropagering Størrelsen på total mengde metadata forblir liten i applikasjonsscenariene Når to partisjoner smelter sammen, utveksles metadata En node vil ikke nødvendigvis ha en perfekt global oversikt fordi det tar tid før endringer i metadata er propagert til alle Propagering av metadata i en nettverkspartisjon krever flere meldinger når ikke alle noder er i direkte kommunikasjonsavstand til hverandre (multihop) INF Ellen Munthe-Kaas 13

14 Paxos Utgangspunkt: Et distribuert system av N samarbeidende noder som trenger å oppnå konsensus/komme frem til en felles beslutning. Noder kan feile og meldinger bli borte Samme melding kan bli levert flere ganger En melding kan bruke vilkårlig lang tid på å bli levert Paxos-algoritmen består av en eller flere avstemningsrunder der målet er at nodene skal vedta ett felles dekret. (Dekretet representerer eller beskriver den felles beslutningen.) Hvis en majoritet av nodene blir enige om et dekret, blir det vedtatt. INF Ellen Munthe-Kaas 14

15 Paxos-algoritmen I hver avstemningsrunde foreligger ett forslag til dekret. Dekretet kan variere fra runde til runde. Bare ett av dekretene som fremmes, kan/vil bli vedtatt. I hver runde kan en node enten stemme for dekretet eller la være å stemme. I utgangspunktet er alle noder positivt innstilt til alle forslag til dekreter. Hvis en node ikke besvarer en melding, er det fordi ett av følgende har skjedd: meldingen eller svaret gikk tapt noden gikk ned før den fikk meldingen eller før den fikk svart på meldingen noden velger å ikke besvare meldingen INF Ellen Munthe-Kaas 15

16 Avstemningsrundene Hver avstemningsrunde tilordnes et nummer (b,p) der b er et tall og p en node. Rundenumrene ordnes leksikografisk: (b,p) b p q. Flere runder kan pågå samtidig hvis flere noder velger å påbegynne nye runder omtrent samtidig og/eller en node velger å påbegynne en ny runde, typisk fordi den ikke fikk inn nok svar i foregående runde. Rundenummeret reflekterer ikke nødvendigvis i hvilken rekkefølge rundene faktisk gjennomføres, men en og samme node tildeler sine runder stigende nummere. INF Ellen Munthe-Kaas 16

17 Fasene i en avstemningsrunde A. Forberedelsesfasen: En node ønsker å initiere en ny avstemningsrunde. Noden innhenter informasjon fra et tilstrekkelig stort antall noder om i hvilken runde de sist stemte, og hvilket dekret som da var oppe til avstemning. B. Stemmefasen: Noden initierer en ny avstemningsrunde der dekretet det skal stemmes over og hvilke noder som skal være med i avstemningen (et kvorum Q), delvis blir bestemt utifra de svarene som ble innhentet i fase A. C. Vedtaksfasen: Hvis alle i kvorumet stemte, er dekretet vedtatt og noden sender dekretet til samtlige noder i N. INF Ellen Munthe-Kaas 17

18 Variable og initialverdier lasttried p = b (b,p) er rundenummeret til siste runde initiert av node p. Initielt: - prevvote p = (b,q,d) (b,q) er høyeste rundenummer blant de rundene der node p har stemt. d er dekretet som var oppe til avstemning i runden. Initielt: (-, nil, BLANK) nextballot p = (b,q) (b,q) er høyeste rundenummer blant de rundene der node p har sagt seg villig til å delta. Initielt: (-, nil) outcome p = d d er det vedtatte dekretet. Initielt: BLANK INF Ellen Munthe-Kaas 18

19 Fase A forberedelsesfasen 1. Node p velger en ny b lasttried p. lasttried p := b. Send meldingen NextBallot(b,p) til en mengde noder M der M N. 2. Node q mottar en NextBallot(b,p)-melding: Hvis (b,p) nextballot q : nextballot q := (b,p). Send meldingen LastVote(b,p,prevVote q ) til p. Hvis (b,p) nextballot q : Ignorer meldingen. INF Ellen Munthe-Kaas 19

20 Fase B - stemmefasen 3. Node p har mottatt en LastVote(b,p,v)-melding fra alle noder i en mengde Q M der Q utgjør en majoritet av nodene og b = lasttried p : Velg dekret d (se algoritme neste side). Send meldingen BeginBallot(b,p,d) til hver av nodene i Q. 4. Node q mottar en BeginBallot(b,p,d)-melding: Hvis (b,p) = nextballot q : prevvote q := (b,p,d) Send meldingen Voted(b,p,q) til p. Ellers: Ignorer meldingen. INF Ellen Munthe-Kaas 20

21 Fase B valg av dekret Hvis samtlige LastVote(b,p,v) har v = (-, nil, BLANK), kan dekretet i avstemningsrunde (b,p) velges fritt. Hvis det finnes minst én b - (da er q nil og BLANK), så finn den med størst Dette, sammen med at kvorumet i hver runde må omfatte en majoritet av nodene, sikrer at avstemningsrundene vil konvergere mot et felles dekret. INF Ellen Munthe-Kaas 21

22 Fase C - vedtaksfasen 5. Node p har mottatt en Voted(b,p,q)-melding fra hver av nodene i Q, der b = lasttried p : outcome p := d Send meldingen Success(d) til hver av nodene i N. 6. Node q mottar en Success(d)-melding: outcome q := d INF Ellen Munthe-Kaas 22

23 Konsistens og vranglås Algoritmen sikrer konsistens, dvs. alle noder der outcome p = d BLANK, har samme verdi d. Algoritmen hindrer vranglås (deadlock): Til ethvert tidspunkt er det alltid mulig å gjennomføre en runde som leder til et vedtak, såsant tilstrekkelig mange meldinger kommer frem og besvares i hver fase. INF Ellen Munthe-Kaas 23

24 Fremdrift I utgangspunktet kan en node fritt velge å la være å besvare meldinger. Dette påvirker ikke konsistensen, men kan hindre at nodene oppnår konsensus/kommer frem til en beslutning. For å sikre at algoritmen har fremdrift, må alle noder forplikte seg til å gjennomføre stegene 2-6 så raskt de kan (besvare meldinger så lojalt som mulig). I tillegg må, så lenge det ikke er vedtatt noe dekret, nye runder (steg 1) initieres fra tid til annen. Dessuten må ikke nye runder initieres for ofte: Hvis det stadig initieres nye runder, risikerer man at ingen av rundene lykkes (livelock). Det er enklest å møte utfordringene i de to foregående punktene hvis en av nodene velges til president og bare presidenten får initiere avstemningsrunder. Da må man i tillegg ha en protokoll for valg av ny president hvis presidentnoden går ned. INF Ellen Munthe-Kaas 24

25 NoSQL NoSQL er et paraplybegrep som omfatter en rekke ulike typer DBMSer. Typiske egenskaper ved NoSQL-databaser: Datamodell avviker fra relasjonsmodellen Intet fast (eksplisitt) skjema enklere å videreutvikle databasen Enorme mengder data store maskinclustere Open-source INF Ellen Munthe-Kaas 25

26 Datamodeller under NoSQL Grafmodellen: Data er strukturert i form av entiteter (noder) og kanter som reflekterer hvordan entitetene forholder seg til hverandre. Søk: Angi hvordan grafen skal navigeres. Aggregatorienterte modeller: Et aggregat er i denne forbindelsen en samling av data som utgjør en naturlig enhet, dvs. spørringer og transaksjoner er typisk begrenset til ett og ett aggregat og involverer sjeldnere samlinger av aggregater. Hvert aggregat lagres som en enhet. Transaksjoner mot aggregater har typisk ACIDegenskapene INF Ellen Munthe-Kaas 26

27 Aggregatorienterte modeller Key-value store: Data er på formen (k,v) der k er en nøkkel og v en verdi. Søk: Oppgi k, finn tilhørende v. Document database: Data består av nestede strukturer av navn-verdi-par. Hvert «dokument» inneholder én slik kompleks datastruktur. Søk: Finn verdi for et gitt navn med angivelse av hvor i strukturen navn-verdiparet befinner seg. Column family database: Data er strukturert etter samhørende kolonner. Kolonnefamilier knyttes sammen med en radnøkkel. Søk: Angi radnøkkel og kolonnefamilienavn. INF Ellen Munthe-Kaas 27

28 Introduksjon til NoSQL Se følgende introduksjon til NoSQL av Martin Fowler (GOTO Aarhus Conference 2012): (Varighet: 55 min.) Temaer: Historikken bak NoSQL Datamodeller i NoSQL Distribusjonsmodeller (sharding, replikering) ACID vs. BASE CAP-teoremet Når og hvorfor bruke NoSQL INF Ellen Munthe-Kaas 28