Wykład 6 Rozproszone bazy danych

(1)

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

Sieć komunikacyjna

Miasto A Miasto B

Miasto C Miasto D

Lokalny DBMS+

warstwa rozproszona

=DDBMS

Lokalny DBMS+

warstwa rozproszona

=DDBMS

Lokalny DBMS+

warstwa rozproszona

=DDBMS Lokalny DBMS+

warstwa rozproszona

=DDBMS

(2)

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

(3)

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

(4)

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

(5)

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)

(6)

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:

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.

Widok Użytkownika EMP

EMP # DEPT#

Dl SALARY

El E2 E3 E4 E5

D1 D1 D2 D2 D3

40k 42k 30k 35k 48k

Nowy Jork Londyn48k

N_EMP L_EMP

EMP

#

DEPT

#

SALAR Y

EMP* DEPT* SALARY El

E2 E5

Dl Dl D3

40K 42K 48K

E3

E4 D2

D2 30 K

45 K

(7)

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

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’

Widok Użytkownika EMP

EMP # DEPT# SALARY Adres El

E2 E3 E4 E5

D1 D1 D2 D2 D3

40k 42k 35k 30k 48k

1 2 3 4 5

Nowy Jork Londyn

N_EMP L_EMP

EMP

# DEPT

# Adre

s SALAR

Y Adres

El E2 E3 E4 E5

Dl Dl D2 D2 D3

1 2 3 4 5

40k 42k 35k 30K 48K

1 2 3 4 5

(8)

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) aktu- alizacji.

Nowy Jork

N_EMP Kopia L_EMP

EMP

# DEPT

# SALAR

Y EMP* DEPT* SALARY

El E2 E5

Dl Dl D3

40K 42K 48K

E3

E4 D2

D2 30 K

45 K Londyn

L_EMP Kopia N_EMP

EMP

#

DEPT

#

SALAR Y

EMP* DEPT* SALARY E3

E4

D2 D2

30K 45K

E1 E2 E5

D1 D1 D3

40K 42K 48K

(9)

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.

(10)

7. Rozproszone przetwarzanie zapytania

•

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 Londyn

S(S#, Miasto) = 10 000 krotek P (P#, Kolor) = 100 000 krotek SP (S#, P#) = 1 000 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

(11)

Strategia Opis Czas Wyni k 1. Prześlij tabelę P (100000) do Nowego

Jorku i wykonaj tam pytanie

0.1(P)+100 000*200/50000

=400 sekund

6 min 40 sek 2. Prześlij tabele S (10000 krotek) i SP

(1000000 krotek) do Londynu i wykonaj tam zapytanie

0.1(S)+0.1(SP)+

(10000+1000000)

*200/50000= 4040 sekund

1 h 7 min 20 sek 3. 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)

0.1*100000+0.1*100000+

2*100000*200/50000=

20800 sekund

5 ha 46 min 40 sek

4. 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)

0.1*10+0.1*10 +

2*10*200/50000=2.08 sek

2.08 sek

5. 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)

0.1 + 100000*200/50000=

400.1sek

6 min 40.1 sek

6. 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+10*200/50000=0.14 sek

0.14 sek

(12)

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.

(13)

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 zmieniona- wó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

Transakcje

Czas tc tf

Punkt kontrolny Awaria systemu T1

T2 T3

T4

T5

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ą

(14)

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 zatwierdzania- istotny, 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.

(15)

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

Bezpośrednia implementacja kontroli będzie wymagała przesłania 5n komunikatów:

1) n żądań założenia blokady

2) n przydziałów blokady

3) n komunikatów o aktualizacji

4) n potwierdzeń

5) 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.

(16)

Problem pełnego zakleszczenia (wzajemnej blokady – global deadlock)

T1x

Trzyma blokadę i czeka na zakończenie T1y

T2x

Czeka na zwolnienie blokady przez T1x

T1y

Czeka na zwolnienie blokady przez T1x

T2y

Trzyma blokadę i czeka na zakończenie T2x Miejsce X

Miejsce Y

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.

(17)

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.