Rozproszone bazy danych

1. Rozproszone bazy danych Przygotował Lech Banachowski na podstawie: • Raghu Ramakrishnan, Johannes Gehrke, Database Management Systems, McGrawHill, 2000 (książka i slide’y). • Lech Banachowski, Krzysztof Stencel, Bazy danych – projektowanie aplikacji na serwerze, EXIT, 2001.

2. Przy rozproszeniu użytkowników w sieci internetowej • Najprostsza organizacja bazy danych - baza scentralizowana: dane są przechowywane w jednym węźle sieci. • Zalety: • Jeden system kontroli danych zapewniający spójność danych. • Przetwarzanie transakcji i odtwarzanie po awarii objęte sprawdzonymi algorytmami i protokołami. • Wady: • Potencjalnie długi czas oczekiwania na rezultaty z odległego węzła sieci – bardzo długi przy awarii sieci lub centralnego węzła. • Brak kontroli nad danymi specyficznymi dla danego miejsca. • Generowanie dużego ruchu w sieci.

3. Przy rozproszeniu użytkowników w sieci internetowej • Możliwa organizacja bazy danych - baza rozproszona: dane są przechowywane w wielu węzłach sieci - część jest powtarzana (replikowana). • Zalety: • Dane bliżej końcowego użytkownika - szybsze zapytania. • Węzeł lokalny może mieć kontrolę nad swoimi danymi. • Zwiększenie dostępności danych w sieci (poprzez repliki). • Wady: • Trudności w utrzymaniu spójności danych. • Transakcje i odtwarzanie bardziej skomplikowane - przy awariach możliwe trudności w zakończeniu transakcji. • Bardziej skomplikowana aktualizacja danych (repliki).

4. Przykład • Rozproszona baza danych powinna reprezentować pojedynczy model danych firmy. • Przypuśćmy, że tworzymy model danych odzwierciedlający zarządzanie kadrami w pewnej organizacji i projektujemy rozproszoną bazę danych tak aby: • w biurze w Gdańsku znajdowały się dane dotyczące Polski Północnej, • w biurze w Krakowie dane dotyczące Polski Południowej a • w biurze w Warszawie dane dotyczące Polski Środkowej. • Informacje o strukturze firmy są replikowane i przechowywane w każdym węźle. Zakładamy, że tylko okresowo dane dotyczące wszystkich trzech regionów będą rozważane razem (np. w postaci raportów), dając obraz całego kraju.

5. Założenia • Dane są przechowywane w więcej niż w jednym węźle sieci – każdy z nich zarządzany przez osobną bazę danych. • Przezroczystość rozproszenia danych:Użytkownicy nie wiedzą, w którym dokładnie miejscu są przechowywane dane. • Transakcje rozproszone:Użytkownicy używają transakcji działających na wielu węzłach w taki sam sposób jak na jednym węźle.

6. Typy rozproszonych baz danych • Jednorodna:We wszystkich węzłach jest ten sam system zarządzania bazą danych. • Niejednorodna:W każdym węźle może być inny system zarządzania bazą danych. Gateway (Brama) DBMS1 DBMS2 DBMS3

7. TID Przechowywanie danych t1 t2 t3 t4 • Fragmentacja (tabeli) • Pozioma:zwykle na rozłączne fragmenty. • Pionowa:z możliwością odtworzenia całej tabeli. • Replikacja • Zwiększona dostępność danych. • Szybsze wykonywanie zapytań. • Synchroniczna vs. asynchroniczna. R1 R3 Węzeł A Węzeł B R1 R2

8. System zarządzania rozproszoną bazą danych • Słownik danych rozproszonej bazy danych jest znacznie bardziej złożony. Obejmuje on, na przykład informacje o położeniu fragmentów i replikacji tabel bazowych. • Problemy związane ze współbieżnością są zwielokrotnione w systemach rozproszonych. Propagowanie aktualizacji do szeregu różnych węzłów jest skomplikowane. • Optymalizator zapytań w prawdziwym systemie rozproszonym powinien być w stanie użyć informacje topologiczne o sieci (np. o koszcie przesłania danych między dwoma węzłami) przy decydowaniu jak najlepiej wykonać dane zapytanie.

9. SELECT AVG(S.age) FROM Sailors S WHERE S.rating > 3 AND S.rating < 7 Zapytania rozproszone • Fragmentacja pozioma: Wiersze z rating < 5 w Shanghai, >= 5 w Tokyo. • Trzeba obliczyć w obu węzłach SUM(age), COUNT(age). • Gdyby był warunek S.rating>6, tylko w jednym węźle. • Fragmentacja pionowa:sid i rating w Shanghai, sname i age w Tokyo, tid w obu. • Trzeba zrekonstruować tabelę i wykonać zapytanie. • Replikacja: Kopie Sailors dostępne w obu węzłach. • Wybór węzła uzależniony od lokalnego kosztu wykonania zapytania i od kosztu przesłania wyników.

