04-11-2007/FENNOEA/IT - Databaser/DDB1 Lektion 13 Distribuerede databaser Begreber Design: fragmentering, allokering Arkitekturer Query Processing Transaktionshåndtering.

Præsentationer af emnet: "04-11-2007/FENNOEA/IT - Databaser/DDB1 Lektion 13 Distribuerede databaser Begreber Design: fragmentering, allokering Arkitekturer Query Processing Transaktionshåndtering."— Præsentationens transcript:

1 04-11-2007/FENNOEA/IT - Databaser/DDB1 Lektion 13 Distribuerede databaser Begreber Design: fragmentering, allokering Arkitekturer Query Processing Transaktionshåndtering

2 04-11-2007/FENNOEA/IT - Databaser/DDB2 Begreber En distribueret databaser er en samling af logisk forbundne databaser, som er fysisk fordelt ud over et netværk (og hver site deltager i mindst én global transaktion). Et distribueret DBMS er et software- system, som håndterer en distribueret database, så distributionen er transparent for brugeren

3 04-11-2007/FENNOEA/IT - Databaser/DDB3 Parallel versus Distribueret teknologi Shared memory (tæt koblet arkitektur): –Flere processorer deler både internt og ekstern lager Shared disk (løst koblet): –Flere processorer har egen RAM, men deler disk Shared nothing: –Separate processorer med egen disk og RAM forbundet via en bus eller lign. Er det ikke distribuere t?

4 04-11-2007/FENNOEA/IT - Databaser/DDB4 Parallel DBMS a) shared memory b) shared disk c) shared nothing

5 04-11-2007/FENNOEA/IT - Databaser/DDB5 Centraliseret DBMS med netværksadgang (klassisk Client/Server)

6 04-11-2007/FENNOEA/IT - Databaser/DDB6 Distribueret DBMS

7 04-11-2007/FENNOEA/IT - Databaser/DDB7 Fordele ved distribueret DBMS Forskellige niveauer af transparens Højere grad af pålidelighed (reliability) og tilgængelighed (availability) Bedre performance Bedre scalerbarhed

8 04-11-2007/FENNOEA/IT - Databaser/DDB8 Transparens Distributions- eller netværkstransparens: –Location transparens –Naming transparens Replikeringstransparens Fragmenteringstransparens: –Horisontal fragmentering –Veritikal fragmentering

9 04-11-2007/FENNOEA/IT - Databaser/DDB9 Company-databasen

10 04-11-2007/FENNOEA/IT - Databaser/DDB10 Fragmentering og replikering Replikering og horisontal fragmentering

11 04-11-2007/FENNOEA/IT - Databaser/DDB11 Krav til distribueret DBMS Udvidet katalog, så fragmenterings-, allokerings- og replikeringsinformation håndteres Distribueret query-afvikling Distribueret transaktionshåndtering Konsistens ved replikering Distribueret recovery Security Distribueret katalog

12 04-11-2007/FENNOEA/IT - Databaser/DDB12 Disadvantages of DDBMSs (fra Connolly& Begg: Database Systems 3 rd Ed. Addison-Wesley) Complexity Cost Security Integrity control more difficult Lack of standards Lack of experience Database design more complex

13 04-11-2007/FENNOEA/IT - Databaser/DDB13 Distribueret databasedesign Først designes det globale skema som vanligt Herefter designes fragmenterings- og allokeringsskemaerene Fragmentering: –Relationer (tabeller) brydes op i subrelationer: Horisontalt Vertikalt Mixed (hybrid) fragmentering

14 04-11-2007/FENNOEA/IT - Databaser/DDB14 Horisontal fragmentering En tabel opdeles ved rækkeudvælges: –Ex. Employee efter Dno. Afledt horisontal fragmentering: –Ex. Project fragmenterings også efter Dno Komplet fragmentering: –Foreningsmængden af alle fragmenter er lig den oprindelige tabel Disjunkt fragmentering: –Ingen fragmenter har fælles tupler (fællesmængden er parvis tom – ingen redundans)

