Distribuované DBS Jaroslav Pokorný FI BVŠP Bratislava

Prezentace na téma: "Distribuované DBS Jaroslav Pokorný FI BVŠP Bratislava"— Transkript prezentace:

1 Distribuované DBS Jaroslav Pokorný FI BVŠP Bratislava
Databázové systémy Distribuované DBS Jaroslav Pokorný FI BVŠP Bratislava

2 Obsah Definice problému Pojem distribuovaného SŘBD Přístupy k DSŘBD
Distribuované zpracování dotazu Transakce – zotavení z chyb Praxe: replikační zpracování J. Pokorný

3 Definice problému centralizovaná DB: Praha Hradec Králové Plzeň
J. Pokorný

4 Definice problému Distribuovaná DB: DB je umístěna na více místech
Místa jsou propojena Plzeň Hradec Králové J. Pokorný

5 Definice problému nyní: connect k HK; exec sql select * from ZAM; ...
connect k Pl; exec sql select * from ZAMĚSTNANEC; ... Hradec Králové Plzeň ZAMĚSTNANEC SŘBD2 SŘBD1 ZAM J. Pokorný

6 Definice problému lépe:
connect k distr-HK; exec sql select * from DZAM; Hradec Králové ZAMĚSTNANEC DSŘBD DSŘBD ZAM SŘBD2 SŘBD1 Plzeň J. Pokorný

7 Distribuce Distribuovaný výpočetní systém (DVS)
rozložen do uzlů (míst) sítě svázaných komunikačními kanály, v uzlech je umožněno autonomní uložení a zpracování dat, prostředky v uzlech mohou být nehomogenní, avšak rovnocenné uživatel nic neví o existenci ostatních uzlů sítě (transparence) DSŘBD je speciálním případem DVS J. Pokorný

8 Výhody DDBS data tam, kde se nejvíce používají rozdělení zátěže
snižuje se cena komunikace větší spolehlivost systému lepší škálovatelnost lepší dostupnost, možnost sdílení, integrace zachování autonomního zpracování J. Pokorný

9 Nevýhody DDBS složitější návrh složitější optimalizace
složitější slovník dat složitější globální transakční zpracování složitější uváznutí redundance implikuje složitější zotavení z chyb heterogennost v uzlech implikuje složitější integraci J. Pokorný

10 Typy DDBS shora dolů (společně organizovaná data, globální schéma)
zdola nahoru (integrace heterogenních dat, globální schéma) federativní integrace (schémata importu a exportu) Pz.: speciální případy – klient/server, replikační přístup J. Pokorný

11 Přístupy k DSŘBD Ve třech dimenzích: autonomie transparence distribuce
heterogennost J. Pokorný

12 Přístupy: autonomie těsné spojení federace úplná izolace J. Pokorný

13 Přístupy: transparence distribuce
DB místo 1 DB místo 1 R1 R3 R1 R1 R3=f(R1,R2) místo 2 R2 R2 místo 2 R2 R4 R4=g(R1,R2) distribuce relací distribuce odvozených dat J. Pokorný

14 Přístupy: transparence distribuce
DB místo 1 DB místo 1 f R1 R1 R1 R1 R2 místo 2 R2 R2 místo 2 g R2 R1 R2 distribuce typu momentka replikované relace J. Pokorný

15 Přístupy: transparence distribuce
místo 1 R11 R21 DB R1 = R11  R12 R2 = R21  R22 R1 místo 2 R2 R12 R22 fragmentace relací Pozor! Bezeztrátovost spojení. J. Pokorný

16 Typy fragmentace vertikální fragmentace ROD_Č JMÉNO ADRESA 480423/016
Novák Široká 24 ... 430122/116 Dvořák Kožená 2 Horizontální fragmentace J. Pokorný

