1

Rozproszone bazy danych

Przygotował Lech Banachowski na podstawie: 1. Raghu Ramakrishnan, Johannes Gehrke, Database Management Systems,

McGrawHill, 2000 (książka i slide’y). 2. Lech Banachowski, Krzysztof Stencel, Systemy zarządzania bazami danych,

Wyd. PJWSTK3. Dokumentacja Oracle.

2

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.

Przy rozproszeniu użytkowników w sieci internetowej

3

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 (m.in. 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 (przez repliki).

Przy rozproszeniu użytkowników w sieci internetowej

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

Rozproszona baza danych

• Baza danych składająca się z kilku składowych baz

danych na ogół rozmieszczonych w odległych węzłach

sieci.

• Rozproszona baza danych w ścisłym znaczeniu ( w

rozumieniu Standardu SQL) – widoczna jako jedna

baza danych – implementacja w postaci zbioru baz

danych – nie widocznych dla użytkownikow.

• Dla końcowego użytkownika wygląda tak samo

jak zwykła, scentralizowana baza danych, tak samo

z każdego węzła sieci.

6

Skonfederowana rozproszona baza danych

• Konfederacja baz danych składa się z kilku składowych baz

danych na ogół rozmieszczonych w odległych węzłach sieci.

• Każda baza danych ma autonomię i realizuje swoje własne

zadania.

• Są określone wspólne zadanie, do których realizacji trzeba

użyć kilku baz danych w konfederacji.

• Łatwo jest dodać nową bazę danych do konfederacji.

7

Przykład bazy skonfederowanej

System kontroli opłat abonamentowych TVP. Komponenty to niezależne bazy danych:

– Urzędu Miasta

• dane meldunkowe obywateli

– sieci MediaMarkt

• dane o sprzedaży odbiorników RTV

– Urzędu Radiofonii i TV

• dane o płaconych abonamentach

8

Dodanie bazy integrującej zbiór odległych baz danych

Do istniejącego zbioru odległych baz danych dodaje się nową bazę danych, której celem jest ich integracja.

9

Problem integracji informacji

1. Powiązane dane istnieją w różnych miejscach i może zaistnieć potrzeba jednoczesnego ich użycia przez jedną aplikację.

2. Bazy danych mogą się różnić:

– modelem (np. relacyjny, obiektowo-relacyjny, hierarchiczny, XML, pliki MS Excel),

– schematem (np. znormalizowany, nieznormalizowany),

– terminologią (np. czy konsultanci firmy są pracownikami, czy emerytowani pracownicy są pracownikami),

– konwencjami (np. stopnie Celsjusza lub Fahrenheita; mile lub kilometry).

10

Hurtownia danych

Skopiuj dane źródłowe do centralnej bazy danych dokonując ich transformacji do wspólnego schematu. Tylko do odczytu.

11

Mediator Utwórz perspektywę wszystkich źródeł danych, tak jakby były zintegrowane. Albo tylko do odczytu albo odczyt i zapis z użyciem protokołu 2PC – mediator koordynatorem.

12

Założenia dla rozproszonej bazy danych

Dane są przechowywane w więcej niż w jednym węźle sieci – każdy z nich zarządzany przez osobną bazę danych.

Zasłonięcie 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.

13

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.

DBMS1 DBMS2 DBMS3

Gateway (Brama)

14

Przechowywanie danych

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.

TID

t1

t2

t3t4

R1

R1 R2

R3

Węzeł AWęzeł B

15

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.

16

Postulaty Date’a

1. Lokalna autonomia - Na każdym węźle działa niezależny system zarządzania bazą danych.

2. Uniezależnienie od centralnego węzła – Wszystkie węzły są równorzędne.

3. Działanie ciągłe – operacje na sieci węzłów nie powinny mieć wpływu na funkcjonowanie systemu (jak dodanie czy usunięcie węzła).

4. Niezależność lokalizacji - użytkownik nie powinien być świadomy fizycznego umiejscowienia danych.

5. Niezależność fragmentacji - użytkownik nie powinien być świadomy istnienia fragmentów i ich lokalizacji, dostęp do każdego fragmentu jest jednakowy i nie zależy od lokalizacji.

6. Niezależność replikacji - użytkownik nie powinien być świadomy istnienia replik, ich lokalizacji i czy korzysta z nich.

17

Postulaty Date’a – c.d.

7. Niezależność sprzętowa – na jakim komputerze znajduje się węzeł.

8. Niezależność od systemu operacyjnego – pod jakim systemem działa komputer węzła.

9. Niezależność od SZBD – jaki SZBD jest zainstalowany w węźle.

10. Niezależność od sieci – od architektur i protokołów sieciowych.

11. Rozproszone zarządzanie transakcjami – zaimplementowane aksjomaty ACID dla transakcji działających na całej sieci węzłów.

12. Rozproszone przetwarzanie zapytań – instrukcje SQL działają na danych rozmieszczonych w różnych węzłach sieci.

18

Zapytania rozproszone

Fragmentacja pozioma: Wiersze z Deptno < 50 w Krakowie, >= 50 w Warszawie.– Trzeba obliczyć w obu węzłach SUM(Sal), COUNT(Sal).– Gdyby był warunek Deptno>60, tylko w jednym węźle.

Fragmentacja pionowa: Sal wWarszawie, Deptno w Krakowie, Empno w obu.– W jednym węźle zrekonstruować tabelę i wykonać zapytanie. – Wykonać selekcję na Deptno w Krakowie, przesłać wyliczone

Empno i Sal do Wwy i tam wykonać obliczenia na Sal. Replikacja: Kopie Emp 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.

SELECT AVG(E.Sal)FROM Emp EWHERE E.Deptno > 30 AND E.Deptno < 70

19

Rozproszone złączenia

Załóżmy, że tabela Dept jest dostępna w Warszawie a  Emp jest dostępna w Krakowie.

SELECT E.Ename, D.Dname  FROM Emp E INNER JOIN Dept D ON E.Deptno=D.Deptno  WHERE E.Job='MANAGER' AND D.Loc='Warszawa'

– Sprowadź jedną tabelę do węzła gdzie jest druga tabela i tam wykonaj złączenie.

– Ewentualnie zastosuj najpierw selekcję i projekcję i tylko ich wynik prześlij do drugiego węzła.

– Gdy rozmiar wyniku jest duży, sprowadź obie tabele do końcowego węzła i tam je złącz.

20

Metoda półzłączeń (Semijoins) – minimalizacja przesyłania danych między węzłami

– W Warszawie, dokonaj projekcji tabeli Dept na

kolumny złączenia i prześlij wynik do Krakowa. Można

skorzystać z selekcji d.Loc='Warszawa' ograniczającej

zbiór wierszy.

– W Krakowie dokonaj złączenia projekcji tabeli Dept z

tabelą Emp korzystając z selekcji E.Job='MANAGER'

ograniczającej zbiór wierszy. Wynik nazywa się

redukcją tabeli Emp względem Dept. Prześlij redukcję

tabeli Emp do Warszawy.

– W Warszawie, dokonaj ostatecznego złączenia tabeli

Dept z redukcją tabeli Emp.

21

Ilustracja metody półzłączeń

Idea metody półzłączeń: koszt przesłania całej tabeli

zastępujemy kosztem obliczenia i przesłania kolejno

projekcji i redukcji.

22

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.

23

Odświeżanie 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. To samo zapytanie oparte na replikach może w różnych węzłach dać różne wyniki.

24

Modyfikacja danych przez repliki

Replika modyfikowalna to replika przez którą można dokonywać zmian w taleli oryginale wykonując instrukcje INSERT/DELETE/UPDATE.

Zasadniczym problemem jest, co robić w przypadku konfliktu, np. gdy w dwóch różnych węzłach dokonano różnych modyfikacji tego samego wiersza.

Dla replik może być zastosowany model optymistycznych blokad. Gdy oryginalny wiersz został w międzyczasie zmieniony i zmiany zostały zatwierdzone, aktualizacja wiersza w replice zostaje wycofana.

25

Kończenie rozproszonej transakcji

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, nie mogą same zatwiedzić swojej części transakcji; wszystkie wykonują COMMIT albo wszystkie wykonują ROLLBACK. Potrzebny jest specjalny protokół zatwierdzania (wykonywania COMMIT rozproszonej transakcji).

Przy realizacji COMMIT może się zatem pojawić ROLLBACK całej transakcji rozproszonej!

Również „rozproszony” ROLLBACK. 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.

26

Model rozproszonych obliczeń

27

Protokół dwufazowego zatwierdzania (2PC)

Węzeł inicjujący transakcję – koordynator. Wykonanie instrukcji COMMIT na sieci węzłów:

Koordynator wysyła komunikat prepare. Węzły zapisują w swoim dzienniku rekord abort lub prepare

a 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 rekord abort/commit i end a następnie wysyłają do koordynatora komunikat ack.

Po otrzymaniu wszystkich potwierdzeń ack koordynator zapisuje do swojego dziennika rekord end.

28

Komentarz na temat 2PC

Dwie rundy komunikacji: pierwsza - głosowanie; druga - koń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).