15 04-11-2007/FENNOEA/IT - Databaser/DDB15 Vertikal fragmentering Tabellen opdeles ved projektion (søjleudvælgelse): –Ex: Employee: personoplysninger i eet fragment og arbejdsrelaterede i et andet Af hensyn til rekonstruktion ved join er det vigtigt, at primærnøglen (evt. en kandidatnøgle) findes i begge fragmenter En komplet vertikal fragmentering opfylder: –Alle attributter findes i foreningsmængden af fragmenterne –Eneste fællesattribut mellem fragmenterne er primærnøglen –Den oprindelige relation kan genskabes ved OUTER JOIN

16 04-11-2007/FENNOEA/IT - Databaser/DDB16 Hybrid fragmentering En kombination af horisontal og vertikal fragmentering. Opnås gennem en kombination af række- og søjleudvælgelser Rekonstruktion via UNION og OUTER JOIN skal være muligt

17 04-11-2007/FENNOEA/IT - Databaser/DDB17 Replikering og allokering Ekstremerne: –Fuld replikering: alt ligger på alle sites: Maksimal tilgængelighed God performance på forespørgsler – elendig på opdateringer + kompleksitet ved transaktionshåndtering –Ingen replikering/ikke-redundant (disjunkt allokering): Lige omvendt Alle grader af partiel replikering her i mellem er mulige

18 04-11-2007/FENNOEA/IT - Databaser/DDB18 Eksempel – Company-databasen Tre sites: –Hovedkontor (site 1): Tilgår Employee og Project for hele virksomheden, styrer Dependent –Afdeling 5 (site 2): Tilgår hyppigt medarbejdere i afdelingen og projekter, som kontrolleres af afdelingen –Afdeling 4 (site 3): Som afdeling 5, men for sine ansatte og projekter

19 04-11-2007/FENNOEA/IT - Databaser/DDB19 Allokering Site 1: –hele databasen Site 2 og 3: –Horisontal fragmentering af Department på Dno –Afledt fragmentering af Employee, Project og ProjectLocations –Fragmenterne EMPD4 og EMPD5 fragmenteres vertikalt, så kun attributterne {Name, SSN, Salery, SuperSSN, Dno} medtages

20 04-11-2007/FENNOEA/IT - Databaser/DDB20 Works_On {Pno, ESSN, hours} Kan fragmenteres efter: –Den afdeling, som den ansatte tilhører –Den afdeling, der kontrollerer projektet

21 04-11-2007/FENNOEA/IT - Databaser/DDB21 Efter den afdeling, som den ansatte tilhører

22 04-11-2007/FENNOEA/IT - Databaser/DDB22 Der er intet enkelt svar på hvilken strategi, der skal vælges. I dette tilfælde vælger vi at fragmentere og allokere, så alle JOIN ind over Works_On kan udføres lokalt, dette føre til replikering af dele af tabellen

23 04-11-2007/FENNOEA/IT - Databaser/DDB23 G1, G2, G3, G4 og G7

24 04-11-2007/FENNOEA/IT - Databaser/DDB24 G2, G4, G5, G6 og G8

25 04-11-2007/FENNOEA/IT - Databaser/DDB25 Arkitekturer Homogene: –Samme DBMS på hver site og hver klient Heterogene Lokal autonomi Ingen lokal autonomi

26 04-11-2007/FENNOEA/IT - Databaser/DDB26 Ekstremerne Fuldstændigt transparent DDBMS (Date’s 12 regler) Federalt DBMS eller Multidatabasesystem: –Hver site er en fuldstændig autonom DBMS –Der er en eller anden form globalt skema, som tillader globale transaktioner

27 04-11-2007/FENNOEA/IT - Databaser/DDB27 Særlige problemer i FDBS Forskellige datamodeller: –Legacy db, RDB, ODB, flade filer, mm. Forskellige constraint-mekanismer Forskellige forespørgselssprog Semantisk forskelligheder: –Samme objekt (konto) kan have både ens og forskellige attributter i to DB’er –Mmm. Behov en kanonisk form for datamodeller