17 Typy fragmentace Definice fragmentů pomocí RA
Př.: KINO(NÁZEV_K, ADR, JMÉNO_V, Č_TELEFONU) Fragmentace 1: KINO1 := KINO(ADR = ‘Praha 1’) KINO2 := KINO(ADR = ‘Praha 2’) KINO3 := KINO(ADR  ‘Praha 1’ AND ADR  ‘Praha 2’) Fragmentace 2: PŘEDSTAVENÍ1:=PŘEDSTAVENÍ <* KINO(ADR= ‘Praha 1’) PŘEDSTAVENÍ2:=PŘEDSTAVENÍ <* KINO(ADR=‘Praha 2’) J. Pokorný

18 Fragmentace místo 1 R11 R1 R21 místo 2 R2 R22 R4 R31 R3 R R41
fragmenty alokace J. Pokorný

19 Transparence obecněji
transparence dat: stupeň, ve kterém DSŘBD odstíní uživatele od detailů, jak a kde jsou umístěna data. Rozlišujeme: transparenci fragmentace transparenci distribuce transparenci replikace J. Pokorný

20 Alternativy DSŘBD Distribuce: žádná, klient-server, peer-to-peer
Autonomie: těsné spojení, federace, úplná izolace Heterogennost: homogenní, heterogenní J. Pokorný

21 Některé architektury distribuované vícenásobné SŘBD
Distribuce peer-to-peer distribuované SŘBD klient-server Autonomie vícenásobné SŘBD Heterogennost federované SŘBD J. Pokorný

22 Architektura schémat globální ext. sch. globální konceptuální schéma
globální schéma distribuce schéma lokální reprezentace lokální konceptuální schéma lokální interní schéma J. Pokorný

23 Příklad UZEL: DÍL(Č_DÍLU, Č_DODAVATELE,CENA)
ADRESÁŘ (Č_DODAVATELE, MĚSTO) DODAVATEL(Č_DODAVATELE, JM_DODAVATELE) KUS(Č_KUSU, CENA, FIRMA_DODAVATELE) DODAVATEL(Č_DODAVATELE, FIRMA_DODAVATELE, PSČ, MĚSTO) IO: v 1. uzlu díly od dodavatelů , v 2. uzlu od dodavatelů DÍL je ve 3NF. J. Pokorný

24 Příklad Schémata relačních DB představují LKS v uzlech
Strategie integrace (SLR): do globálního světa „co nejvíce“ (použité NULL) do globálního světa „spíše průnik dílčích světů“ uzel LR_DÍL(ČÍS_DÍLU, ČÍS_DODAVATELE, CENA), LR_ADRESÁŘ(ČÍS_DODAVATELE, MĚSTO) LR_DÍL(KUS * DODAVATEL)[Č_KUSU, Č_DODAVATELE, CENA] LR_ADRESÁŘ  DODAVATEL[Č_DODAVATELE, MĚSTO] Pz: jaké budou klíče těchto tabulek? J. Pokorný

25 Příklad GSD se bude obsahovat SLR1  SLR2.
Rozdělení dat v GSD bude dáno tabulkou: LR_DÍL 1 ČÍS_DÍLU < 650 LR_DÍL 1,  ČÍS_DÍLU  700 LR_DÍL 2 ČÍS_DÍLU > 700 GKS obsahuje relace GK_DÍL a GK_ADRESÁŘ se stejnými atributy jako LR_DÍL a LR_ADRESÁŘ. Může však být def. pomocí RA z GSD. Pz.: RA je vhodná, ale nestačí, např. pro ADRESA a atributů (PSČ, MĚSTO, ULICE, Č_DOMU) je třeba speciální funkci (konkatenace) nebo: barva (číslo vs. název) J. Pokorný

26 Komponenty DSŘBD UŽIVATEL uživatelské rozhraní Kontroler sémantiky
Optimalizátor globálních dotazů Monitor globalního volání externí schéma globální konceptuální GD/D Reakce systému AP lokální lokální Interní systemový katalog procesor pro podporu runtime manažer lokálního zotavení z chyb lokální dotazy Databáze DP Uživatelské požadavky J. Pokorný

