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

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ý

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

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ý

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ý

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ý

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ý

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ý

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ý

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ý

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

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

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ý

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ý

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ý

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ý

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ý

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

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ý

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

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ý

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ý

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ů 000-700, v 2. uzlu od dodavatelů 650-999. DÍL je ve 3NF. J. Pokorný

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ý

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,2 650  ČÍ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ý

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ý

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ý

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ý

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ý

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ý

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ý

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

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ý

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ý

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ý

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

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ý

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ý

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ý

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

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

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ý

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ý

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ý

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ý

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

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ý

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

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ý

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

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ý

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

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

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ý

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ý

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ý

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ý

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ý

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ý

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ý

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ý

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

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ý

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ý

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ý