10. LONDYN PARYŻ Rozproszone złączenia Sailors Reserves 500 stron 1000 stron • Sprowadzaj strony gdy trzeba, metoda Page Nested Loops, tabela Sailorszewnętrzna. • Koszt: 500 D + 500 * 1000 (D+S). • D – koszt odczytu/zapisu; S -kosztprzesłania strony. • Gdyby zapytanie nie było złożone w Londynie, trzeba by było dodać koszt przesłania wyniku. • Sprowadź całą tabelę:PrześlijReserves do Londynu. • Koszt: 1000 S + 4500 D (Złączenie SortMerge; koszt = 3*(500+1000)). • Jeśli rozmiar wyniku jest duży, może się opłacać sprowadzić tabele do końcowego węzła i tam je złączyć.

11. Półzłączenia • W Londynie, dokonaj projekcji tabeli Sailors na kolumny złączenia i prześlij wynik do Paryża. • W Paryżu,dokonaj złączenia projekcji tabeli Sailors z tabelą Reserves. • Wynik nazywa się redukcją tabeli Reserves względem Sailors. • Prześlij redukcję tabeli Reserves do Londynu. • W Londynie,dokonaj złączenia Sailors z redukcją Reserves. • Idea:koszt przesłania całej tabeli Reserves zastępujemy kosztem obliczenia i przesłania kolejno projekcji i redukcji. • Szczególnie warte zastosowania gdy w zapytaniu występuje selekcja wartości z tabeli Sailors oraz gdy wyniki są wymagane w Londynie.

12. Optymalizacja rozproszonego zapytania • Metoda oparta na koszcie; rozważ wszystkie plany, wybierz najtańszy; podobnie jak w scentralizowanym przypadku. • Różnica 1: Koszty komunikacji między węzłami; decyzja którą replikę wybrać. • Różnica 2:Trzeba wziąć pod uwagę specyfikę węzła lokalnego (np. inny SZBD). • Różnica 3: Specyficzne metody rozproszonego złączenia.

13. Modyfikacja replik • Synchroniczna replikacja: Zanim modyfikująca transakcja zostanie zatwierdzona należy dokonać aktualizacji wszystkich replik (obejmuje zakładanie blokad, wymianę komunikatów w sieci). Przy odczytywaniu możemy skorzystać z dowolnej kopii. • Asynchroniczna replikacja: Kopie zmodyfikowanej tabeli są tylko okresowo aktualizowane – metoda znacznie tańsza; ale chwilowo różne kopie mogą nie być ze sobą zsynchronizowane.

14. Rozproszone odtwarzanie • Nowe problemy: • Dodatkowe rodzaje awarii, np. związane z połączeniami sieciowymi i odległymi węzłami. • Gdy “pod-transakcje” całej transakcji są wykonywane w różnych węzłach, wszystkie wykonują COMMIT albo żadna z nich. Potrzebny jest specjalnyprotokół zatwierdzania. • W każdym węźle jest utrzymywany odrębny dziennik (log) wykonywanych akcji, jak w scentralizowanej bazie danych. W tym dzienniku są odnotowywane akcje protokołu zatwierdzania.

15. Dwufazowe zatwierdzanie (2PC) • Węzeł inicjujący transakcję – koordynator. • Wykonanie instrukcji COMMIT: • Koordynator wysyła komunikat prepare. • Węzły zapisują w swoim dzienniku rekordabort lub preparea następnie wysyłają do koordynatora komunikat no lub yes. • Gdy koordynator uzyska jednomyślną odpowiedź yes, zapisuje do swojego dziennika rekord commit i wysyła komunikat commit. Wpp. zapisuje do swojego dziennika rekord abort i wysyła komunikat abort. • Węzły zapisują w swoim dzienniku odpowiedni rekordabort/commit i enda następnie wysyłają do koordynatora komunikat ack. • Po otrzymaniu wszystkich potwierdzeńack koordynator zapisuje do swojego dziennika rekordend.

16. Komentarz na temat 2PC • Dwie rundy komunikacji: pierwsza - głosowanie; druga - zakończenie. Obie inicjowane przez koordynatora. • Każdy węzeł może zadecydować o wycofaniu (abort) transakcji. • Każdy komunikat odzwierciedla decyzję nadawcy; aby mieć pewność odporności na awarie, decyzja jest najpierw zapisywana do dziennika transakcji (logu).

17. Implementacja rozproszonych baz danych w Oracle • Oracle dostarcza oprogramowania sieciowego Net8(SQL*Net) umożliwiającego komunikację między bazami danych Oracle oraz obsługę transakcji działających na więcej niż jednej bazie danych – w tym zatwierdzanie takich transakcji i ich wycofywanie.