27 Distribuované zpracování dotazu
problémy (přídavné k centralizovanému případu) cena přenosů cpu, disk, #přenášených Byte, #přenášených zpráv paralelismus / překrývání prodlev Jak minimalizovat uběhnutý čas? Nebo jak minimalizovat spotřebu zdrojů? J. Pokorný

28 Optimalizace distribuovaného dotazu – polospojení
DODAVATEL DODÁVKA M1 Č_D Č_ZBOŽÍ d1 z1 d2 d3 z5 z9 Č_D ... d1 d2 d5 d11 z1 M3 DODAVATEL * DODÁVKA = ? J. Pokorný

29 Polospojení volba plánů:
P1: přesuň DODÁVKA -> M1; *; přesuň výsledek -> M3 P2: přesuň DODÁVKA->M3; přesuň DODAVATEL->M3; * ... další? J. Pokorný

30 Polospojení Idea: před přesuny redukovat tabulky M1 M3 M2 DODAVATEL
DODÁVKA M1 Č_D Č_ZBOŽÍ d1 z1 d2 d3 z5 z9 Č_D ... d1 d2 d5 d11 M3 M2 DODAVATEL * DODÁVKA = ? J. Pokorný

31 Polospojení Idea: před přesuny redukovat tabulky, např DODÁVKA DODAVATEL DODÁVKA (d1,d2,d5,d11) M1 Č_D Č_ZBOŽÍ d1 z1 d2 d3 z5 z9 Č_D ... d1 d2 d5 d11 M3 M2 DODAVATEL * DODÁVKA = ? J. Pokorný

32 Polospojení Formálně: DODÁVKA’ = DODÁVKA <* DODAVATEL
Pz: vyjádření polospojení pomocí RA: R <* S  (R * S)[R] J. Pokorný

