Systemy baz 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, Bazy danych – projektowanie aplikacji na serwerze, EXIT,
2001.
1
Przy rozproszeniu użytkowników w sieci internetowej
v
v
v
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
v
v
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).
v
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).
3
Przykład
v
v
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.
v
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
Założenia
v
v
v
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.
5
Typy rozproszonych baz danych
v
v
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
6
Przechowywanie
danych
v
v
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
7
System zarządzania rozproszoną bazą danych
v
v
v
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.
8
Zapytania rozproszone
v
SELECT AVG(S.age)
FROM Sailors S
WHERE S.rating > 3
AND S.rating < 7
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.
v
Fragmentacja pionowa: sid i rating w Shanghai,
sname i age w Tokyo, tid w obu.
– Trzeba zrekonstruować tabelę i wykonać zapytanie.
v
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.
9
LONDYN
Rozproszone złączenia
Sailors
500 stron
v
PARYŻ
Reserves
1000 stron
Sprowadzaj strony gdy trzeba, metoda Page Nested Loops,
tabela Sailors zewnętrzna.
– Koszt: 500 D + 500 * 1000 (D+S).
– D – koszt odczytu/zapisu; S - koszt przesłania strony.
– Gdyby zapytanie nie było złożone w Londynie, trzeba by było
dodać koszt przesłania wyniku.
v
Sprowadź całą tabelę: Prześlij Reserves 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ć.
10
Półzłączenia
v
v
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.
v
v
v
v
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.
11
Optymalizacja rozproszonego
zapytania
v
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.
12
Modyfikacja replik
v
v
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.
13
Rozproszone odtwarzanie
v
v
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 specjalny protokół 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.
14
Dwufazowe zatwierdzanie (2PC)
v
v
Węzeł inicjujący transakcję – koordynator.
Wykonanie instrukcji COMMIT:
 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.
15
Komentarz na temat 2PC
v
v
v
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).
16
Implementacja rozproszonych baz
danych w Oracle
v
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.
17
Powiązanie z odległą bazą danych
(database link)
v
v
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’;
u gdzie
u 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,
u nazwa_usługi – nazwa usługi (aliasu bazy danych) Net8 (SQL*Net)
zdefiniowanej w pliku konfiguracyjnym TNSNAMES.ORA .
18
v
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
u
u
u
v
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
u SELECT *
u 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 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.
19
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;
20
Replikacja, migawka, perspektywa zmaterializowana
v
lokalna kopia (replikacja) 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ć
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.
21
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.
22
Implementacja migawki w lokalnej
bazie danych
v
v
v
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.
23
Aktualizacja replik (odświeżanie migawek)
v
v
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 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 jest przesyłana tylko zawartość dziennika tej tabeli. Składnia:
CREATE SNAPSHOT LOG ON Emp;
24
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';
25