29

ROLLBACK w 2PC

– Koordynator przekazuje węzłom lokalnym polecenie abort do wykonania lokalnie. Po otrzymaniu potwierdzeń od wszystkich węzłów kończy transakcję.

30

Dwu-fazowe zatwierdzanie (2PC) z domyślnym wycofaniem

W przypadku podjęcia decyzji o wycofaniu zarówno koordynator (po wysłaniu komunikatu abort) jak i węzeł lokalny od razu dokonują wycofania transakcji.

– Brak transakcji w pamięci RAM oznacza, że została ona wycofana.

– Natomiast gdy koordynator podjął decyzję o zatwierdzeniu transakcji rozproszonej, utrzymuje o niej informacje dopóki nie uzyska potwierdzeń ack od wszystkich lokalnych węzłów.

31

Zdecentralizowany 2PC

– Koordynator wysyła komunikat prepare.

– Węzły zapisują w swoim dzienniku rekord abort lub prepare a następnie wysyłają do wszystkich węzłów komunikat no lub yes.

– Każdy węzeł (w tym koordynator) ma pełen obraz stanu transakcji rozproszonej. Gdy węzeł uzyska jednomyślną odpowiedź yes, zapisuje do swojego dziennika rekord commit. Wpp. zapisuje do swojego dziennika rekord abort. Węzeł już nie wysyła żadnej wiadomości ani do koordynatora ani do innych węzłów.