33 Polospojení – příklad Velikost hodnoty každého atributu je 4 Byte
Q: cena přenosu (#Byte) pro polospojení DODÁVKA’ = DODÁVKA <* DODAVATEL J. Pokorný

34 Polospojení Idea: před přesuny redukovat tabulky M1 M2 M3 4 Byte
DODAVATEL DODÁVKA (d1,d2,d5,d11) M1 Č_D Č_ZBOŽÍ d1 z1 d2 d3 z5 z9 Č_D ... d1 d2 d5 d11 M3 M2 4 Byte DODAVATEL * DODÁVKA = ? J. Pokorný

35 Polospojení – příklad Předpoklad: hodnota každého atributu 4 Byte
Q: cena přenosu (#Byte) pro polospojení DODÁVKA’ = DODÁVKA <* DODAVATEL Zde: Q = 4*4 Byte J. Pokorný

36 Strategie krok1: navrhni plán s polospojením(i)
krok2: odhadni jeho cenu (# přenesených Byte) J. Pokorný

37 Polospojení – příklad P3: Cena?
redukuj DODÁVKA na DODÁVKA’ DODÁVKA’ -> M3 DODAVATEL -> M3 proveď * v M3 Cena? Předpoklad: hodnota každého atributu 4 Byte J. Pokorný

38 Polospojení M1 4 Byte 4 Byte M3 M2 4 Byte 4 Byte DODAVATEL DODÁVKA
(d1,d2,d5,d11) M1 Č_D Č_ZBOŽÍ d1 z1 d2 d3 z5 z9 Č_D ... d1 d2 d5 d11 4 Byte 4 Byte M3 M2 4 Byte 4 Byte J. Pokorný

39 Polospojení – příklad Q pro P3: 72 Byte celkem
4*4 Byte - redukuj DODÁVKA na DODÁVKA’ 3*8 Byte - DODÁVKA’ -> M3 4*8 Byte - DODAVATEL -> M3 72 Byte celkem J. Pokorný

40 Další plány? P4: redukuj DODÁVKA na DODÁVKA’
redukuj DODAVATEL na DODAVATEL’ DODÁVKA’ -> M3 DODAVATEL’ -> M3 J. Pokorný

41 Další plány? P5: redukuj DODAVATEL na DODAVATEL’ DODAVATEL’ -> M2
proveď * v M2 přesuň výsledek -> M3 J. Pokorný

42 Transakce v DSŘBD Problém: transakce provádí převod
1000 Kč z HK -> 500 do Pl, 500 do ČB 3 dílčí transakce na 3 systémech Jak garantovat atomicitu (všechno nebo nic)? Pozorování: další typy chyb (připojení servery, prodlevy, time-outs ....) J. Pokorný

43 Monitor globálního volání
Monitor globálního volání (koordinátor transakcí, transakční monitor) analyzuje požadavky T, rozděluje ji na dílčí transakce (DT), provádí syntézu výsledků, Implementace: jeden ve vybraném místě distribuovaný: je v každém uzlu sítě J. Pokorný

44 Monitor globálního volání
Role: Zajišťuje přidělení privátního prostoru B pro T, kterou řídí: Zajišťuje promítnutí hodnot do DB Zajišťuje řízení kopií objektu v DB Zajišťuje konzistenci DB J. Pokorný

45 Monitor globálního volání
akce při read(X): if B obsahuje X then XT else vyber kopii X a pošli požadavek do lokálního SŘBD S, který pak umístí X do B. write(X): if B obsahuje X then proveď aktualizaci všech jeho kopií else vytvoř kopii X s danou hodnotou. Požadavek na EOT. Provede akce např. podle 2PC. J. Pokorný

46 Distribuované zotavení z chyb
Plzeň jak? T1,2: +500 Kč HK ČB HK T1,3: +500 Kč T1,1: Kč J. Pokorný

47 Problém: dominový efekt
time T1,2 T2 obdržení A T1,1 B:=B+A Write(B) EOT EOT pro T1,1 Read(C) A:=500 pošli(A) Read(B) B:=B-C Write(C) čekání na EOT od T1,2 obdržení zhroucení systému J. Pokorný

48 Distribuované zotavení z chyb
Plzeň Krok1: zvol koordinátora T1,2: +500 Kč HK ČB HK T1,3: +500 Kč T1, Kč koordinátor J. Pokorný

49 Distribuované zotavení z chyb
Krok 2: vyvolej protokol, např. dvoufázový potvrzovací protokol (2PC) Fáze 1: dosáhne-li DT RC-bod (ready-to-commit), hlásí to koordinátorovi, ale neuvolní změny pro jiné transakce. V RC-hlášení: A (je připraven k potvrzení, N (ABORT); Fáze 2: koordinátor shromáždí všechna RC-hlášení. Vyšle COMMIT, když jsou všechna A. Vyšle ABORT, jestli alespoň 1 DT hlásí N nebo vypršel time-out. Pz: Někdy ještě čeká na COMMIT, ABORT od všech DT. J. Pokorný

50 2PC: úspěšné provedení T1,1 (koord.) T1,2 T1,3 připrav ke commit time
J. Pokorný

51 2PC: úspěšné provedení T1,1 (koord.) T1,2 T1,3 připrav ke commit
RC-hlášení: A RC-hlášení: A time J. Pokorný

52 2PC: úspěšné provedení time T1,1 (koord.) T1,2 T1,3 připrav ke commit
RC-hlášení: A commit EOT J. Pokorný

53 2PC: neúspěšné provedení
T1,1 (koord.) T1,2 T1,3 připrav ke commit time J. Pokorný

54 2PC: neúspěšné provedení
T1,1 (koord.) T1,2 T1,3 připrav ke commit RC-hlášení: N RC-hlášení: A time J. Pokorný

55 2PC: neúspěšné provedení
time T1,1 (koord.) T1,2 T1,3 připrav ke commit abort RC-hlášení: N RC-hlášení: A J. Pokorný

56 Problémy s 2PC Blokování Nezávislé zotavení z chyb není možné
Ready způsobuje, že participanti čekají na koordinátora Jestliže koordinátor chybuje, místo je blokováno až do zotavování z chyb. Blokování redukuje dostupnost. Nezávislé zotavení z chyb není možné Byl navržen 3PC protokol pro řešení blokovacích problémů. 3PC je neblokující (nerealistický, ale redukující). J. Pokorný

57 Replikace dat fragment relace je replikovaný, je-li uložen současně na více místech. úplná replikace relace: případ, kdy je relace umístěna ve všech místech plně redundantní databáze: případ, kdy je databáze umístěna ve všech místech J. Pokorný

58 Replikace dat výhody dostupnost: chyba v místě s relací R nevede k nedostupnosti R, paralelismus: dotazy nad R mohou být zpracovávány paralelně na více místech, redukce přenosů dat. nevýhody složitější aktualizace: každá replika R musí být aktualizována, zvýšená složitost řízení souběžného zpracování: možnost vzniku nekonzistence dat, J. Pokorný

59 Strategie aktualizací
v závislosti - KDY: synchronní (rychlejší) asynchronní (pomalejší) v závislosti - KDE: primární kopie (master) aktualizace kdekoliv master kdekoliv synch asynch J. Pokorný

60 Strategie aktualizací
synchronní + žádné nekonzistence (identické kopie) + čtení lokální kopie poskytuje aktuální hodnotu + změny jsou atomické - transakce musí aktualizovat všechna místa - delší čas transakce - nižší dostupnost asynchronní + transakce je vždy lokální (dobrý čas odpovědi) - nekonzistence dat - lokální čtení ne vždy vrací aktuální hodnotu - změny do všech kopií nejsou garantovány - replikace není transparentní aktualizace kdekoliv + jakékoliv místo může zpracovat transakci (změnu) + zatížení je rovnoměrně distribuováno - kopie je třeba synchronizovat primární kopie + žádná synchronizace mezi místy není nutná (je v primární kopii) + existuje vždy jedno místo, které má všechny aktualizace - v primární kopii může být velké zatížení - čtení lokální kopie nemusí poskytovat aktuální hodnoty J. Pokorný

61 Replikační strategie master kdekoliv synch asynch
+ změny nemusí být koordinovány + žádné nekonzistence dlouhá odezva v hodné pro málo změn lokální kopie mohou být pouze čteny + žádné nekonzistence + elegantní (symetrické) řešení dlouhá odezva změny musí být koordinovány synch asynch + koordinace není nutná + krátký čas odezvy lokální kopie nejsou up-do-date nekonzistence + žádná centrální koordinace + nejkratší čas odezvy změny mohou být ztraceny (urovnávání rozdílů) nekonzistence J. Pokorný

62 Distribuovaný monitor globálního volání
Řešení protokolů:   primární kopie většinový protokol konsensus kvórem … slabá konsistence J. Pokorný

63 Protokol primární kopie
zvol repliku prvku dat jako jeho primární kopii. její místo je primární místo pro daný prvek dat různé prvky dat mohou mít různá primární místa požaduje-li transakce zamknout prvek P, požaduje to na primárním místě pro P. odtud se provádějí propagace změn na kopie výhody: souběžné zpracování jako na nereplikovaných datech – jednoduchá implementace. nevýhody v případě chyby v primárním místě, je P nedostupný, dokonce i když jiná místa s replikou P jsou dostupná J. Pokorný

64 Slabě konsistentní replikace
negarantuje uspořádatelnost Př.: replikace master-slave – aktualizace jsou prováděny v jednom “master” místě a jsou propagovány do “slave” míst. Propagace není součástí transakce !: Může nastat bezprostředně po potvrzení transakce, Může být periodická Data v podřízených místech mohou být pouze čtena, nikoliv aktualizována Netřeba používat zámky na vzdálených místech Využitelné při distribuci informací (např. centrální úřad a jeho pobočky) J. Pokorný

65 Závěry Architektury DSŘBD se liší v integraci lokálních db a úrovni nezávislosti dat. DDBS korespondují organizační struktuře podniku (státní správy, e-komerce,…) Ekonomické přínosy větší výpočetní síla více disciplíny Aplikace: paralelní db / klastry aktivní disky replikované db (servery pro e-komerci) J. Pokorný