28 04-11-2007/FENNOEA/IT - Databaser/DDB28 Date’s 12 Rules for a DDBMS 0.Fundamental Principle To the user, a distributed system should look exactly like a nondistributed system. 1.Local Autonomy 2.No Reliance on a Central Site 3.Continuous Operation 4.Location Independence 5.Fragmentation Independence 6.Replication Independence

29 04-11-2007/FENNOEA/IT - Databaser/DDB29 Date’s 12 Rules for a DDBMS 7.Distributed Query Processing 8.Distributed Transaction Processing 9.Hardware Independence 10.Operating System Independence 11.Network Independence 12.Database Independence Last four rules are ideals.

30 04-11-2007/FENNOEA/IT - Databaser/DDB30 Query processing i DDB Mål: reduktion af netværkstrafik Eksempel: –Employee på site 1 –Department på site 2 (ingen fragmentering) –Employee fylder 10000*100Bytes= 1 MB –Department fylder 100*35 Bytes = 3.5 KB

31 04-11-2007/FENNOEA/IT - Databaser/DDB31 Eksempel fortsat Query: π FNAME,LNAME,DNAME (Employee * DNO=DNUMBER Department) Q fyres af fra site 3 3 strategier (antag at en resultattuple er 40 Bytes): 1.Overfør Employee og Department til site 3 og udfør JOIN- operationen der. Overførsel af 1,003.5 KB 2.Overfør Employee til site 2. Udfør JOIN-operation på site 2 og overfør resultatet til site 3. Overførsel af 40*10,000+1,000,000 = 1,400 KB 3.Overfør Department til site 1. Udfør JOIN der og overfør resultatet til site 3. Overførsel af 3.5 KB + 400 KB= 403.5 KB –Strategi 3 er at foretrække

32 04-11-2007/FENNOEA/IT - Databaser/DDB32 Eksempel fortsat Betragt nu query: π FNAME,LNAME,DNAME (Employee * SSN=MGRSSN Department) Giver 100 tuples á 40 Bytes Strategier: 1.JOIN på site 3: 1 MB + 3.5 KB = 1003.5 KB 2.JOIN på site 2: 1 MB + 40*100 Bytes = 1004 KB 3.JOIN på site 1: 3.5 KB + 4 KB = 7.5 KB –Igen vinder site 1 – denne gang stort –Antag, at initierende site er site 2: –Overfør Employee til site 2 (1MB) –Over Department til site 1 og returner resultatet (7.5KB)

33 04-11-2007/FENNOEA/IT - Databaser/DDB33 Semi-join Ofte er semi-join en god strategi (R*S): –Kun JOIN-attributten fra R overføres –JOIN udføres på S’s site og relevante attributter projiceres ud og returneres til R’s site –Reultatet JOIN’es med R Anvendes semi-join i vores to eksempler:

34 04-11-2007/FENNOEA/IT - Databaser/DDB34 π FNAME,LNAME,DNAME (Employee * DNO=DNUMBER Department) 1.Project DNUMBER fra Department på site 2 og overfør til site 1. Overførsel 100*4 Bytes= 0.4 KB 2.Join med Employee på site 1. Project og overfør resultatet til site 3: Overførsel 10,000*34Bytes= 340 KB π FNAME,LNAME,MGRSSN (Employee * SSN=MGRSSN Department) 1.Project MGRSSN fra Department på site 2 og overfør til site 1. Overførsel 100*9 Bytes= 0.9 KB 2.Join med Employee på site 1. Project og overfør resultatet til site 3: Overførsel 100*39Bytes= 3.9 KB

35 04-11-2007/FENNOEA/IT - Databaser/DDB35 Transaktionshåndtering i DDB Skal sikre konsistens mellem fragmenter i tilfælde af replikering Fortsat drift ved udfald af enkelte sites. Ved recovery skal siten opdateres Kommunikationsfejl Distribueret commit (2PC) Evt. håndtering af distribueret dead-lock Distribueret recovery

