1 / 43

Lektion 13

Lektion 13. Distribuerede databaser Begreber Design: fragmentering, allokering Arkitekturer Query Processing Transaktionshåndtering. Begreber.

helene
Download Presentation

Lektion 13

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lektion 13 Distribuerede databaser Begreber Design: fragmentering, allokering Arkitekturer Query Processing Transaktionshåndtering NOEA/IT - Databaser/DDB

  2. 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 NOEA/IT - Databaser/DDB

  3. 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 distribueret? NOEA/IT - Databaser/DDB

  4. Parallel DBMS a) shared memory b) shared disk c) shared nothing NOEA/IT - Databaser/DDB

  5. Centraliseret DBMS med netværksadgang(klassisk Client/Server) NOEA/IT - Databaser/DDB

  6. Distribueret DBMS NOEA/IT - Databaser/DDB

  7. Fordele ved distribueret DBMS • Forskellige niveauer af transparens • Højere grad af pålidelighed (reliability) og tilgængelighed (availability) • Bedre performance • Bedre scalerbarhed NOEA/IT - Databaser/DDB

  8. Transparens • Distributions- eller netværkstransparens: • Location transparens • Naming transparens • Replikeringstransparens • Fragmenteringstransparens: • Horisontal fragmentering • Veritikal fragmentering NOEA/IT - Databaser/DDB

  9. Company-databasen NOEA/IT - Databaser/DDB

  10. Fragmentering og replikering Replikering og horisontal fragmentering NOEA/IT - Databaser/DDB

  11. 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 NOEA/IT - Databaser/DDB

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

  13. 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 NOEA/IT - Databaser/DDB

  14. 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) NOEA/IT - Databaser/DDB

  15. 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 NOEA/IT - Databaser/DDB

  16. 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 NOEA/IT - Databaser/DDB

  17. 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 NOEA/IT - Databaser/DDB

  18. 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 NOEA/IT - Databaser/DDB

  19. 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 NOEA/IT - Databaser/DDB

  20. Works_On{Pno, ESSN, hours} • Kan fragmenteres efter: • Den afdeling, som den ansatte tilhører • Den afdeling, der kontrollerer projektet NOEA/IT - Databaser/DDB

  21. Efter den afdeling, som den ansatte tilhører NOEA/IT - Databaser/DDB

  22. 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 NOEA/IT - Databaser/DDB

  23. G1, G2, G3, G4 og G7 NOEA/IT - Databaser/DDB

  24. G2, G4, G5, G6 og G8 NOEA/IT - Databaser/DDB

  25. Arkitekturer • Homogene: • Samme DBMS på hver site og hver klient • Heterogene • Lokal autonomi • Ingen lokal autonomi NOEA/IT - Databaser/DDB

  26. 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 NOEA/IT - Databaser/DDB

  27. 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 NOEA/IT - Databaser/DDB

  28. 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 NOEA/IT - Databaser/DDB

  29. 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. NOEA/IT - Databaser/DDB

  30. 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 NOEA/IT - Databaser/DDB

  31. 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): • Overfør Employee og Department til site 3 og udfør JOIN-operationen der. Overførsel af 1,003.5 KB • 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 • 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 NOEA/IT - Databaser/DDB

  32. Eksempel fortsat • Betragt nu query: πFNAME,LNAME,DNAME(Employee *SSN=MGRSSN Department) • Giver 100 tuples á 40 Bytes • Strategier: • JOIN på site 3: 1 MB + 3.5 KB = 1003.5 KB • JOIN på site 2: 1 MB + 40*100 Bytes = 1004 KB • 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) NOEA/IT - Databaser/DDB

  33. 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: NOEA/IT - Databaser/DDB

  34. πFNAME,LNAME,DNAME(Employee *DNO=DNUMBER Department) • Project DNUMBER fra Department på site 2 og overfør til site 1. Overførsel 100*4 Bytes= 0.4 KB • 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) • Project MGRSSN fra Department på site 2 og overfør til site 1. Overførsel 100*9 Bytes= 0.9 KB • Join med Employee på site 1. Project og overfør resultatet til site 3: Overførsel 100*39Bytes= 3.9 KB NOEA/IT - Databaser/DDB

  35. 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 NOEA/IT - Databaser/DDB

  36. 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. NOEA/IT - Databaser/DDB

  37. 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 NOEA/IT - Databaser/DDB

  38. 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 NOEA/IT - Databaser/DDB

  39. 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 NOEA/IT - Databaser/DDB

  40. 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. NOEA/IT - Databaser/DDB

  41. Præsentationslag (browser) WEB-klienter Applikationslag WEB-server firewall Dedikeret klient Applikationsserver 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) NOEA/IT - Databaser/DDB

  42. WEB Services tilgås Præsentationslag Dedikeret klient Dedikeret klient WEB-klienter Dedikeret klient WEB-server Applikationsserver firewall Databaselag – (fx SQL-baserede DBMS’er på flere databaseservere) 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 NOEA/IT - Databaser/DDB

  43. Opgave • Web-adgang og Distribution af databasen for Nørhalne Bibliotek. ORDB-WEB-DDB.doc NOEA/IT - Databaser/DDB

More Related