Wykład 6 Rozproszone bazy danych

Transkrypt

Wykład 6
Rozproszone bazy danych
Definicja rozproszonych baz danych
System rozproszonej bazy danych składa się z zestawu miejsc lub węzłów
połączonych za pomocą sieci łączności takich, że w każdym węźle ulokowany jest
samodzielny system bazy danych.
Systemy te pracują razem, więc użytkownik w dowolnym miejscu sieci może
mieć dostęp do danych dokładnie taki, jakby wszystkie dane były przechowywane w
jego własnym węźle
Podstawowy problem
Minimalizowanie wykorzystania sieci - minimalizacja liczby i wielkości
przesyłanych komunikatów
Miasto A
Miasto B
Lokalny
DBMS+
warstwa
rozproszona
=DDBMS
Lokalny
DBMS+
warstwa
rozproszona
=DDBMS
Sieć
komunikacyjna
Lokalny
DBMS+
warstwa
rozproszona
=DDBMS
Lokalny
DBMS+
warstwa
rozproszona
=DDBMS
Miasto C
Miasto D
Zalety
Dr inż. Zofia Kruczkiewicz
1
Internetowe bazy danych, Wykład 6
1. Przechowywanie danych blisko miejsca, w których są potrzebne
2. Umożliwienie dostępu do danych w innym mieście
3. Odzwierciedlenie struktury przedsiębiorstwa
Wady
Złożoność
Podstawowa zasada
Dla użytkownika system rozproszony powinien wyglądać dokładnie tak samo,
jak zwykły system
Przykłady:
ORACLE, Microsoft 2000 Server
Cele tworzenia rozproszonej bazy danych
1. Lokalna autonomia
2. Brak uzależnienia od centralnego miejsca
3. Działanie ciągłe
4. Niezależność od lokalizacji
5. Niezależność od fragmentacji
6. Niezależność od replikacji
7. Rozproszone przetwarzanie zapytania
8. Rozproszone zarządzanie transakcjami
9. Niezależność sprzętowa
'
10. Niezależność od systemu operacyjnego
11. Niezależność od sieci
12. Niezależność od DBMS
2
1. Lokalna autonomia
(C.J.DATE, Wprowadzenie do systemów baz danych, rozdział 21)
Węzły w systemie rozproszonym powinny być autonomiczne.
Autonomia lokalna oznacza, że wszystkie operacje dokonywane w danym miejscu są
kontrolowane z tego miejsca. Pomyślne działanie jakiegoś węzła X nie powinno zależeć od
jakiegoś innego węzła Y. (W przeciwnym razie zamknięcie węzła Y z powodu awarii mogłoby
spowodować wstrzymanie działania węzła X, chociaż miejsce to by było w zupełnym
porządku. Byłaby to oczywiście niepożądana sytuacja).
Autonomia lokalna oznacza także, że dane lokalne są zarządzane lokalnie, ich właściciel
jest lokalny i lokalnie można je przetworzyć: Wszystkie dane „naprawdę" należą do pewnej
lokalnej bazy danych, nawet jeżeli jest ona dostępna z innych, odległych miejsc. Sprawy takie
jak bezpieczeństwo, integralność oraz reprezentacja w pamięci trwałej danych lokalnych
pozostają pod kontrolą lokalnego węzła.
Tak naprawdę nie da się w pełni osiągnąć lokalnej autonomii. Są liczne sytuacje, w których
dane miejsce X musi przekazać pewną część kontroli innemu miejscu Y.
Można więc sformułować cel autonomii następująco:
Węzły powinny być maksymalnie autonomiczne.
2. Brak uzależnienia od centralnego węzła
Z lokalnej autonomii wynika, że wszystkie miejsca muszą być traktowane równo. Nie może
być zatem żadnego uzależnienia od centralnego, „głównego" miejsca, realizującego centralne
usługi — np. scentralizowane przetwarzanie żądań, centralne zarządzanie transakcjami czy
centralne nadawanie nazw — takiego, by cały system zależał od niego.
Drugi cel jest więc wnioskiem wynikającym z pierwszego (jeżeli pierwszy będzie osiągnięty,
to drugi z tego wyniknie). „Brak uzależnienia od centralnego węzła" jest pożądany również sam
w sobie, nawet jeśli nie uda się zrealizować pełnej lokalnej autonomii. Warto zatem przedstawić
to jako osobny cel.
Uzależnienie od centralnego węzła jest niepożądane z przynajmniej dwóch
względów:
• Centralne miejsce mogłoby stanowić wąskie gardło całej bazy;
• jest to ważniejszy powód, system byłby osłabiony — gdyby centralne miejsce uległo awarii,
wówczas cały system przestałby działać.
3
3. Działanie ciągłe
Systemy rozproszone mają na ogół tę zaletę, że powinny dawać zwiększoną niezawodność i
zwiększoną dostępność:
• Niezawodność (którą można zdefiniować jako prawdopodobieństwo tego, że system działa
pomyślnie w dowolnej chwili) jest lepsza, ponieważ systemy rozproszone nie są systemami
typu „wszystko albo nic". Mogą one działać (w ograniczonym zakresie), nawet jeśli jakiś
pojedynczy składnik (miejsce) ulegnie awarii.
• Dostępność (którą można zdefiniować jako prawdopodobieństwo tego, że system działa
pomyślnie w sposób ciągły przez określony czas) jest także lepsza, częściowo z tego
samego powodu, a częściowo dlatego, że istnieje możliwość replikacji danych.
Powyższe rozważania odnoszą się do przypadku, kiedy w pewnej chwili następuje
nieplanowane zamknięcie systemu (shutdown), tj. jakiś błąd. Oczywiście nieplanowane
zamknięcia są niepożądane, ale trudne do uniknięcia.
Z kolei nie powinno się nigdy wymagać zamknięć planowych, ponieważ idealnie by było,
gdyby system nigdy nie wymagał zamykania w celu przeprowadzenia pewnych czynności,
takich jak dodawanie nowego miejsca czy aktualizacja oprogramowania DBMS.
4. Niezależność od lokalizacji
Zasadnicza idea niezależności od lokalizacji (znanej też jako przezroczystość
lokalizacji) jest prosta. Użytkownicy nie powinni wiedzieć, gdzie dane są przechowywane
fizycznie, natomiast powinni móc zachowywać się tak — przynajmniej z punktu widzenia
logiki — jakby wszystkie dane były przechowywane na ich lokalnym stanowisku.
Niezależność od lokalizacji jest pożądana, ponieważ:
• upraszcza ona czynności programów użytkownika i prace z terminalem.
• w szczególności, umożliwia migrację danych z miejsca na miejsce, nie naruszając tych
programów ani czynności terminalowych. Przenoszalność taka jest pożądana, ponieważ
umożliwia przesyłanie danych w sieci w odpowiedzi na zmieniające się wymagania
wydajności.
Uwaga: Niezależność od lokalizacji jest rozszerzeniem znanego pojęcia (fizycznej)
niezależności danych na przypadek rozproszonej bazy. W istocie każdy cel na naszej liście,
który ma w nazwie „niezależność" można uważać za rozszerzenie pojęcia niezależności
danych.
Zarządzanie katalogiem
Katalog systemowy musi zawierać informacje wspierające niezależność od lokalizacji:
1. relacje bazowe
2. perspektywy
3. indeksy
4. użytkowników
5. informacja kontrolna obsługująca niezależność od lokalizacji, fragmentacji, replikacji
4
Sposób przechowywanie katalogu - przykład rozwiązania umożliwiającego spełnianie
podstawowych zadań przez katalog systemu rozproszonego.
Tworzenie nazw systemowych jest głównym mechanizmem katalogu
• ID twórcy (identyfikator użytkownika, który utworzył dany obiekt (tabelę))
• ID miejsca twórcy (identyfikator stanowiska, w którym wydano instrukcję CREATE)
• Nazwa lokalna (niekwalifikowana nazwa obiektu)
• ID miejsca urodzenia (identyfikator miejsca, w którym po raz pierwszy zachowano
obiekt).
Np. KOWALSKI @ NEWYORK . STATS @ LONDON – oznacza użytkownika Kowalski
z Nowego Jorku , który założył tabelę STATS, przechowywaną początkowo w Londynie.
Można utworzyć synonim do danej nazwy systemowej:
CREATE SYNONIM MSTATS FOR KOWALSKI @ NEWYORK . STATS @
LONDON
Odtąd użytkownik może stosować składnię:
SELECT ... FROM STATS
lub
SELECT ... FROM MSTATS
Składniki katalogu w każdym węźle sieci:
• Tabele synonimów: umożliwiają odwzorowanie synonimu w nazwę globalną.
• Pozycję w katalogu odpowiadającą każdemu obiektowi urodzonemu w tym miejscu
• Pozycję w katalogu odpowiadającą każdemu obiektowi aktualnie przechowywanemu w
tym miejscu lub informację o aktualnej lokalizacji obiektu
Przykład posługiwania się katalogiem
Wyszukiwanie katalogu (1-6) lub migracja katalogu (1-9)
1) Przeglądana jest tabela synonimów i zostaje znaleziona nazwa globalna
2) Na podstawie nazwy globalnej dowiaduje się, że miejscem urodzenia jest Londyn
3) Na podstawie tej informacji zdalnie zostaje przeszukany katalog w Londynie, który
zawiera tę pozycję związaną z obiektem STATS.
4) Jeżeli ten obiekt jest dalej w Londynie, zostaje już znaleziony (2)
5) W przeciwnym wypadku pozycja ta zwiera informację o aktualnym położeniu np. Los
Angeles (2)
6) Po zdalnym wyszukaniu w katalogu Los Angeles obiekt zostaje odnaleziony (2)
7) W celu przeniesienia obiektu do San Francisco, do katalogu tego węzła zostaje dodana
nowa pozycja (2)
8) usuwa się z katalogu w Los Angeles daną pozycję (2)
9) w Londynie zmienia się zapis (2) o aktualnym położeniu (San Francisco zamiast Los
Angeles)
5
5. Niezależność od fragmentacji
(wg C.J.DATE, Wprowadzenie do systemów baz danych, rozdział 21)
System umożliwia fragmentację danych, jeżeli można podzielić daną relację pamiętaną na
kawałki czy „fragmenty", w celu przechowywania w pamięci fizycznej.
Fragmentacja jest wskazana ze względu na wydajność: Można przechowywać dane w tych
miejscach, w których są one najczęściej używane. Dzięki temu większość operacji będzie
lokalnych, a ruch w sieci spadnie.
Wyróżniamy dwa rodzaje fragmentacji: poziomą i pionową.
Może to być dowolna podrelacja, dająca się uzyskać z wyjściowej relacji poprzez operacje
restrykcji i rzutu. Musi ona spełniać następujące warunki:
• Wszystkie fragmenty danej relacji są rozłączne, w tym sensie, że nie da się wyprowadzić
żadnego fragmentu z innych fragmentów ani nie ma restrykcji czy rzutów wyprowadzalnych z
innych fragmentów.
• W przypadku rzutu muszą one być bezstratne.
• Odtwarzanie oryginalnej relacji z fragmentów odbywa się za pomocą odpowiednich operacji
złączenia i sumy (z łączenia dla fragmentów pionowych, sumy dla fragmentów poziomych)
Podział poziomy- restrykcja
Rozważmy na przykład relację EMP. W systemie wspierającym fragmentację można by
zdefiniować dwa następujące fragmenty:
Widok Użytkownika
EMP
EMP #
El
E2
E3
E4
E5
Nowy Jork
N_EMP
EMP DEPT
#
#
El
Dl
E2
Dl
E5
D3
SALAR
Y
40K
42K
48K
DEPT#
Dl
D1
D1
D2
D2
D3
SALARY
40k
42k
30k
35k
48k
48k
Londyn
L_EMP
EMP* DEPT* SALARY
E3
D2
30 K
E4
D2
45 K
FRAGMENT EMP INTO
N_EMP AT SITE 'New York' WHERE DEPT# = 'Dl' OR DEPT# = 'D3',
L_EM P AT SITE ' London'
WHERE DEPT # = ' D2 ' ;
Uwaga: Zakładamy, że:
(a) krotki pracowników odwzorowują się bezpośrednio na pamięć fizyczną,
(b) Dl i D3 są oddziałami w Nowym Jorku, D2 zaś jest oddziałem w Londynie.
Innymi słowy, krotki pracowników z Nowego Jorku będą przechowywane w komputerze w
Nowym Jorku (N_EMP), natomiast krotki pracowników londyńskich (L_EMP) — w Londynie.
6
Przykład zapytania w systemie rozproszonym:
EMP WHERE SALARY >40k AND DEPTH# = ‘D1’
Uwzględniając fragmentację poziomą mamy:
EMP = N_EMP UNION L_EMP
(N_EMP UNION L_EMP) WHERE SALARY >40k AND DEPTH# = ‘D1’
czyli
(N_EMP WHERE SALARY >40k AND DEPTH# = ‘D1’)
UNION
(L_EMP WHERE SALARY >40k AND DEPTH# = ‘D1’)
Całe wyrażenie jest równe
N_EMP WHERE SALARY >40k AND DEPTH# = ‘D1’
Podział pionowy - rzutowanie
Widok Użytkownika
EMP
EMP #
El
E2
E3
E4
E5
DEPT#
D1
D1
D2
D2
D3
SALARY
40k
42k
35k
30k
48k
Nowy Jork
N_EMP
EMP DEPT Adre
#
#
El
Dl
1s
E2
Dl
2
E3
D2
3
E4
D2
4
E5
D3
5
Adres
1
2
3
4
5
Londyn
L_EMP
SALAR Adres
Y
40k
1
42k
2
35k
3
30K
4
48K
5
FRAGMENT EMP INTO
N_EMP AT SITE ‘NewYork’ [EMP#, DEPT#, Adres]
L_EMP AT SITE ‘London’ [SALARY, Adres]
Przykład zapytania w systemie rozproszonym:
EMP WHERE SALARY >40k AND DEPTH# = ‘D1’
7
Uwzgledniając fragmentację pionową mamy:
EMP = N_EMP JOIN L_EMP
(N_EMP JOIN L_EMP) WHERE SALARY >40k AND DEPTH# = ‘D1’
czyli
(N_EMP WHERE DEPTH# = ‘D1’)
JOIN
(L_EMP WHERE SALARY >40k )
6. Niezależność od replikacji
System umożliwia replikację danych, jeżeli dana zapamiętana relacja — lub
ogólniej fragment — może być reprezentowana w wielu różnych kopiach, inaczej replikach,
przechowywanych w wielu różnych miejscach. Na przykład:
REPLICATE N_EMP
LN_EMP AT SITE ' London' ;
REPLICATE L_EMP
NL_EMP AT SITE 'New York' ;
Zwróćmy uwagę na wewnętrzne nazwy systemowe NL_EMP, LN_EMP.
Replikacja jest wskazana z przynajmniej dwóch powodów:
• może oznaczać lepszą wydajność (aplikacje mogą operować na lokalnych kopiach zamiast
sięgać do odległych miejsc).
• może także oznaczać lepszą dostępność (dany powielony obiekt jest dostępny tak długo,
jak pozostaje dostępna choćby jedna kopia, przynajmniej do celów wyszukiwania danych).
Zasadniczą wadą replikacji jest oczywiście to, że kiedy aktualizuje się dany obiekt, to trzeba
aktualizować wszystkie kopie tego obiektu. Jest to problem przekazywania (propagacji) aktualizacji.
Nowy Jork
N_EMP
EMP DEPT
#
#
El
Dl
E2
Dl
E5
D3
Londyn
L_EMP
EMP DEPT
#
#
E3
D2
E4
D2
SALAR
Y
40K
42K
48K
SALAR
Y
30K
45K
Kopia
EMP*
E3
E4
L_EMP
DEPT* SALARY
D2
30 K
D2
45 K
Kopia
EMP*
E1
E2
E5
N_EMP
DEPT*
D1
D1
D3
8
SALARY
40K
42K
48K
Replikacja w systemach rozproszonych jest specyficznym zastosowaniem idei
kontrolowanej redundancji (nadmiarowości)
Podobnie jak fragmentacja, replikacja najlepiej powinna być „przeźroczysta" dla
użytkownika. Innymi słowy, system wspierający replikację danych powinien także wspierać
niezależność od replikacji (znaną także jako przezroczystość replikacji). Oznacza to, że
użytkownicy powinni móc tak działać, jakby dane nie były wcale powielone, przynajmniej z
logicznego punktu widzenia. Niezależność od replikacji (podobnie jak niezależność od
lokalizacji czy fragmentacji) jest pożądana, ponieważ upraszcza programy użytkownika i pracę
przy terminalu. W szczególności umożliwia ona tworzenie i usuwanie replik danych w
dowolnym momencie zależnie od zmian wymagań co do wydajności, bez naruszania tych
programów użytkownika czy innych czynności.
Niezależność od replikacji prowadzi do wniosku, że to optymalizator systemowy odpowiada
za określenie, które repliki powinny być fizycznie dostępne, aby spełnić dane żądanie
użytkownika. Szczegóły związane z tą kwestią pomijamy.
Na zakończenie zwracamy uwagę na to, że wiele produktów komercyjnych wspiera obecnie
replikację w takiej postaci, że nie daje ona pełnej niezależności (tj. nie jest całkowicie
„przeźroczysta dla użytkownika").
Przekazywanie aktualizacji
Sposób postępowania z kopią pierwotną
• jedną kopię powielonego obiektu oznacza się jako kopię pierwotną
• kopie pierwotne różnych obiektów trzyma się trzyma się w różnych miejscach (schemat
rozproszony)
• uważa się, że operacja zakończyła się z logicznego punktu widzenia, gdy zakończyła się
aktualizacja kopii pierwotnej. Miejsce przechowujące kopię pierwotną odpowiada za
późniejsze przekazywanie aktualizacji do kopii wtórnych. Musi to jednak nastąpić przed
zatwierdzeniem transakcji, jeśli chcemy zachować własności ACID tej transakcji.
• Problemy te omówiono w p. 8.
9
7. Rozproszone przetwarzanie zapytania (C.J.DATE, Wprowadzenie do systemów baz danych, rozdział 21)
• Rozważmy zapytanie „Znajdź dostawców mających siedzibę w Londynie i
dostarczających czerwone części". Przyjmijmy, że warunki te spełnia n dostawców.
Załóżmy, że użytkownik znajduje się w Nowym Yorku, a dane są przechowywane w
Londynie. W przypadku systemu relacyjnego zapytanie spowoduje przesłanie dwóch
komunikatów - jeden to wysłanie zapytania z Nowego Jorku do Londynu, a drugi to
przekazanie zbioru wynikowego n krotek z Londynu do Nowego Jorku. Gdyby system nie
był relacyjny, a tylko przetwarzał rekord po rekordzie, wówczas zapytanie wymagałoby
przesłania 2n komunikatów: n razy z Nowego Jorku do Londynu żądających następnego
dostawcy i n komunikatów z Londynu do Nowego Jorku, zwracających tych dostawców.
Przykład pokazuje, że systemy relacyjne zapewne będą miały nawet o rzędy wielkości lepszą
wydajność niż nierelacyjne (przynajmniej, jeśli chodzi o żądania na poziomie zbiorów).
• W systemach
rozproszonych
optymalizacja
jest
jeszcze
ważniejsza
niż w
scentralizowanych. Główna sprawa wiąże się z ruchem w sieci – należy dążyć do
wysyłania jak najmniejszej liczby komunikatów i o możliwie najmniejszych
rozmiarach. W zapytaniu takim jak powyższe, może być wiele wariantów przesyłania
danych zmierzających do realizacji żądania, zatem bardzo ważne jest znalezienie właściwej
strategii. Żądanie na przykład wykonania sumy relacji Rx przechowywanej w miejscu X i
relacji Ry przechowywanej w miejscu Y można zrealizować, przesyłając Rx do Y lub Ry do
X bądź też wysyłając obie relacje do trzeciego miejsca Z (itp.). Wymowny przykład
ilustrujący to zagadnienie, oparty na wspomnianym zapytaniu („Podaj dostawców mających
siedzibę w Londynie i dostarczających czerwone części") znajduje się dalej. Przytaczamy
tutaj tylko najważniejsze rezultaty. Analizowanych będzie sześć różnych, rozsądnych strategii
przetwarzania zapytania. Pokażemy, że czas odpowiedzi zmienia się od jednej dziesiątej
sekundy do ok. sześciu godzin. Optymalizacja jest więc bardzo istotna. Dlatego właśnie
systemy rozproszone są zawsze relacyjne — żądania sformułowane na poziomie zbiorów
można zawsze optymalizować, natomiast na poziomie rekordów nie można.
Przykład
Nowy Jork
S(S#, Miasto) = 10 000 krotek
SP (S#, P#) = 1 000 000 krotek
Londyn
P (P#, Kolor) = 100 000 krotek
Zapytanie:
S.S# WHERE EXISTS SP EXISTS P ( S.CITY = ‘Londyn’
AND S.S# = SP.S#
AND SP.P# = P.P#
AND P.Kolor = ‘Czerwony’);
a) liczba czerwonych części - 10
b) liczba dostaw realizowanych przez dostawców z Londynu – 100 000
c) szybkość transmisji = 50 000 bitów na sekundę
d) czas dostępu = 0.1 s
e) rozmiar krotki w każdej z tabel – 200 bitów
10 Internetowe bazy danych, Wykład 6
Strategia Opis
1.
2.
3.
4.
5.
6.
Czas
Wyni
k
Prześlij tabelę P (100000) do Nowego 0.1(P)+100 000*200/50000 6 min
=400 sekund
40 sek
Jorku i wykonaj tam pytanie
Prześlij tabele S (10000 krotek) i SP
(1000000 krotek) do Londynu i wykonaj
tam zapytanie
Dla każdej dostawy z Londynu sprawdź,
czy część jest czerwona (złączenie tabel S i
SP (SSP) i restrykcja wyniku do dostawców
z
Londynu
w
Nowym
Jorku
(SSP.MIASTO=’Londyn’),
następnie
wysyłanie po jednej krotce (z 100000 krotek)
do Londynu, sprawdzenie, czy jest czerwona:
SSP.P#=P.P# AND P.Kolor=’Czerwony’, i
wysłanie odpowiedzi do Nowego Jorku)
Dla każdej części czerwonej, sprawdź czy
istnieje dostawca z Londynu (restrykcja w
tabeli P: P.Kolor=’Czewony’ w Londynie wg
czerwonego koloru części, przesłanie każdej
krotki (z 10 krotek) osobno do Nowego
Jorku, sprawdzanie dla nich dostawcy i
wysłanie potwierdzenia dla każdej z nich do
Londynu)
Prześlij dostawy z Londynu do Nowego
Jorku (wykonanie złączenia tabel S i SP
(SSP) w Nowym Jorku, następnie wykonanie
restrykcji wg dostawców z Londynu
(SSP.Miasto=’Londyn’), wyrzutowanie wg
atrybutów [S#P#] i przeniesienie całego
wyniku do Londynu (100000 krotek) i tam
zakończenie zapytania)
Prześlij czerwone części do Nowego Jorku
i tam sprawdź dostawcę (restrykcja tabeli P
wg czerwonych części w Londynie:
P.Kolor=’Czerwony’ i następnie przesłanie
całego wyniku (10 krotek) do Nowego Jorku
i tam dokończenie zapytania)
0.1(S)+0.1(SP)+
(10000+1000000)
*200/50000= 4040 sekund
0.1*100000+0.1*100000+
2*100000*200/50000=
20800 sekund
1h
7 min
20 sek
5 ha
46
min
40 sek
0.1*10+0.1*10 +
2*10*200/50000=2.08 sek
2.08
sek
0.1 + 100000*200/50000=
400.1sek
6 min
40.1
sek
0.1+10*200/50000=0.14
sek
0.14
sek
8. Rozproszone zarządzanie transakcjami (wg C.J.DATE, Wprowadzenie do systemów baz danych, rozdział 21)
8.1. Transakcje – podstawowe wiadomości
Transakcja jest logiczną jednostką pracy oraz logiczna jednostką odtwarzania danych w
przypadku niepomyślnego przebiegu transakcji. Podczas transakcji wszystkie tabele biorące
udział w transakcji są zablokowane (niedostępne dla innych operacji na bazie danych).
Przykład
public void wstaw_tytul(Tytul t) throws Exception
{ polaczenie.setAutoCommit(false);
//wyłączenie zewnętrznego zarządzania
try
//odtwarzaniem danych
{ Statement polecenie = polaczenie.createStatement();
String sql="INSERT INTO Tytul (tytul, autor, ISBN)"+
" VALUES ('"+t.tytul+"','"+ t.autor+"','"+ t.ISBN+"')";
polecenie.addBatch(sql);
polecenie.executeBatch();
polaczenie.commit();
//pomyślne zakończenie transakcji
} catch(BatchUpdateException e)
{ System.out.println("Wycofanie transakcji");
polaczenie.rollback(); }
//niepomyślne zakończenie transakcji
}
Podstawowe operacje menedżera transakcji:
• Operacja commit (commit transaction – sygnalizuje pomyślne zakończenie transakcji.
Informuje ona menedżera transakcji, że logiczna jednostka pracy zakończyła się pomyślnie,
baza danych jest w stanie uzgodnienia i wszystkie dokonane aktualizacje przez tę jednostkę
pracy mogą być teraz „zatwierdzone”, czyli utrwalone.)
• Operacja rollback (rollback transaction – sygnalizuje niepomyślne zakończenie
transakcji. Informuje ona menedżera transakcji, że baza danych może być w stanie
nieuzgodnionym, a wszystkie aktualizacje dokonane przez logiczną jednostkę pracy muszą
być cofnięte.)
• Dziennik transakcji, w którym są odnotowywane szczegóły wszystkich operacji
aktualizacji. W praktyce dziennik składa się z części aktywnej („online”) oraz archiwum
(„offline”). Część aktywna jest używana w czasie normalnego działania systemu- kiedy staje
się pełna, jest przenoszona do archiwum.
Aktualizacje bazy danych:
• Instrukcja commit ustala m.in. punkt zatwierdzania – czyli punkt synchronizacji
(syncpoint), kiedy baza danych jest w stanie spójnym. Po ustaleniu punktu zatwierdzenia
wszystkie aktualizacje są zachowane (dotąd były tymczasowe) i już nie mogą być cofnięte
• Instrukcja rollback przesuwa bazę danych z powrotem do stanu, w jakim była przez
rozpoczęciem transakcji, czyli następuje powrót do poprzedniego stanu zatwierdzenia
• Zarówno po zakończeniu transakcji instrukcją commit lub rollback całe pozycjonowanie bazy
danych jest tracone i wszystkie blokady na krotkach są zwolnione. Pozycjonowanie bazy
danych oznacza, że system zna adresy pewnych krotek.
• Instrukcje rollback lub commit kończą transakcję, lecz nie kończą programu.
Własności transakcji - ACID:
A- niepodzielność (atomici) – transakcje są niepodzielne (wszystko albo nic) tzn. nie może być
sytuacji, gdy na skutek błędu wykonania transakcji tylko część krotek jest zmienionawówczas baza musi powrócić do stanu przed wykonaniem transakcji
B- spójność (consistency) – przekształcenia zachowują spójność bazy danych
C- izolacja (isolation) – transakcje są odizolowane jedna od drugiej: dla dowolnych dwóch
różnych transakcji T1 i T1 można dopuścić, by transakcja T1 widziała aktualizacje dokonane
przez transakcje T2 po jej zatwierdzenie lub T2 widziała zmiany T1 po jej zakończeniu.
Jednak te dwie sytuacje nie mogą wystąpić jednocześnie.
D- trwałość (durability) – po pomyślnym zakończeniu transakcji zmiany prze nią dokonane
powinny być zachowane nawet jeśli nastąpi awaria systemu.
Odtwarzanie systemu
• z powodu awarii systemowych (awaria zasilania – miękkie awarie)
• z powodu błędów nośników (uszkodzenie dysku – twarde awarie)
Kategorie transakcji
Czas
tc
tf
T1
T2
T3
T4
T5
Transakcje
Punkt kontrolny
Awaria systemu
Co pewien określony czas system ustala punkt kontrolny i zapisuje rekord kontrolny,
zawierający spis wszystkich transakcji będących w toku, do dziennika transakcji:
• W czasie tf wystąpiła awaria systemu, natomiast aktualnym punktem kontrolnym jest tc
• T1 zakończyła się pomyślnie przed tc – nie musi być powtórzona, ponieważ zostały
dokonane fizycznie wszystkie skutki transakcji.
• T2 rozpoczęła się przed tc i zakończyła się pomyślnie po chwili tc i przed tf oraz T4
rozpoczęła się po tc i zakończyła się przed tf – należy powtórzyć obie transakcje
• T3 rozpoczęła się przed tc, ale nie zakończyła się przed tf oraz T5 rozpoczęła się po tc i nie
zakończyła się przed tf - należy wycofać skutki działania transakcji T3 i T5.
• W momencie restartu systemu transakcje T2 i T4 należy powtórzyć
Procedura wykonywana w momencie restartu:
• Utwórz dwie listy transakcji UNDO (lista uzyskana z rekordu kontrolnego) i REDO (pusta)
• Rozpocznij przeszukiwanie do „przodu” dziennika transakcji począwszy od rekordu
kontrolnego
• Jeżeli napotkasz na pozycje begin transaction T, wpisz pozycje do listy UNDO
• Jeżeli napotkasz na pozycję commit dla transakcji T, przesuń ją z listy UNDO do listy REDO
• Kiedy napotkasz na znak końca dziennika, wtedy listy UNDO i REDO wskazują
odpowiednio transakcje typu T3 i T5 oraz transakcje typu T2 i T4.
Algorytm zatwierdzania dwufazowego
Algorytm zatwierdzania dwufazowego jest ważny wszędzie tam, gdzie dana transakcja może
oddziaływać z kilkoma niezależnymi „menadżerami zasobów” (jednoczesne aktualizowanie
kilku baz danych), z których każdy utrzymuje niezależny dziennik odzyskiwania danych.
Koordynator systemu:
• Najpierw zawiadamia wszystkich „menedżerów zasobów”, by przygotowali się na „obie
ewentualności” zakończenia transakcji. W praktyce znaczy to, że każdy menedżer zasobów
musi wypisać wszystkie pozycje z dziennika transakcji, odpowiadające lokalnym zasobom
używanym w tej transakcji, do swego własnego fizycznego dziennika transakcji. Jeśli
wypisywanie to zakończyło się pomyślnie, każdy z „menedżerów zasobów” potwierdza
koordynatorowi pomyślne lub niepomyślne zakończenie transakcji.
• Po otrzymaniu odpowiedzi od wszystkich uczestników koordynator wpisuje odpowiedni
zapis do swego własnego dziennika transakcji odpowiedzi od poszczególnych „menedżerów
zasobów”. Jeśli jakakolwiek odpowiedź była negatywna, koordynator każe wszystkim
menedżerom zasobów biorących udział w transakcji wycofać się z niej odtwarzając poprzedni
stan bazy. W przeciwnym wypadku umożliwia zatwierdzenie nowego stanu bazy danych po
pomyślnie przeprowadzonej transakcji.
8.2. Zarządzanie transakcjami w systemach rozproszonych
Zarządzanie transakcjami ma dwa ważne aspekty, kontrolę odtwarzania i kontrolę
współbieżności. Każdy z nich wymaga specjalnego podejścia w środowisku rozproszonym. Żeby
wyjaśnić, na czym ono polega, wprowadzimy najpierw nowe pojęcie - „agent". W systemie
rozproszonym pojedyncza transakcja może obejmować wykonywanie programu w wielu miejscach
jednocześnie, w szczególności aktualizacja może zachodzić w wielu miejscach. Mówimy, że
transakcja składa się z kilku agentów, gdzie agentem jest proces prowadzony w ramach danej
transakcji w określonym miejscu. System musi wiedzieć, czy dwa takie procesy są częścią tej
samej transakcji. Nie można na przykład pozwolić, aby dwóch agentów z tej samej transakcji
założyło na siebie wzajemną blokadę.
Zajmijmy się teraz kontrolą odtwarzania: Chcąc zagwarantować, aby dana transakcja w
systemie rozproszonym była atomowa (wszystko albo nic), system musi sprawić, żeby
wszystkie pojedyncze procesy związane z tą transakcją jednocześnie wykonywały albo jej
zatwierdzenie, albo wycofanie. Można to osiągnąć, stosując protokół dwufazowego
zatwierdzania.
Jeśli chodzi o kontrolę współbieżności, to jest ona oparta w większości systemów
rozproszonych na blokowaniu, podobnie jak to było w przypadku zwykłych systemów. (Kilka
nowszych systemów zaczęło stosować kontrolę wielowariantową, jednak tradycyjne blokowanie
w większości systemów jest nadal metodą z wyboru).
8.2.1. Kontrola odtwarzania
Kontrola odtwarzania przeważanie opiera się na protokole dwufazowego zatwierdzaniaistotny, gdy pojedyncza transakcja może oddziaływać z kilkoma autonomicznymi
menedżerami zasobów. Jest szczególnie ważne w systemie rozproszonym, ponieważ
menedżerowie zasobów – tj. lokalne DBMS – działają w odległych miejscach i są bardzo
autonomiczni.
•
•
•
•
•
Dodatkowe zagadnienia:
Cel sformułowany jako „brak uzależnienia od centralnego miejsca” sprawia, że nie można
przypisać funkcji koordynatora do jednego węzła sieci - musi ona być realizowana dla
różnych transakcji przez różne węzły. Zwykłe pełni to miejsce, w którym transakcja się
rozpoczęła. Każde miejsce pełni rolę koordynatora dla jednych transakcji, zaś rolę
uczestnika dla innych
Proces dwufazowego zatwierdzania wymaga, aby koordynator komunikował się z każdym
miejscem uczestniczącym. Oznacza to więcej przesyłania danych i większe obciążenie
dodatkowe.
Jeżeli miejsce Y działa jako uczestnik w procesie dwufazowego zatwierdzania
koordynowanym przez miejsce X, to musi ono robić to, co jej każe miejsce X (zatwierdzić
lub odwołać transakcję). Jest to niewielka utrata autonomii.
Problemem nierozwiązywalnym jest zapewnienie poprawnego działania dwufazowego
zatwierdzania w przypadku awarii sieci lub miejsca.
Proces dwufazowego zatwierdzania przedstawiono w p. 8.1.
8.2.2. Kontrola współbieżności
Kontrola współbieżności opiera się na blokowaniu, tak jak w zwykłych systemach. W
systemach rozproszonych jednak wszelkie żądania sprawdzania, ustawiania i zwalniania blokad
stają się komunikatami – oznacza to dodatkowe obciążenie systemu.
Problemy blokowania: pogarszanie wydajności oraz możliwość zakleszczenia transakcji
Przykład
Transakcja T musi aktualizować tabelę, która ma repliki w n oddalonych miejscach. Każde
miejsce kontroluje blokady złożone na tabeli tam przechowywanej (zgodnie z wymogami
lokalnej autonomii).
1)
2)
3)
4)
5)
Bezpośrednia implementacja kontroli będzie wymagała przesłania 5n komunikatów:
n żądań założenia blokady
n przydziałów blokady
n komunikatów o aktualizacji
n potwierdzeń
n żądań zdjęcia blokady.
Zastosowanie strategii z kopią pierwotną pierwotną: 2n+3 komunikatów, ograniczenie
autonomii lokalnej
1) 1 żądanie założenia blokady na kopię pierwotną
2) 1 przydział blokady
3) n komunikatów o aktualizacji
4) n potwierdzeń
5) 1 żądanie zdjęcia blokady.
Problem pełnego zakleszczenia (wzajemnej blokady – global deadlock)
T1x
Trzyma blokadę i
czeka na
zakończenie T1y
T2x
Czeka na zwolnienie blokady przez T1x
Miejsce X
Miejsce Y
T1y
Czeka na zwolnienie blokady przez T1x
T2y
Trzyma blokadę i
czeka na
zakończenie T2x
1) Agent transakcji T2 w miejscu X oczekuje na zwolnienie blokady przez agenta transakcji T1
w miejscu X
2) Agent transakcji T1 w miejscu X oczekuje na agenta transakcji T1 w miejscu Y na
zakończenie
3) Agent transakcji T1 w miejscu Y oczekuje na zwolnienie blokady przez agenta transakcji T2
w miejscu Y
4) Agent transakcji T2 w miejscu Y oczekuje na agenta transakcji T2 w miejscu X na
zakończenie. Pełne zakleszczenie.
Wykrywanie zakleszczeń nie jest możliwe w lokalnym grafie oczekiwań, a jedynie w grafie
globalnym. Prowadzi to dalszego obciążania systemu przesyłanymi komunikatami.
9. Niezależność sprzętowa
W zasadzie niewiele można dodać ponad to, co mówi tytuł tego punktu. Rzeczywiste
instalacje komputerowe zwykle obejmują wiele typów maszyn — komputery IBM, DEC, HP,
PC i różne stacje robocze itd. Naprawdę zachodzi potrzeba zintegrowania danych
przechowywanych w tych wszystkich systemach w jeden obraz. Pożądana jest możliwość
korzystania z tego samego DBMS na różnych platformach sprzętowych i zmuszenia ich do
partnerskiej współpracy w jednym systemie rozproszonym.
10. Niezależność od systemu operacyjnego
Ten cel jest częściowo wnioskiem z poprzedniego i także nie wymaga szerszej dyskusji.
Dobrze by było nie tylko móc stosować ten sam DBMS na różnych platformach
sprzętowych, ale także w środowiskach rozmaitych systemów operacyjnych. Dotyczy to
również różnych systemów operacyjnych na tym samym sprzęcie, np. korzystania z wersji
MVS, UNIX-owej i PC/DOS tego samego systemu rozproszonego.
11. Niezależność od sieci
Również i tutaj niewiele można dodać: jeżeli system ma wspierać różnorodne węzły, z
różnorodnym sprzętem i rozmaitymi systemami operacyjnymi, to oczywiście powinien móc
współdziałać z różnymi sieciami komputerowymi.
12. Niezależność od DBMS
W tym punkcie zastanawiamy się, jakie będą konsekwencje rezygnacji z założenia o ścisłej
homogeniczności systemu. Można sądzić, że założenie to jest zbyt mocne. Tak naprawdę
to potrzebujemy jedynie tego, aby instancje DBMS w różnych miejscach umożliwiały
korzystanie z tego samego interfejsu. Nie muszą one być kopiami tego samego
oprogramowania DBMS.
Na przykład, jeśli zarówno INGRES i ORACLE wspierają oficjalny standard języka SQL, to
łatwo możemy sobie wyobrazić, że miejsce z INGRESEM komunikuje się z miejscem z bazą
ORACLE w środowisku rozproszonym. Innymi słowy, system rozproszony może być do
pewnego stopnia heterogeniczny.
Możliwość korzystania z takiej heterogeniczości jest z pewnością pożądana. Instalacje
komputerowe w rzeczywistym świecie nie tylko składają się z różnych maszyn stosujących wiele
różnych systemów operacyjnych, ale także bardzo często używają różnych DBMS. Dobrze by
było, gdyby te rozmaite DBMS mogły jakoś uczestniczyć w systemie rozproszonym. Innymi
słowy, idealny system rozproszony powinien gwarantować niezależność od DBMS.

Wykład 6 Rozproszone bazy danych

Transkrypt

Podobne dokumenty

petrygo plus g12+

como parma due - swiatlo.warszawa.pl

Koszty ogrzewania elektrycznego

Złóź wniosek przez portal Emp@tia 2016

C-EZ Cennik nr EZ26020219UG Oferty ENERGIA+ Zdrowie

asti capri - swiatlo.warszawa.pl