36 04-11-2007/FENNOEA/IT - Databaser/DDB36 2 Phase Commit Protokol (2PC) For transaktionen udnævnes en koordinator Fase 1: Preparing for commit: –Koordinatoren sender ”PREPARE” til alle sites, som skriver i loggen. Herefter svares ”OK” eller ”NOT OK” (intet svar inden time out == ”NOT OK”) Fase 2: Commit: –Hvis alle har svaret ”OK”, så sender koordinatoren ”COMMIT” –Ellers sendes ”ROLLBACK” Idet al information skrives i fase 1, så er rollback (fase 1) eller recovery (fase 2) mulig.

37 04-11-2007/FENNOEA/IT - Databaser/DDB37 Distribueret låsning Distinguished (udvalgt) kopi (DC): –En site udvælges til at have en særlig kopi af et dataelement og bliver ansvarlig for låsning på dette element –Alle forespørgsler om låse på dette element sendes til denne site Forskellige metoder afhængig af hvordan DC udvælges

38 04-11-2007/FENNOEA/IT - Databaser/DDB38 Primary site technique- evt. med backup site En central site er DC for alle dataitems –Simpel udvidelse af centraliseret transaktionshåndtering (2PL er lige ud ad landevejen) –Denne DC bliver flaskehals og ”single point of failure” –Bemærk kun låsene er centraliseret. Når først en transaktion har en lås, så kan en vilkårlig kopi af dataelementet tilgås For at imødegå ”Single point of failure” udpeges en backup-site: –Al låseinformation replikeres på backup-siten –Hvis DC’en fejler, så overtager backup-siten og en ny backup-site vælges –Forværrer flaskehals-problemet

39 04-11-2007/FENNOEA/IT - Databaser/DDB39 Primary Copy technique – evt. med backup Forskellige dataelementer får forskellige sites som værter for deres PC (Primary copy). –Spreder belastning ved låsehåndtering –Intet ”single point of failure” –Men alle kopier af et dataelement er utilgængeligt, hvis dets primary copy er nede

40 04-11-2007/FENNOEA/IT - Databaser/DDB40 Transaktionshåndtering baseret på ”voting” Alle sites, som har en kopi af et dataelement, har sin egen låsemekanisme Når en transaktion ønsker en lås, så sendes request til alle sites, som har en kopi Hvis et flertal af disse sites giver svaret ”ok”. Så sendes en meddelelse til alle om, at man har låsen Ægte distribueret, men koster netværkstrafik, og er ekstremt kompliceret, når der skal tages højde for fejl undervejs.

41 04-11-2007/FENNOEA/IT - Databaser/DDB41 Traditionel WEB-adgang til DB Præsentationslag: –WEB-serveren genererer HTML, som præsenteres i browseren hos klinten Applikationslag –forretningslogik) er indlejeret i web-serveren i form af scripts, som bla. kalder databaselaget Databaselag (centraliseret DBMS) Interne applikationer på applikationsserveren: –forretningslogik er dubleret (WEB-server og appl.- server) Databaselag – (fx SQL-baserede DBMS på en databaseserver) WEB-server WEB- klienter Præsentationslag (browser) Applikationslag Applikations server Dedikeret klient firewall

42 04-11-2007/FENNOEA/IT - Databaser/DDB42 I dag: n-tier Client/Server arkitektur: Præsentationslag: –dedikerede klienter, inden for eller uden for fire-wallen –web-browser via en web-server. Bemærk, at web-serveren er klient i forhold til applikationsserveren –Dedikerede klienter, som til via web-services på web-serveren (web-serveren fungerer som proxy) Applikationslag (forretningslogik) bør ikke ligge på web-serveren Databaselag (centraliseret DBMS) –Der kan være flere database- servere i databaselaget, i så fald får applikationslaget rollen som koordinator ved globale transaktioner Applikations server Databaselag – (fx SQL-baserede DBMS’er på flere databaseservere) WEB- klienter Præsentationslag WEB- server firewall Dedikeret klient WEB Services tilgås Dedikeret klient

43 04-11-2007/FENNOEA/IT - Databaser/DDB43 Opgave Web-adgang og Distribution af databasen for Nørhalne Bibliotek. ORDB-WEB-DDB.doc