Rozproszone bazy danych

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. PJWSTK
3.
Dokumentacja Oracle.
1
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.
2
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 (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).
3
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.
4
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.
5
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.
6
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
7
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.
8
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).
9
Hurtownia
danych
Skopiuj dane źródłowe do centralnej bazy
danych dokonując ich transformacji do
wspólnego schematu. Tylko do odczytu.
10
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.
11
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.

12
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
13
Przechowywanie
danych
TID
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
14
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.
15
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.
16
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.
17
Zapytania rozproszone

SELECT AVG(E.Sal)
FROM Emp E
WHERE E.Deptno > 30
AND E.Deptno < 70
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.
18
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.
19
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.
20
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.
21
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.
22
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.

23
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.
24
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.
25
Model rozproszonych obliczeń
26
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.
27
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).

28
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ę.
29
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.
30
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.
31
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.
32
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.
33
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 .
34

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.
35
Przykłady
UPDATE
Emp@warszawa
SET Salary = Salary *
1.1;
SELECT * FROM Emp@warszawa
UNION
SELECT * FROM Emp@gdansk
UNION
SELECT * FROM Emp@katowice;
Perspektywa
CREATE
SELECT
UNION
SELECT
UNION
SELECT
VIEW Pracownicy(Ename, Sal) AS
Ename, Sal FROM Emp@warszawa
Ename, Sal FROM Emp@gdansk
Ename, Sal FROM Emp@katowice;
Synonim
CREATE SYNONYM Klienci
FOR Klienci@gdansk;
36
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_migawki
REFRESH 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.
37
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.
38
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.

39
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;
40
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';
41