18. Powiązanie z odległąbazą danych (database link) • Jest to zapisana w bazie danych ścieżka sieciowa do odległej bazy danych. • Składnia: • CREATE DATABASE LINKnazwa_powiązania • CONNECT TOużytkownik IDENTIFIED BYhasło • USING ’nazwa_usługi’; • gdzie • użytkownik/hasło – dotyczą konta, na które ma zostać dokonane logowanie w odległej bazie danych, jeśli ich brak – używana jest nazwa użytkownika i hasło z lokalnej bazy danych, • nazwa_usługi – nazwa usługi (aliasu bazy danych)Net8 (SQL*Net) zdefiniowanej w pliku konfiguracyjnym TNSNAMES.ORA .

19. Po utworzeniu powiązania z bazą danych, można korzystać z tabel i perspektyw w tej odległej bazie danych, tak jakby znajdowały się one w lokalnej bazie danych – dołączając do nazwy tabeli lub perspektywy napis @nazwa_powiązania. Na przykład instrukcja • CREATE DATABASE LINK baza • CONNECT TO scott IDENTIFIED BY tiger • USING 'mojabaza'; • tworzy powiązanie bazodanowe o nazwie baza z odległą bazą danych określoną przez sieciową usługę Oracle o nazwie mojabaza. • Przy wykonywaniu instrukcji • SELECT * • FROM Emp@baza; • lokalny serwer Oracle łączy się, używając oprogramowania Net8, z odległą bazą danych mojabaza. Oprogramowanie Net8 znajdujące się na docelowym komputerze przechwytuje zgłoszenie i dokonuje logowania w bazie mojabazana konto scott/tiger. Serwer wykonuje przesłaną instrukcję SELECT i przesyła przez sieć z powrotem wyniki zapytania, jednocześnie wylogowując użytkownika scott/tiger.

20. Przykłady Oracle potrafi wykonać dowolne instrukcje SQL, tak jakby tabele i perspektywy z odległych baz danych znajdowały się w lokalnej bazie danych np. SELECT * FROM Emp@warszawa UNION SELECT * FROM Emp@gdansk UNION SELECT * FROM Emp@katowice; UPDATE Emp@warszawa SET Salary = Salary * 1.1; Definiuje się zwykle synonimy dla obiektów w odległej bazie danych np. CREATE SYNONYM Klienci FOR Klienci@Baza_szkola;

21. Replikacja, migawka, perspektywa zmaterializowana • lokalna kopia (replikacja) danych znajdujących się w jednej lub więcej odległych bazach danych. Składnia (Oracle): CREATE SNAPSHOTnazwa_migawki REFRESH NEXTprzedział_czasu ASzapytanie; gdzie przedział_czasu określa co jaki czas należy odświeżać migawkę,zapytanie – określa zapytanie, które tworzy zawartość migawki. Zamiast słowa kluczowego SNAPSHOT można też używać słowa kluczowego MATERIALIZED VIEW.

22. Przykład • Instrukcja CREATE SNAPSHOT Wszyscy_prac REFRESH NEXT Sysdate +1 AS SELECT * FROM Emp@warszawa UNION AS SELECT * FROM Emp@gdansk; tworzy migawkę złożoną z danych o pracownikach pochodzących z dwóch oddziałów firmy w Warszawie i Gdańsku. Zawartość migawki będzie odświeżana raz na dzień. • Po zdefiniowaniu, migawki Wszyscy_prac można jej używać w zapytaniach, tak jakby to była zwykła tabela lub perspektywa. Np. SELECT * FROM Wszyscy_prac WHERE Job = 'MANAGER'; wypisuje informacje o wszystkich osobach pracujących w firmie na stanowisku MANAGER.

23. Implementacja migawki w lokalnej bazie danych • Tabela, do której jest zapisywany wynik zapytania (stąd nazwa perspektywa zmaterializowana), • indeks dla klucza głównego, • perspektywa służąca do wyświetlania i używania zawartości migawki.

24. Aktualizacja replik (odświeżanie migawek) • Migawka prosta – w instrukcji SELECT nie występują ani klauzule GROUP BY, CONNECT BY, DISTINCT ani funkcje sumaryczne ani operatory zbiorowe ani złączeniatabel. • Dla migawki prostej jest możliwe szybkie odświeżanie (opcja REFRESH FAST) pod warunkiem utworzenia w węźle, w którym znajduje się tabela nadrzędna tej migawki, specjalnego dziennika tej tabeli, do którego są wpisywane wszystkie zmiany dokonywane na tej tabeli. Następnie przy odświeżaniu migawki zamiast przesyłać całą zawartość tabelijest przesyłana tylko zawartość dziennika tej tabeli. Składnia: CREATE SNAPSHOT LOG ON Emp;

25. Modyfikowanie danych przez migawkę Migawka modyfikowalna (musi być prosta): CREATE SNAPSHOT Rep_emp REFRESH FAST NEXT sysdate +1 FOR UPDATE AS SELECT * FROM Emp@warszawa Można przez nią wprowadzać zmiany. UPDATE Rep_emp SET Sal = Sal*1.05 WHERE Ename = 'SCOTT';