Obsah

1. Zpracování datv distribuovaných DBSspeciální přednáška pro NSWI035 - Principy distribuovaných systémů

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í

3. 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í

4. Definice problému centralizovaná DB: Praha Hradec Králové Plzeň

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

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

7. 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ň

8. 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í

9. 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

10. 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í

11. 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

12. 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í

13. 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) • škálovatelné NoSQL databáze pro webové aplikace a cloud computing Pz.: speciální případy – klient/server, replikační přístup,

14. místo 1 Fragmentace tabulky R11 R1 R21 místo 2 R2 R22 R4 R31 R3 R R41 alokace fragmenty

15. globální ext. sch. globální ext. sch. Místo n globální konceptuální schéma globální schéma distribuce schéma lokální reprezentace schéma lokální reprezentace lokální konceptuální schéma lokální konceptuální schéma lokální interní schéma lokální interní schéma Obecná architektura schémat Místo 1

16. Příklad konstrukce schémat • UZEL: DÍL(Č_DÍLU, Č_DODAVATELE,CENA) ADRESÁŘ (Č_DODAVATELE, MĚSTO) DODAVATEL(Č_DODAVATELE, JM_DODAVATELE) • UZEL: 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.

17. 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) • uzel LR_DÍL(KUS * DODAVATEL)[Č_KUSU, Č_DODAVATELE, CENA] LR_ADRESÁŘ DODAVATEL[Č_DODAVATELE, MĚSTO]

18. Příklad • GSD 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)

19. 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í

20. 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ů?

21. Optimalizace distribuovaného dotazu – polospojení M2 DODAVATEL DODÁVKA M1 M3 DODAVATEL * DODÁVKA = ?

22. 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ší?

23. Polospojení Idea: před přesuny redukovat tabulky DODAVATEL DODÁVKA M1 M3 M2 DODAVATEL * DODÁVKA = ?

24. Polospojení Idea: před přesuny redukovat tabulky, např DODÁVKA DODAVATEL DODÁVKA (d1,d2,d5,d11) M1 M3 M2 DODAVATEL * DODÁVKA = ?

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

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

27. Polospojení Idea: před přesuny redukovat tabulky DODAVATEL DODÁVKA (d1,d2,d5,d11) M1 M2 M3 4 Byte DODAVATEL * DODÁVKA = ?

28. 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

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

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

31. 4 Byte 4 Byte 4 Byte 4 Byte Polospojení DODAVATEL DODÁVKA (d1,d2,d5,d11) M1 M3 M2

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

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

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

35. 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í

36. 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)? Např. pomocí 2PC. • Pozorování: další typy chyb (připojení servery, prodlevy, time-outs ....)

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

38. Transakční monitor Transakční monitor(monitor globálního volání, koordinátor transakcí) • 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ě

39. Transakční monitor 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

40. Distribuované zotavení z chyb • Základní technika: zámky (podobně jako v 2PL protokolu u centralizovaných SŘBD) • Další problémy: • uváznutí, • problémy s 2PC (co když nastane chyba u koordinátora, co když není spojení atd.) • Různá řešení (např. 3-phase commit)

41. 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í

42. Replikace dat • fragment relacejereplikovaný, je-li uložen současně na více místech. • úplnáreplikacerelace: 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

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

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

45. Replikační strategie master kdekoliv • + 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

46. Distribuovaný transakční monitor Řešení protokolů: • primárníkopie • většinový protokol • konsensus kvórem • … • slabá konsistence

47. Protokol primární kopie • zvol repliku prvku dat jako jeho primární kopii. • její místo je primární místopro 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á

48. Slabě konsistentní replikace • negarantuje uspořádatelnost rozvrhu • 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)

49. Mobilní databáze • mobilní databáze je rozšíření distribuovaného DBS. • mobilní databáze může obsahovat databáze spojené sítí pevných linek a databáze zabudované na mobilní stanice. • charakteristiky: • bezdrátová síť má omezenou šířku pásma, • energie použitá v mobilních stanicích má omezenou dobu života, • kvůli energetickým omezenímnejsou mobilní stanice vždy dostupné, • mobilní stanice se pohybují různou rychlostí a v různých oblastech.

50. Mobilní databáze • Maje uvedené charakteristiky, problém souběžného zpracování v mobilních databázích je těžší než v distribuovaných databázích. • Odpojení stanice je dlouhé, takže uzamykací protokoly a časová razítka nejsou vhodné. 2PC je nevhodný také, protože dostupnost je redukována. • Pro prostředí s mobilními databázemi byly navrženy různé transakční modely založené na uvolnění vlastností ACID a uvolnění uspořádatelnosti.