32

2PC w topologii drzewowej

– Koordynator znajduje się w korzeniu drzewa węzłów. Komunikacja między węzłami zachodzi po krawędziach drzewa.

– Koordynator rozsyła swoje komunikaty w dół drzewa. Każdy węzeł przekazuje komunikat koordynatora do swoich następników w drzewie.

– Najpierw swoją decyzję (yes lub no) podejmują i wysyłają węzły-liście.

– Każdy węzeł czeka na odpowiedź od swoich następników. Gdy je otrzyma, podejmuje zbiorczą decyzję (yes lub no) i przesyła ją do swojego poprzednika w drzewie.

33

Implementacja rozproszonych baz danych w Oracle

Oracle dostarcza oprogramowania sieciowego 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.

34

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 LINK nazwa_powiązania– CONNECT TO użytkownik IDENTIFIED BY hasł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) sieciowej Oracle zdefiniowanej w pliku konfiguracyjnym TNSNAMES.ORA .

35

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ę z odległą bazą danych mojabaza. Oprogramowanie sieciowe Oracle znajdujące się na docelowym komputerze przechwytuje zgłoszenie i dokonuje logowania w bazie mojabaza na 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.

36

Przykłady UPDATE Emp@warszawa

SET Salary = Salary * 1.1;

SELECT * FROM Emp@warszawaUNIONSELECT * FROM Emp@gdanskUNIONSELECT * FROM Emp@katowice;

Synonim

CREATE SYNONYM Klienci FOR Klienci@gdansk;

Perspektywa

CREATE VIEW Pracownicy(Ename, Sal) ASSELECT Ename, Sal FROM Emp@warszawa UNIONSELECT Ename, Sal FROM Emp@gdanskUNIONSELECT Ename, Sal FROM Emp@katowice;

37

Replika, migawka, perspektywa zmaterializowana

lokalna kopia (replika) danych znajdujących się w jednej lub więcej odległych bazach danych. Składnia (Oracle):

CREATE SNAPSHOT nazwa_migawkiREFRESH NEXT przedział_czasu AS zapytanie;

gdzie przedział_czasu określa co jaki czas należy odświeżać replikę, zapytanie – określa zapytanie, które tworzy zawartość repliki.

Zamiast słowa kluczowego SNAPSHOT można też używać słowa kluczowego MATERIALIZED VIEW.

38

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

Przykład

39

Implementacja migawki w lokalnej bazie danych

Tabela, do której jest zapisywany wynik zapytania (stąd nazwa perspektywa zmaterializowana),

perspektywa służąca do wyświetlania i używania zawartości migawki,

ewentualnie indeks dla klucza głównego.

40

Odświeżanie replik (migawek)

Migawka prosta – w instrukcji SELECT nie występują ani klauzule GROUP BY, CONNECT BY, DISTINCT ani funkcje sumaryczne ani operatory zbiorowe ani złączenia tabel.

Dla migawki prostej jest możliwe szybkie (przyrostowe) 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ść tabeli są przesyłane tylko nowe pozycje dziennika wpisane od ostatniego odświeżania.

Składnia: CREATE SNAPSHOT LOG ON Emp;

41

Modyfikowanie danych przez migawkę

CREATE SNAPSHOT Rep_emp REFRESH FAST NEXT sysdate +1FOR UPDATEAS SELECT * FROM Emp@warszawa

UPDATE Rep_empSET Sal = Sal*1.05WHERE Ename = 'SCOTT';

Migawka modyfikowalna (musi być prosta):

Można przez nią wprowadzać zmiany.