CC BY
152
mgr inz. Adam Krasuski prof. dr hab. inz. Tadeusz Maciak
Szkola Glôwna Sluzby Pozarniczej
ROZPROSZONE BAZY DANYCH - ARCHITEKTURA
FUNKCJONALNA
Streszczenie: Przedstawiony artykul ma charakter przegl^dowy a celem jego jest zwi^zly i syntetyczny opis niektorych aspektow zwi^zanych z technologic rozproszonych baz danych. Zawarto w nim rowniez wst^pn^ ocen§ przydatnosci tej technologii jako podstawy do budowy systemu wymiany informacji w PSP. Zaprezentowano podstawowy podzial rozproszonych baz danych oraz roznice funkcjonalne wyst^puj^ce mi^dzy poszczegolnymi ich rodzajami. Szczegolny nacisk polozono na opis aspektow technicznych dotycz^cych spojnosci i bezpieczenstwa danych. Majc one kluczowe znaczenie przy konstruowaniu systemow przeznaczonych dla sluzb ratowniczych wymagaj^cych duzej niezawodnosci i bezpieczenstwa na wysokim poziomie.
Abstract: This paper focuses on taxonomy of Distributed Database Systems (DDBS). A technical aspects related to DDBS like concurrency control, distributed recovery and query processing are described. The paper also contains comparison between DDBS and other systems of distributed data sharing.
Wstçp
System wymiany informacji wewn^trz Panstwowej Strazy Pozarnej (PSP) obok wykorzystania powszechnych narzçdzi takich jak poczta elektroniczna bazuje na programie o nazwie EWID. Program ten sluzy do gromadzenia informacji o zdarzeniach, w ktôrych interweniowala PSP. EWID zostal zbudowany na pocz^tku lat dziewiçcdziesi^tych i bez wiçkszych modyfikacji uzywany jest do dzisiaj. Zawartosc bazy danych przechowywana jest w plikach typu DBF (ang. database file). Informacje generowane w jednostkach nizszego szczebla (powiatach) zapisywane s^ lokalnie a takze przekazywane wyzej z wykorzystaniem protokolu FTP (ang. file transport protocol). Poszczegôlne kopie nie s^ ze sob^ synchronizowane a aktualizacja polega na dopisywaniu nowych wartosci.
EWID przechowuje jedynie podstawowe informacje o zdarzeniach. S3. to miçdzy innymi: czas, miejsce akcji, opis geograficzny i administracyjny a takze rodzaj pozaru, jego
wielkosc i zaangazowane sily i srodki. Dane wprowadzane s^. za pomoc^ pól wyboru w formularzu. Taki sposób powoduje brak dost?pu do szerszych opisów i sprawozdan z prowadzonych dzialan. Jednostki nizszego szczebla maj^ dost?p zaw?zony do informacji zgromadzonych na ich terenie. Ponadto ze wzgl?du na skrótowy opis zdarzen mog^. generowac jedynie zestawienia statystyczne.
W niektórych jednostkach PSP wprowadzono komputerowe systemy wspomagania decyzji. Zazwyczaj s^. to bazy danych substancji niebezpiecznych. Tylko niektóre jednostki wprowadzily systemy przetwarzaj^ce informacje geograficzne z danego terenu. Brak jest natomiast narz?dzi do dystrybuowania i pozyskiwania informacji z innych jednostek organizacyjnych PSP. Systemy wspomagania decyzji maj^. zazwyczaj opracowane scenariusze dzialan w zwi^zku z zagrozeniami wyst?puj ^cymi na ich terenie, co obecnie, z powodu zagrozenia terrorystycznego jest niewystarczaj^ce. Analiza ataków terrorystycznych na przykladzie Osetii Pólnocnej pokazuje, ze nawet male miasteczka typu Bieslan licz^ce 30 tysi?cy mieszkanców narazone s^. na ryzyko ataku, efektem którego smierc moze poniese kilkaset osób. Zdarzenia wyst?puj^ce w Polsce równiez potwierdzaj^, ze sluzby ratownicze musz^ miec dost?p do informacji na poziomie globalnym. Zawalenie si? Hali Targowej w Katowicach mialo swój precedens w zawaleniu si? budynku mieszkalnego w Gdansku w 1995 roku. Podczas akcji sl^scy ratownicy powinni miec dost?p do analiz i opisów dzialan wypracowanych przez ratowników gdanskich.
Chc^c skutecznie zapobiegac zagrozeniom mog^cym wyst^pic na terenie danej gminy czy powiatu sluzby ratownicze powinny miec dost?p do informacji globalnych z terenu calej Polski a nawet panstw s^siaduj^cych. Koniecznym warunkiem realizacji tej strategii jest budowa systemu wymiany informacji maj^cego na celu integracj? danych z terenu calej Polski. Tylko dost?p do informacji na poziomie globalnym jest w stanie zapewnic odpowiedni poziom bezpieczenstwa kazdej najmniejszej gminie. Systemy wspomagania decyzji nie powinny zawierac jedynie scenariuszy do zwalczania zagrozen istniej^cych na terenie danej gminy. Zagrozenia terrorem powoduje iz mozna si? spodziewac niebezpieczenstw transgranicznych. Dlatego tez budowa zintegrowanego systemu wymiany danych musi doczekac si? swojej realizacji. Wladze panstwowe oraz dowództwo PSP jest swiadome tej koniecznosci. Uruchomiony zostal projekt w ramach amerykanskiego offsetu mysliwca F-16 maj^cy na celu budow? takiego zintegrowanego systemu danych. Zgodnie z planami, architektura jego b?dzie bazowala na modelu scentralizowanym. Choc model ten jest jednym z prostszych w realizacji, posiada liczne ograniczenia w organizacjach rozproszonych
geograficznie takich jak PSP. Dlatego tez koniecznym jest rozwazenie innych rozwi^zan bazuj^cych na przyklad na modelu rozproszonym.
Prob? oszacowania przydatnosci innych modeli niz scentralizowany do budowy systemu wymiany danych podj?to w Szkole Glownej Sluzby Pozarniczej. Prowadzone s^ tam badania wlasne maj^ce na celu sprawdzenie mozliwosci wykorzystania technologii rozproszonych baz danych do budowy zintegrowanego systemu wymiany informacji. Badania te poprzedzone zostaly rozpoznaniem literaturowym z zakresu rozproszonych baz danych. Znajomosc podstaw oraz motywow, ktore powodowaly rozwoj tego typu systemow jest konieczna aby mozna bylo rozwazyc ich wykorzystanie w PSP.
Ponizszy artykul ma charakter przegl^dowy a celem jego jest zwi?zly i syntetyczny opis niektorych aspektow zwi^zanych z technologic rozproszonych baz danych. Zawarto w nim rowniez wst?pn^ ocen? przydatnosci tej technologii jako podstawy do budowy systemu wymiany informacji w PSP. Zaprezentowano podstawowy podzial rozproszonych baz danych oraz roznice funkcjonalne wyst?puj^ce mi?dzy poszczegolnymi ich rodzajami. Szczegolny nacisk polozono na opis aspektow technicznych dotycz^cych spojnosci i bezpieczenstwa danych. Majc one kluczowe znaczenie przy konstruowaniu systemow przeznaczonych dla sluzb ratowniczych wymagaj^cych duzej niezawodnosci i bezpieczenstwa na wysokim poziomie.
1. Wprowadzenie
Pierwsi projektanci systemow baz danych kierowali si? zasadc, iz do kazdego zbioru danych nalezy zbudowac oddzieln^ aplikacj? [1,2]. Z uplywem czasu, rozwi^zania takie, z uwagi na nadmiarowosc danych oraz problemy z ich wymiany, zast?powano systemami centralnymi. Informacje firmy gromadzone byly w jednym miejscu i udost?pniane poszczegolnym aplikacjom klienckim. Rozwi^zanie takie bylo rowniez najbardziej oplacalne ekonomicznie. Prawo Groscha [3] stanowilo, iz moc komputera jest proporcjonalna do kwadratu jego ceny. Powodowalo to, iz zakup duzej ilosci komputerow a co za tym idzie masowa produkcja byly malo oplacalne. Dlatego tez centralne przechowywanie danych, bylo polityk^ w pelni usprawiedliwion^ zarowno ekonomicznie jak i technologicznie.
Presja uzytkownikow oraz ograniczenia techniczne wymusily dalsze zmiany w systemach baz danych [4]. Zwolennicy zasady centralizacji d^zyli do modelu, w ktorym wszystkie dane przedsi?biorstwa zgromadzone zostan^ w jednym miejscu. Polityka taka w wi?kszych organizacjach typu banki lub osrodki zdrowia, spowodowala liczne niedogodnosci. W trakcie swojej dzialalnosci przedsi?biorstwa te nagromadzily bardzo duze ilosci danych.
Przy tak duzych ich ilosciach, powstal problem nawigacji w bazach scentralizowanych. Wyodr?bnila si? grupa uzytkowników, którym administratorzy systemów nie byli w stanie zapewnic satysfakcjonuj^cego poziomu dost?pu do bazy. Optymalizuj^c struktur? danych pod k^tem wydajnosci globalnej, skomplikowano obslug? systemu uzytkownikom lokalnym. Wzgl?dy technologiczne uniemozliwialy natomiast tworzenie widoków lub perspektyw dla potrzeb lokalnej obslugi danych.
Mimo polityki centralnego przechowywania danych zacz?ly powstawac tak zwane „wyspy informacji" [5]. Wynikalo to mi?dzy innymi z historycznej przeszlosci firm. Duze przedsi?biorstwa bardzo cz?sto powstawaly na skutek l^czenia si? i wchlaniania mniejszych. Kazda z wchloni?tych firm miala zazwyczaj swój wlasny system do zarz^dzania informacjami. Przeniesienie danych do jednego centralnego systemu poci^galo za sob^ znaczne naklady finansowe, co w wielu przypadkach bylo nieoplacalne.
Wraz ze wzrostem ilosci przechowywanych informacji w systemach centralnego gromadzenia danych napotkano szereg problemów technicznych [4]. Centralne systemy generowaly duz^. ilosc operacji wejscia/wyjscia na dyskach, co stanowilo zawsze w^skie gardlo aplikacji i spowalnialo jej prac?. Dodatkowo problemami byly niezawodnosc oraz bezpieczenstwo sytemu. Celem zabezpieczenia si? przed utrat^. danych stosowano kopie danych. Przy tak duzej ich ilosci bylo to bardzo kosztowne. Koniecznym stawal si? zakup zapasowego systemu o podobnych parametrach technicznych jak roboczy. Kazda awaria zas sytemu centralnego unieruchamiala w zasadzie caly system informatyczny instytucji.
Dane przechodzily ci^gl^. modyfikacj? na skutek regulacji prawnych, zmiany produktu czy tez optymalizacji systemu. W przypadku wykorzystania centralnego systemu do przechowywania danych bardzo trudne i zarazem kosztowne okazywalo si? wprowadzanie kazdej modyfikacji.
Ograniczenia te oraz presja uzytkowników systemów centralnych wymusily szukanie rozwi^zañ w dziedzinie systemów rozproszonych.
W polowie lat siedemdziesi^tych prawo Groscha zostalo podwazone. Rozwój technologiczny umozliwil relatywnie tani^ produkcj? procesorów. Dodatkowo badania w dziedzinie komunikacji sieciowej umozliwily efektywn^. wymian? danych mi?dzy komputerami. Wszystko to doprowadzilo do powstania nowego sposobu przechowywania danych - w systemach rozproszonych. W latach osiemdziesi^tych systemy te uzyskaly oficjaln^ nazw? Rozproszone bazy danych.
Obecnie okreslenie „Rozproszona baza danych" DDB (ang. Distributed Database) jest róznie rozumiana w srodowiskach informatycznych. Producenci systemów baz danych
postrzegaj^. DDB poprzez problemy zwi^zane z l^czeniem ich produktôw. Dla twôrcôw narzçdzi dostçpu oraz obslugi danych, DDB jest systemem, ktôry posiada rozproszon^ architekturç i wymaga zastosowania rôznego rodzaju protokolôw dostçpu. Producenci sprzçtu komputerowego widz^. natomiast DDB jako system skomponowany z rôznego rodzaju oprogramowania do obslugi baz danych pracuj^cych na tej samej platformie sprzçtowej.
W zasadzie kazda z tych definicji pasuje do luzno powi^zanych baz danych. Za najbardziej trafn^. uznaje siç definicjç ustanowion^. przez C. J. Date [1]. Wprowadzil on dwanascie zasad precyzuj ^cych idee rozproszonych baz danych. Zasady te maj^ na celu zdefiniowanie podstaw otwartej architektury umozliwiaj^cej integracjç systemôw baz danych rôznych producentôw. Celem ich jest rôwniez utworzenie systemu baz danych, ktôry swoj^. funkcjonalnosci^ przewyzszac bçdzie systemy scentralizowane.
2. Umiejscowienie DDB pomiçdzy systemami wspoldzielenia danych
Definicja zaprezentowana przez Date'a jest bardzo rozbudowana i sluzy zazwyczaj do wytyczania kierunku rozwoju oprogramowania z dziedziny rozproszonych baz danych.
W literaturze swiatowej natomiast najczçsciej wykorzystywana jest krôtsza definicja, zgodnie z ktôr^ rozproszon^ baz^ nazywamy [2,4-6]:
Logicznie polqczone ze sobq zasoby wspôtdzielonych danych, ktôre fizycznie rozproszone sqpomiçdzy wçzlami w sieci komputerowej.
Analogicznie System zarz^dzania rozproszon^ baz^. danych DDBMS (ang. Distributed Database Management System) definiowany j est j ako:
Oprogramowanie umozliwiajqce zarzqdzanie rozproszonq bazq danych, w sposôb, w ktôrym rozproszenie danych jest niewidoczne dla uzytkownikôw.
Definicja ta ma z kolei postac bardzo ogôln^. i w zasadzie wymogi jej spelniac moze wiele aplikacji. Dokonuj^c jej interpretacji mozna stwierdzic, iz DDB jest po prostu rozproszonym systemem plikôw DSF (ang. Distributed File Systems) [7]. W obu przypadkach zadaniem systemu jest zapewnienie uzytkownikom dostçpu do plikôw rozproszonych geograficznie. Wystçpuj^. jednak istotne czynniki odrôzniaj^ce DDB od DFS. Objawia siç to struktur^. przechowywanych danych oraz funkcjonalnosci^ tych systemôw.
Najwazniejsze czynniki rozrôzniaj^ce DDB oraz DFS s^. nastçpuj^ce [8]: 1. DFS zapewnia uzytkownikom prosty interfejs dostçpu do plikôw rozmieszczonych na komputerach pol^czonych w siec. Pliki te maj^ prosty struktur^ (zazwyczaj s^.
plaskie). Powiyzania pomi?dzy kilkoma plikami (o ile w ogole istniejy) nie sy zarzydzane przez system, pozostawiajyc to uzytkownikom. W przeciwienstwie do tego, DDB sy zorganizowane zgodnie ze schematem, ktory definiuje struktur? danych oraz relacje miedzy nimi. Za zarzydzanie struktury oraz relacjami odpowiedzialny jest system.
2. Interfejs uzytkownika w DFS umozliwia jedynie wykonywanie podstawowych operacji na plikach, typu: otwarcie, odczyt lub zapis oraz zamkni?cie pliku. DDB natomiast posiadajy pelny funkcjonalnosc centralnej bazy danych. Oznacza to, ze umozliwiajy wykonywanie operacji na danych z uzyciem j?zykow wysokiego poziomu (np. SQL ang. Structured Query Language lub OQL ang. Object Query Language), wsparcie dla transakcji (zbioru powiyzanych zapytan) oraz implementacj? mechanizmow wielodost?pu i odzyskiwania danych.
3. W rozproszonych bazach danych zapewniona jest przezroczystosc dost?pu do danych, co oznacza, iz uzytkownik nie zdaje sobie sprawy z tego, iz dane sy rozmieszone na innych komputerach niz jego. Natomiast w DFS uzytkownik musi znac rozmieszczenie plikow.
Rozproszony system plikow moze byc realizowany w roznych architekturach sieciowych. Moze to byc serwer udost?pniajycy swoje zasoby klientom (architektura klient/serwer) jak rowniez moze to byc architektura P2P (ang. peer-to-peer) [9], w ktorych nie ma wyraznie sprecyzowanego serwera i klienta.
W sieci P2P kazdy z w?zlow moze byc serwerem, ktory udost?pnia zasoby klientom, jak rowniez klientem korzystaj ycym z tych zasobow. Funkcjonalnosc t? ma cz?sc rozproszonych baz danych. Nie nalezy zatem kojarzyc sieci P2P z systemem wspoldzielenia plikow. DDB mogy rowniez byc budowane w architekturze P2P [10,11].
Waznym kryterium uznania danej bazy za rozproszony jest geograficzne oddzielenie od siebie przechowywanych zasobow. Definicja nie precyzuje odleglosci mi?dzy w?zlami. Jest zatem mozliwe utworzenie architektury rozproszonej bazy danych na jednym komputerze. Warunkiem jest aby komputer ten posiadal kilka procesorow i byl w stanie przetwarzac zapytania rownolegle. Systemy takie jednak stanowiy odr?bny dziedzin? techniki i znane sy pod nazwy Rownolegle bazy danych PDB (ang. Parallel Database Systems) [2,4,5].
W odroznieniu od rozproszonych baz danych PDB majy na celu przede wszystkim zwi?kszenie wydajnosci, a nie fakt integrowania struktur danych rozproszonych geograficznie [2,12]. Ponadto w?zly w rozproszonej bazie danych sy osobno administrowalne i polyczone
siecic o duzo mniejszej przepustowosci, natomiast w?zly rownoleglej bazy danych sc elementami tego samego komputera.
Obecnie coraz wi?kszc popularnosc w duzych przedsi?biorstwach zyskujc hurtownie danych (ang. Data warehouse) [13]. Podobnie jak rozproszone bazy danych zasoby hurtowni mogc byc rozproszone geograficznie. Istniejc jednak dosyc istotne roznice pomi?dzy tymi systemami. Do najwazniejszych mozna zaliczyc [4]:
1. DDB przechowujc dane biezcce, natomiast hurtownie danych przechowujc rowniez archiwalne;
2. Dane w hurtowni danych zazwyczaj sc zagregowane;
3. Dane przechowywane w hurtowni majc natur? statycznc - raz zaladowana hurtownia rzadko si? zmienia. Natomiast dane w DDB ulegajc cicglej modyfikacji.
4. W DDB mozna wyznaczyc zbior zapytan, ktore si? powtarzajc, natomiast w hurtowniach danych zapytania zazwyczaj sc niestrukturalne i heurystyczne.
Przedstawione roznice pomi?dzy DDB a innymi systemami rozproszonymi sklaniajc do wyznaczenia praktycznej definicji rozproszonej bazy danych. Mozna zatem stwierdzic, iz DDB jest systemem posiadajccym funkcjonalnosc centralnej bazy danych, jednak zasoby jej rozproszone sc geograficznie. Integracja danych realizowana jest za pomocc sieci komputerowej.
Jak zaprezentowano powyzej DDB stanowic wydzielony fragment oprogramowania o rozproszonym przetwarzaniu danych. Przez kilka lat rozwoju tej dziedziny baz danych, powstalo szereg rozwiczan realizujccych zalozenia DDB. Roznic si? one mi?dzy sobc zarowno architekturc jak i mozliwosciami funkcjonalnymi. Zaistniala roznorodnosc wymusila proby usystematyzowania tego oprogramowania.
3. Podzial DDB ze wzgl^du na architektur^
Jeden z pierwszych podzialow rozproszonych baz danych zostal opracowany przez D. Bella oraz J. Grimson [4]. Zaproponowali oni nast?pujccc struktur? DDBMS (rysunek 1).
Ryc. 1. Podzial rozproszonych baz danych, wg [4]
D. Bell oraz J. Grimson dokonali glownego podzialu rozproszonych baz danych na homogeniczne oraz heterogeniczne. W homogenicznych wszystkie w?zly wykorzystuj c ten sam rodzaj oraz wersj? oprogramowania, natomiast w heterogenicznych mamy do czynienia z
integracjy roznorodnych struktur danych umiejscowionych w roznych architekturach sprz?towych lub systemowych. W ponizszych rozdzialach zamieszczono szczegolowy opis rysunku 1.
3.1. Homogeniczne DDB
Homogeniczne bazy danych HDDB (ang. Homogeneous Distributed Databases) lyczy roznorodne zasoby danych jednak wszystkie w?zly wchodzyce w sklad systemu posiadajy ty samy wersj? oprogramowania [2]. Homogeniczne systemy zarzydzania bazy danych przypominajy centralne DBMS lecz w przeciwienstwie do nich dane sy fizycznie rozproszone. Rysunek 2 przedstawia struktur? HDDB.
Ryc. 2. Architektura homogenicznej rozproszonej bazy danych, wg [4]
Na rysunku 2 zaznaczono, iz uzytkownicy nie majy bezposredniego dost?pu do lokalnych baz danych. Kazdy z nich do komunikacji z bazy wykorzystuje globalny interfejs. Zgodnie z definicjy, rozproszenie danych musi byc ukryte przed uzytkownikiem. W celu uproszenia struktury globalnej, tworzy si? widoki bazy, dostosowane do potrzeb lokalnych uzytkownikow.
Do opisu danych wykorzystywany jest globalny schemat bazy, ukazujycy zaleznosci pomi?dzy poszczegolnymi relacjami. Jest on konstruowany poprzez polyczenie wszystkich lokalnych schematow.
Jako standard opisu centralnych DBMS uznana zostala architektura ANSI-SPARC [14]. Zaklada ona trzy warstwy opisu danych przechowywanych w bazie: fizyczny, logiczny oraz zewn?trzny. Kazdy z tych warstw opisujy odpowiednie schematy: wewn?trzny, konceptualny oraz zewn?trzny.
Architektur? ANSI-SPARC zastosowano rowniez do opisu rozproszonych baz danych. Jednak w ich przypadku dodatkowo rozszerzono jy celem uwzgl?dnienia aspektu rozproszenia danych. Wyodr?bniono dwie dodatkowe warstwy: alokacji oraz fragmentacji. Zmodyfikowany schemat rozproszonej bazy danych zgodny ze standardem ANSI-SPARC przedstawiono na rysunku nr 3.
Ryc. 3. Wzorcowa architektura dla DDBMS wg [2]
Przedstawiony na rysunku 3 schemat alokacji przechowuje informacje dotycz^ce lokalizacji danego fragmentu relacji [2,4]. Relacje w DDB mogc bye rozmieszczone na cztery podstawowe sposoby:
• centralnie w j ednym miej scu,
• podzielone na fragmenty i rozproszone,
• replikowane calkowicie w kazdym w^zle,
• replikowane selektywnie.
Centralizacja polega na utworzeniu w wybranym w^zle jednej bazy danych i zarz^dzaj^cego ni^ DBMS oraz pol^czenie tego w^zla z wieloma uzytkownikami rozproszonymi w sieci (metoda ta nazywana jest rowniez przetwarzaniem rozproszonym).
Metoda podzialu na fragmenty polega na podzieleniu bazy na rozl^czne fragmenty i umieszczenie ich w roznych w^zlach (kazdy fragment w innym w^zle). Rozmieszczenie danych w w^zlach, ktore najcz^sciej z nich korzystaj^, pozwala osi^gn^e wysoki poziom lokalnosci odwolan.
Calkowita replikacja, polega na przechowywaniu kompletnej kopii calej bazy w kazdym w^zle. Rozwi^zanie takie maksymalizuje lokalnose odwolan, wiarygodnose, dost^pnose oraz wydajnose. Z drugiej strony jednak s^ tutaj najwi^ksze koszty przechowywania, komunikacyjne oraz modyfikacji danych.
Selektywna replikacja jest pol^czeniem metod fragmentacji, replikacji i centralizacji. Cz^se danych jest dzielona na fragmenty w celu uzyskania wysokiego poziomu lokalnosci odwolan, cz^se natomiast wykorzystywanych przez wiele w^zlow oraz rzadko modyfikowanych jest replikowana. Pozostale dane, dla ktorych nie zastosowano replikacji i fragmentacji s^ scentralizowane [6].
Widoczny na rysunku 4 schemat fragmentacji przechowuje informacje dotycz^ce sposobu podzielania globalnej relacji (tabeli) na tabele lokalnych baz danych [2,4]. Wyrozniamy dwie glowne metody fragmentacji: poziom^. i pionow^. Fragmenty poziome s^ zbiorami krotek, natomiast pionowe zbiorami atrybutow. Stosowane s^ rowniez dwa inne rodzaje fragmentacji: mieszana oraz pochodna (rysunek 4).
Ryc. 4. Rodzaje fragmentacji: (a) pozioma, (b) pionowa, (c) mieszana
Fragmentacja pochodna polega na zlyczeniu relacji powstalych z wykonanych wczesniej fragmentacji.
3.1.1. Autonomicznosc systemow homogenicznych
Homogeniczne rozproszone bazy danych dziely si? dodatkowo na autonomiczne i nieautonomiczne. Autonomicznosc bazy jest okreslana jako mozliwosc modyfikacji (ingerencji) zawartosci bazy danych z poziomu lokalnego [6,8]. Nalezy przy tym wspomniec, iz autonomicznosc nie odnosi si? wylycznie do homogenicznych baz danych, jest ona rowniez atrybutem opisujycym heterogeniczne bazy.
Wi?kszosc systemow homogenicznych jest nieautonomiczna. Modyfikacja kazdej z baz lokalnych dokonywana jest poprzez globalny interfejs. Wynika to z konstruowania HDDB. Tworzenie ich zazwyczaj odbywa si? przez planowanie globalnej struktury a nast?pnie struktury relacji kazdego z w?zlow. Dzi?ki temu duzo latwiej wprowadzic mozna globalny interfejs zarzydzania bazy. Jest on znacznym ulatwieniem administracyjnym. Przeciwienstwem do tego typu projektowania sy systemy heterogeniczne, gdzie tworzenie bazy zazwyczaj odbywa si? poprzez lyczenie juz istniejycych systemow i globalna administracja kazdym z w?zlow staje si? trudna w realizacji [5].
3.2. Heterogeniczne DDB
W systemach heterogenicznych w?zly mogy wykorzystywac rozne oprogramowania, ktore nie muszy opierac si? na tym samym modelu danych [2,4]. W efekcie w sklad heterogenicznych baz danych mogy wchodzic relacyjne, sieciowe, obiektowe oraz inne modele danych.
Heterogeniczne bazy danych dziely si? na podklasy:
• zintegrowane poprzez pomosty;
• zintegrowane poprzez systemy;
W bazach zintegrowanych przez pomosty pomi?dzy poszczegolnymi w?zlami umieszczane jest oprogramowanie, ktore ma za zadanie dopasowanie protokolow komunikacyjnych oraz konwersj? zapytan na wlasciwe dla danej bazy [15].
W integracji przez systemy zadania dopasowania protokolow komunikacyjnych oraz tlumaczenia zapytan kierowanych do baz przejmuje jedna aplikacja. Polyczone sy z niy wszystkie niejednorodne bazy danych. Aplikacja lyczyca posiada specjalne API (ang. Application User Interface) umozliwiajyce programom klienckim korzystanie z baz
przyl^czonych do systemu [4]. Rysunek 5 przedstawia koncepcj? integracji przez pomosty oraz przez systemy.
Ryc. 5 Heterogeniczne bazy danych, koncepcja. a) zintegrowane przez pomosty, b) zintegrowane przez systemy
Aplikacje zintegrowane przez systemy dziel^ si? dodatkowo na zapewniaj^ce peln^. funkcjonalnose centralnego DBMS oraz takie, ktore jej nie zapewniaj^ poniewaz nastawione s^. na bardziej pragmatyczne zagadnienia, typu konwersja zapytan lub uzyskanie maksymalnej wydajnosci. Systemy, ktore realizuj^ cz^sciow^ funkcjonalnose DBMS nazywane s^ systemami wielobazowymi MDBS (ang. mutli-database systems) [2, 4, 12].
3.2.1. Systemy wielobazowe
Systemy wielobazowe l^cz^ roznorodne bazy danych, posiadaj^ce lokaln^ autonomi?. Integracja baz danych odbywa si? za pomoc^ warstw posrednicz^cych (ang. middleware). Warstwa ta moze miee charakter opakowuj^cy b^dz mediacyjny [6, 18]. Dost?p do lokalnych baz danych moze bye bezposredni lub przy wykorzystaniu globalnego interfejsu. Funkcjonalnose ta determinuje podzial MDBS na federacyjne (sfederowane) oraz niefederacyjne (niesfederowane) [4,12,16]. W federacyjnych bazach danych uzytkownicy mogc rowniez korzystae z obu wymienionych interfejsow, natomiast w niesfederowanych mogc wykorzystywae jedynie interfejs globalny. W obu przypadkach musi bye zapewniona przezroczystose lokalizacji, co oznacza, ze uzytkownicy nie zdajc sobie sprawy z tego, ze pracujc w systemie rozproszonym.
Integracja wielu niejednorodnych systemow baz danych w jedn^ rozproszon^ baz? nastr?cza cz?sto duzo problemow ze konstruowaniem jej schematu. Budowa globalnego schematu konceptualnego wymaga czasem zaangazowania tak duzych zasobow, iz staje si? to przedsi?wzi?ciem nieoplacalnym. W trakcie konstruowania schematu nalezy rozwi^zywae problemy zarowno semantyki jak i skladni zapytan poszczegolnych baz. Dlatego tez cz?sto rezygnuje si? z budowy globalnego schematu konceptualnego ograniczaj^c si? do schematow fragmentarycznych.
Ze wzgl?du na wyzej wymienione wlasnosci wsrod federacyjnych baz danych powstaly dwie podklasy: scisle zwi^zane (ze zdefiniowanymi schematami konceptualnymi) oraz luzno zwi^zane (bez schematow).
Bazy scisle zwiyzane muszy miec zdefiniowane schematy globalne. Schemat ten jest konstruowany poprzez polyczenie konceptualnych schematow lokalnych baz danych. Wybor zasobow lokalnych, ktore majy byc przylyczone do systemu globalnego, spoczywa na administratorach lokalnych baz danych. Funkcjonalnosc ta komplikuje budow? schematow globalnych.
Federacyjne scisle zwiyzane bazy danych ze wzgl?du na zlozonosc schematu globalnego, muszy posiadac mozliwosc definiowania widokow (tworzenia wirtualnych tabel, perspektyw). Ponadto czasami konieczne jest definiowanie rowniez schematow pomocniczych. Opisujy one zasady przeksztalcania (mapowania) schematow lokalnych na globalne. Mapowanie moze polegac mi?dzy innymi na konwersji jednostek, wtedy gdy opis danych na jednej z baz jest w kilometrach natomiast na innej w milach.
Luzno powiyzane MDBS nie posiadajy globalnego schematu konceptualnego. Ze wzgl?du na najbardziej nieograniczony mozliwosc w integrowaniu roznorodnych struktur danych nazywane sy rowniez Interoperacyjnymi (ang. Interoperable Database Systems) [17, 18]. W luzno powiyzanych bazach danych uzytkownik jest odpowiedzialny za tworzenie lokalnych widokow.
Przedstawiony podzial rozproszonych baz danych przebiega glownie mi?dzy systemami homogenicznymi oraz heterogenicznymi. Systemy homogeniczne sy prostsze w konstrukcji i zarzydzaniu, mimo to wi?kszym zainteresowaniem cieszy si? systemy heterogeniczne.
Jak wspomniano we wst?pie system wymiany informacji pomi?dzy poszczegolnymi komorkami organizacyjnymi PSP bazuje na systemie EWID. Dzi?ki temu dane przechowywane we wszystkich jednostkach PSP majy jednakowy struktur? oraz semantyk?. Taki stan rzeczy zwi?ksza szanse na wprowadzenie w PSP homogenicznych rozproszonych baz danych. Zastosowanie modelu homogenicznego niesie ze soby wiele zalet i powinno byc wprowadzane tam gdzie jest to mozliwe. HDDB dzi?ki wyst?pujycemu schematowi globalnemu oraz identycznemu oprogramowaniu sy latwiejsze w administrowaniu. Wprowadzenie heterogenicznych rozproszonych baz danych zazwyczaj jest podyktowane koniecznosciy integracji systemow juz istniejycych.
Trudnosc w implementacji homogenicznych baz danych polega na konstruowaniu przejrzystego a zarazem obejmujycego swym zasi?giem caly struktur? schematu globalnego. W przypadku PSP jednak konstrukcja schematu globalnego nie powinna nastr?czac trudnosci dzi?ki temu, ze struktura PSP jest hierarchiczna i relatywnie prosta. Zatem homogeniczne bazy danych wydajy si? najlepszym rozwiyzaniem dla PSP.
W PSP powinno d^zyc si? do tego aby lokalne bazy danych byly autonomiczne. Zmniejszy to naklady zwi^zane z administrowaniem systemem poprzez przeniesienie ci?zaru zarz^dzania baz^ na lokalnych administratorow.
W zwi^zku ze specyfik^ organizacji mozna zalozyc iz ponad 80 % wszystkich zapytan kierowanych do bazy b?dzie mialo zasi?g lokalny. Schemat alokacji zatem powinien bazowac na calkowitej fragmentacji danych. Spowoduje to iz ruch w systemie b?dzie minimalizowany ze wzgl?du na lokalnosc odwolan. Jednakze ze wzgl?du na czasowe odwolania globalne i wysoki ich priorytet (w sytuacjach akcji ratowniczej) nalezy dodatkowo zabezpieczyc istotne fragmenty danych replikaj Replikacja ta moze byc wykonywana w komendach wojewodzkich a kopie danych powinny sluzyc jedynie do odczytu w sytuacjach awarii lub gdy z^danie ma wysoki priorytet.
Powstanie tak roznorodnych struktur rozproszonych baz danych wynikalo z potrzeb uzytkownikow jak rowniez sposobow realizacji pewnych problemow technicznych.
W zwi^zku z rozproszeniem danych problemy zwi^zane z DDB s^ duzo bardziej skomplikowane niz w systemach scentralizowanych. Konieczne zatem staje si? dokladniejsze omowienie tej problematyki.
4. Aspekty techniczne rozproszonych baz danych
Rozproszone bazy danych powinny d^zyc do osi^gni?cia takiej samej funkcjonalnosci jak systemy scentralizowane. Najwazniejszymi funkcjami jakie musz^ zapewnic uzytkownikom to [6,8,12]:
• wsparcie dla zapytan oraz ich optymalizacja,
• dost?pnosc transakcji,
• kontrola wielodost?pu,
• integralnosc pomi?dzy poszczegolnymi relacjami,
• bezpieczenstwo,
• niezawodnosc.
Zagadnienia te w systemach rozproszonych s^ techniczne o wiele trudniejsze do rozwi^zania, ze wzgl?du na szereg dodatkowych problemow wynikaj^cych z rozproszenia danych. Wymienic tutaj mozna zaleznosc od sieci transmisyjnej, niejednorodnosc stosowanego oprogramowania, roznorodnosc modeli danych i wiele innych. W latach dziewi?cdziesi^tych problemy te w wi?kszosci zostaly rozwi^zane, niemniej prowadzone s^ nadal badania maj^ce na celu ulepszenie istniej^cych algorytmow [2, 5].
4.1. Przetwarzanie rozproszonych zapytaú
Przetwarzanie zapytania jest procesem, w którym zapytanie otrzymane od aplikacji uzytkowej przeksztalcane jest na niskiego poziomu operacjç na danych. Optymalizacja zapytania jest natomiast procesem wyboru najlepszej strategii wykonania tego zapytania [8].
W DDBMS proces przetwarzania zapytania realizowany jest w czterech etapach [6,
12]:
• dekompozycja zapytania,
• lokalizacj a danych, które maj ц byc przetwarzane,
• optymalizacja globalna,
• optymalizacja lokalna w poszczególnych bazach danych.
Dekompozycja zapytania, to jego przetworzenie na algebrç relacji. W procesie tym zapytanie poddawane jest semantycznej analizie, upraszczane a w przypadku wykrycia blçdu skladni odrzucane. Zapytania przetworzone przez modul dekompozycji odnoszy siç do relacji globalnych. Optymalizacja ich przybiega w taki sposób jakby wszystkie zasoby umieszczone byly w systemie centralnym. W procesie tym nie sy brane pod uwagç informacje dotyczyce lokalizacji danych oraz ich podzialu na fragmenty. Dlatego po dekompozycji poddawane sy dalszej obróbce. Glównym celem kolejnego modulu (lokalizacji danych), jest zlokalizowanie danych przy uzyciu schematu alokacji i fragmentacji. Z ich pomocy, zapytanie globalne przetwarzane jest na szereg zapytan odnoszycych siç do poszczególnych fragmentów (w^zlów).
Kazda globalna relacja moze byc odtworzona z lokalnych fragmentów na kilka sposobów. Modul lokalizacji danych ma za zadanie odrzucic te metody, które sy blçdne lub tez absorbujy zbyt duzo zasobów systemowych.
Po podziale zapytania globalnego na szereg operacji na fragmentach, wynik kierowany jest do kolejnego modulu - optymalizacji globalnej. Jego zadaniem jest wyznaczenie optymalnego zbioru zapytan na fragmentach danych, po rozwazeniu kosztów komunikacji z poszczególnymi bazami.
Ostatni etap to optymalizacja poszczególnych zapytan w lokalnych bazach danych. Jest to proces bardzo podobny do stosowanego w systemach scentralizowanych. W procesie tym brane sy pod uwagç aspekty wykorzystania indeksów relacji, czy tez ich skanowania sekwencyjnego. Na rysunku 6 przedstawiono sekwencjç realizacji zapytania globalnego.
Ryc. 6: Przetwarzanie zapytania w systemie rozproszonym
4.2. Kontrola wielodost^pu w systemach rozproszonych
Jezeli wielu uzytkownikow zamierza jednoczesnie dokonac modyfikacji danych w bazie, wowczas operacje te powinny byc synchronizowane przez system zarzydzania bazy danych. Synchronizacja taka jest realizowana przez mechanizm kontroli wielodost?pu (ang. concurrency control) [6,19,20]. Glownym jego zadaniem jest izolacja oraz szeregowanie transakcji uzytkownikow. Protokol implementujycy te mechanizmy kontroluje aby transakcje dotyczyce tego samego fragmentu danych byly uruchamiane dopiero wtedy kiedy zakonczone sy poprzednie. Ponadto celem zapewnienia wydajnosci systemu, dyzy do tego aby transakcje odnoszyce si? do roznych elementow danych wykonywane byly rownolegle.
Istnieje okolo dwudziestu algorytmow realizuj ycych kontrol? wielodost?pu.
W systemach rozproszonych najbardziej popularne to [19, 21-23]:
a) dwufazowe blokowanie;
a) znaczniki czasowe;
b) szeregowanie za pomocy wielowymiarowych znacznikow czasowych;
c) optymistyczny mechanizm bez blokad.
ad. a) Dwufazowe blokowanie 2PL (ang. two-phase locking). Protokol 2PL bazuje przydzieleniu kazdemu elementowi danych (rekord, atrybut) odr?bnej blokady. Jezeli jakas transakcja chce dokonac operacji na tych danych musi otrzymac od systemu dost?p do blokady. Do danych przypisane sy dwa rodzaje blokad: zapisu oraz odczytu. Zanim system przydzieli transakcji blokad? sprawdza czy jest ona wolna. Gdy warunek ten jest spelniony, transakcja niezaleznie do rodzaju operacji (odczyt/zapis) otrzymuj? blokad? odczytu. Moze jy teraz zmienic na zapisu, poniewaz jest pewna, ze nikt w tym czasie nie dokonuje operacji odczytu (blokada odczytu jest zaj?ta). Po wykonaniu operacji zwalniane sy obie blokady.
Dana transakcja moze otrzymac blokad? tylko wtedy kiedy poprzednio nie zwolnila innej blokady. Ma to na celu rozpoznawanie czy transakcja jest w fazie rosnycej czy wygasajycej i zabezpieczanie przed mozliwymi zakleszczeniami systemu [24]. Dwufazowe blokowanie jest najcz?sciej stosowany metody kontroli wielodost?pu. W systemach rozproszonych w zaleznosci od sposobu zarzydzania dzieli si? dodatkowo na:
1. Scentralizowane 2PL, w ktorych jeden w?zel w sieci jest odpowiedzialny za zarzydzanie tabely blokad dla calej rozproszonej bazy.
2. 2PL z kopiy glowny, jest najcz?sciej wykorzystywany w systemach z replikacjy danych, gdzie dane mogy posiadac kilka kopii w roznych w?zlach. Jedna z nich jest uznawana jako kopia podstawowa i tylko ona powinna byc blokowana w przypadku
dost?pu do danych. Kazdy z w?zlow zna lokalizacj? kopii glownych i prosba o przydzielenie blokady jest kierowana do w?zla na ktorym umieszczona jest kopia glowna. W?zel ten jest odpowiedzialny za kontrol? blokad. Jezeli baza danych nie jest replikowana wowczas metoda 2PL z kopi^ glowna sprowadza si? do rozproszonego 2PL [12].
3. Rozproszone 2PL, istnieje wielu zarz^dcow blokad, kazdy z nich jest odpowiedzialny za dane przechowywane w jego w?zle.
ad. b) Znaczniki czasowe TS (ang. time stamping). Najwi?kszym problemem z systemami blokad jest mozliwose wyst?powania zakleszczen. Maj^ one miejsce wtedy gdy kilka transakcji czeka na zwolnienie wzajemnie blokowanych danych. Problem ten moze bye rozwi^zany przez uzycie znacznikow czasowych. Kazda transakcja ma przyporz^dkowany znacznik czasu. Ponadto kazda operacja wewn^trz transakcji (jezeli na dan^ transakcj? sklada si? kilka zapytan) ma rowniez przypisany taki znacznik. W przypadku wyst^pienia konfliktu, priorytet ma transakcja o nizszym znaczniku czasowym. W systemach centralnych transakcji przydzielane s^ znaczniki czasowe na podstawie zegara systemowego. W przypadku DDBMS nalezy stosowae bardziej wyrafinowane algorytmy, poniewaz zintegrowane bazy danych mogc bye niezsynchronizowane pracuj^c w roznych strefach geograficznych. Powszechnie stosowanym rozwi^zaniem w rozproszonych DBMS jest wykorzystanie w roli znacznika pol^czenie wartosci lokalnego znacznika czasu z unikalnym identyfikatorem w?zla [4,21,22]. Dzi?ki temu transakcja identyfikowana jest z danym w?zlem i w przypadku ustalania priorytetu w?zly porownuj^ mi?dzy sob^ udost?pnione znaczniki czasu.
ad. c) Szeregowanie za pomoc^ wielowymiarowych znacznikow czasowych. W metodzie tej podobnie jak w poprzedniej kazdej transakcji przyporz^dkowywany jest znacznik czasu [19,22]. Jest on odpowiedzialny za ustalanie hierarchii transakcji. Kiedy transakcja dokonuje odczytu jakiegos fragmentu danych ustawia im swoj znacznik. Dane przechowuj^ zatem czas ostatniego odczytu. Kiedy transakcja dokonuje modyfikacji fragmentu danych tworzy jego kopi? z ustawionym znacznikiem modyfikacji. Jezeli w trakcie modyfikacji fragment danych uzyska znacznik odczytu wyzszy niz modyfikacji operacja jest wycofywana i powtarzana.
ad. d) Optymistyczny mechanizm bez blokad [22]. Poprzednie mechanizmy kontroli wielodost?pu wymagaly nadzorowania zapisu/odczytu danych przy uzyciu blokad lub znacznikow czasowych. Poci^galo to za sob^ wykorzystywanie znacznych zasobow systemowych, szczegolnie wtedy gdy angazowalo to operacje na dysku. W pewnych
sytuacjach jednak kontrola wielodostepu nie jest wymagana np. w przypadku gdy transakcja dokonuje jedynie odczytu danych.
W modelu optymistycznym transakcja dzielona jest na trzy fazy: odczytu, wartosciowania oraz zapisu. W trakcie pierwszej fazy transakcja przeprowadza modyfikacje danych w lokalnym buforze pamieci, w trakcie fazy wartosciowania system sprawdza spojnosc zmodyfikowanych danych, natomiast w trzeciej fazie zmiany lokalne otrzymujy status globalny. W przypadku odczytu danych transakcje przechodzy wylycznie dwie pierwsze fazy. Metoda wykorzystuje rowniez znaczniki czasu jako podstawe przeprowadzania wartosciowania transakcji.
W przypadku zintegrowanego systemu wymiany danych dzialajycego wewnytrz PSP nalezy sie spodziewac iz wiekszosc transakcji bedzie miala na celu odczyt danych. Dane mogy byc modyfikowane w niewielkim stopniu i zazwyczaj sprowadzone to bedzie do dodawania nowych wartosci. Wynika to przede wszystkich ze specyfiki systemu. Sposobem wykorzystania systemu sklania on sie bardziej w kierunku hurtowi danych. Jednakze dane w nim przechowywane nie bedy zagregowane oraz typ zapytan ma charakter transakcyjny a nie heurystyczny. W zwiyzku z tym w implementacji systemu w PSP mozna by sie bylo kierowac w strone optymistycznego mechanizmu bez blokad. Mechanizm ten ma swoje dodatkowe zalety w postaci malego obciyzenia systemu w porownaniu do konkurencji. Jest to istotne w systemach gdzie liczy sie predkosc przetworzenia zydan. Jednakze nie moze byc on zaimplementowany w czystej postaci. Musi zostac poddany modyfikacji w celu zwiekszenia jego niezawodnosci.
4.3. Synchronizacja transakcji w systemie rozproszonym
Niezawodnosc dzialania rozproszonej bazy danych charakteryzuj y dwa czynniki: atomowosc (niepodzielnosc) oraz trwalosc rozproszonych transakcji. Atomowosc wymaga tego, aby wszystkie operacje transakcji zostaly wykonane lub wszystkie odrzucone. Zasada trwalosci jest natomiast spelniona wtedy gdy po wykonaniu transakcji zmiany majy charakter trwaly.
Transakcje mogy byc przerwane na skutek roznego rodzaju awarii, wynikajycych czy to problemow komunikacyjnych, wad sprzetu, oprogramowania czy tez zakleszczen transakcji. W celu poprawnego przeprowadzania transakcji wymagane jest uprzednie sprawdzenie mozliwosci jej przeprowadzenia a w przypadku nastypienia awarii mozliwosc wycofania wprowadzonych zmian.
Aby spelnie wymogi atomowosci oraz trwalosci transakcji wymagana jest implementacja dwoch protokolow: atomowego wypelniania transakcji oraz rozproszonego odtwarzania. W DDBMS najcz?sciej wykorzystywane algorytmy realizuj^ce atomowe wypelnianie to dwufazowe lub trzyfazowe wypelnianie [2,6].
4.3.1. Wypelnianie dwufazowe
Zgodnie z nazw^ wypelnianie dwufazowej 2PC (ang. two-phase commit) sklada si? z dwoch faz: glosowania oraz decyzyjnej. W pierwszej fazie koordynator transakcji odpytuje wszystkie w?zly bior^ce udzial w transakcji o gotowose jej przeprowadzenia. Jezeli jeden z w?zlow glosuje za odrzuceniem transakcji lub nie udzieli odpowiedzi w okreslonym limicie czasu wowczas koordynator poleca wszystkim uczestnikom odrzucenie transakcji. Jezeli natomiast wszyscy glosuje za wypelnieniem transakcji wowczas koordynator nakazuje im jej wykonanie. W protokole tym zaklada si?, ze kazdy w?zel posiada swoj wlasny lokalny rejestr, na podstawie ktorego moze wiarygodnie wypelnie lub wycofae transakcj?. Wypelnienie dwufazowe wymaga, aby procesy oczekiwaly na wiadomosci z innych w?zlow. Stosuje si? jednak limity czasu oczekiwania, aby zapobiec niepotrzebnemu blokowaniu procesow. Rysunek 6 przedstawia dzialanie protokolu 2PC.
Ryc. 7. Schemat dzialania protokolu 2PC: (a) protokol 2PC dla uczestnika glosuj^cego za wypelnieniem; (b) protokol 2PC dla uczestnika glosuj^cego za odrzuceniem
Protokol 2PC posiada kilka wad, mi?dzy innymi mozliwose zablokowania w?zlow w trakcie transakcji. Przykladowo zablokowany zostanie proces, ktory przekroczy limit czasu po glosowaniu za wypelnieniem, lecz przed otrzymaniem globalnego wyniku od koordynatora, ktory w tym czasie mogl ulec awarii. Prawdopodobienstwo wyst^pienia tego typu awarii jest niewielkie, wobec czego 2PC jest stosowany dosye cz?sto. Znany jest jednak alternatywny protokol nieblokuj^cy, nazywany wypelnianiem trzyfazowym [2].
4.3.2. Wypelnianie trzyfazowe
Wypelnianie trzyfazowe 3PC (ang. three-phase commit) jest protokolem nieblokuj^cym, z wyj^tkiem sytuacji w ktorej awarii ulegn^ wszystkie w?zly. Podstawowe rozwi^zanie, na ktorym oparto 3PC, polega na usuni?ciu okresu „niepewnosci", w ktorym uczestnicy glosuj^cy za wypelnieniem transakcji oczekuje, az koordynator przesle im informacje o globalnym odrzuceniu lub wypelnieniu transakcji. W 3PC wprowadzono trzecie
faz? nazywany wst?pnym wypelnieniem (ang. pre-commit), wyst?pujycy mi?dzy glosowaniem a globalny decyzjy. Po otrzymaniu wszystkich glosow od uczestnikow zglaszajycych gotowosc do przeprowadzenia transakcji, koordynator wysyla komunikat „wypelnianie wst?pne". Po otrzymaniu komunikatu globalnego wypelniania wst?pnego uczestnik wie, ze wszyscy glosowali za wypelnieniem. W zwiyzku tym moze wypelnic transakcj?, chyba, ze ulegnie uszkodzeniu. Kazdy uczestnik wysyla potwierdzenie odebrania komunikatu PRE-COMMIT, a koordynator po otrzymaniu wszystkich potwierdzen dokonuje globalnego wypelniania. Glosy odrzucania transakcji sy dokladnie tak samo obslugiwane jak w 2PC.
Ze wzgl?du na wi?kszy niezawodnosc w systemie wymiany informacji w PSP powinien byc wykorzystany protokol 3PC.
4.4. Rozproszony protokol odtwarzania
Transakcja jest zbiorem zapytan, powiyzanych ze soby w ten sposob, iz w przypadku niepowodzenia jednego z nich odrzucane sy wszystkie. Mechanizm jej dzialania zaklada wi?c wycofanie zmian wprowadzonych przez zapytania jezeli w trakcie transakcji wystypila awaria lub inny powod jej nie zatwierdzenia. Wycofywanie transakcji oraz przywracanie bazy danych do stanu sprzed transakcji jest dziedziny, za ktore odpowiedzialny jest rozproszony protokol odtwarzania bazy danych (ang. Distributed recovery protocols) [2,6,12,25].
Protokol odtwarzania bazy danych traktuje rozproszony system, jako zbior procesow komunikujycych si? ze soby poprzez siec. Odpornosc na uszkodzenia realizowana jest poprzez okresowy zapis stanu bazy danych na trwalych nosnikach. Jezeli wystypila awaria systemu, mozliwy jest powrot do stanu, ktorym zostal zapisany na dysku, zachowujyc cz?sc wykonanych operacji. Momenty w ktorych dokonywany jest zapis nazywane sy punktami kontrolnymi (ang. checkpoint). Jezeli system nie wymaga od uzytkownikow zadnej ingerencji i dziala automatycznie zgodnie z ustalony polityky nazywany jest przezroczystym [25].
W systemach rozproszonych dzialanie protokolu komplikuje si?, poniewaz procesy komunikujy si? poprzez siec. Jezeli na jednym z w?zlow nastypi awaria, w?zel przywraca baz? do stanu poprzedzaj ycego awari?, przykladowo punku m. Dodatkowo w?zel musi wysylac wiadomosci do pozostalych uczestnikow aby one rowniez przywrocily bazy do stanu sprzed m. Jezeli wyznaczane punktow kontrolnych w poszczegolnych w?zlach nie jest zsynchronizowane, w latwy sposob moze dojsc do „efektu domino". W trakcie tego procesu bazy wzajemnie wysylajy do siebie informacj? o wycofywaniu zmian. Moze to doprowadzic
ze przywrocony zostanie stan pocz^tkowy, to jest moment uruchomienia bazy, a wszystkie modyfikacje utracone.
W celu unikni^cia efektu domino stosowane jest skoordynowane wyznaczanie punktow kontrolnych w kazdym w?zle [6].
Inn^. metod^ zapewniaj^c^ odpornosc na uszkodzenia jest wykorzystanie dziennikow (ang. log). Jest to pol^czenie wykonywania punktow kontrolnych z zapisywaniem wyj^tkow. Metoda bazuje na tym, iz wszystkie niestandardowe operacje wykonywane przez procesy s^. wychwytywane i zapisywane w dzienniku. St^d tez informacje potrzebne powtorzenia tej operacji s^ zachowane i w razie potrzeby mog^ byc odtworzone. Poprzez zapisywanie ich w kolejnosci wyst^pienia mozliwy jest powrot do stanu bazy z dowolnego momentu w przeszlosci.
4.5. Protokol replikacji
Zwi^kszenie wydajnosci systemu jest mozliwe poprzez replikacj? danych. Replikacja zaklada, ze cz?sc danych posiada swoje kopie w miejscach gdzie zapotrzebowanie na dost^p do nich jest duze. Replikacja jest oplacalna wtedy, gdy dane s^ rzadko modyfikowane i cz^sto wykorzystywane przez lokalnych uzytkownikow.
Zadaniem rozproszonego systemu zarz^dzania baz^ danych jest utrzymanie spojnosci pomi^dzy wszystkimi kopiami. Najwazniejszym kryterium utrzymania spojnosci danych jest rownowaznosc wszystkich kopii OCE (ang. One copy equivalence), ktory mowi iz wszystkie kopie logicznej cz^sci danych powinny byc identyczne w momencie gdy transakcja je modyfikuj^ca zakonczy dzialanie [12].
Jezeli zachowana jest przezroczystosc replikacji, transakcje przeprowadzaly operacje na logicznych danych x. Protokol replikacji b^dzie zas odpowiedzialny za to aby zmapowac operacj? z logicznej cz^sci danych na ich fizyczne kopie x (x1, x2, ..., xn). Typowy protokol kontroli replikacji ktory zapewnia funkcjonalnosc OCE znany jest jako ROWA (ang. Read Once/Write All). ROWA zamienia odczyt logicznych danych x na odczyt z wybranej fizycznej ich kopii xi. Wlasciwa kopia wyznaczana jest na podstawie kryterium wydajnosci. Kazda modyfikacja logicznych danych x wymaga modyfikacji wszystkich ich kopii fizycznych.
Protokol ROWA jest prosty i niezawodny, jednak wymaga aby podczas transakcji modyfikacji danych wszystkie kopie logicznej cz^sci danych byly dost^pne. Awaria jakiegokolwiek z w^zlow zmniejsza spojnosc bazy danych.
Istniejy rôwniez mniej rygorystyczne co do dostçpnosci wçzlôw protokoly ROWA. Wymagajy one aby tylko wiçkszosc fizycznych danych zostala zmodyfikowana podczas transakcji.
5. Podsumowanie
W artykule dokonano przeglydu rodzajôw rozproszonych baz danych. Dokonano umiejscowienia DDB w systemach rozproszonego przetwarzania. Artykul mial na celu zapoznanie z technologic rozproszonych baz danych a takze rozwazenie potencjalnych mozliwosci wprowadzenia ich w PSP i korzysci z tego plynycych. Podsumowujyc informacje zawarte w artykule mozna sporzydzic porôwnanie systemôw rozproszonych i scentralizowanych. Na korzysc systemôw rozproszonych przemawiajy miçdzy innymi argumenty [2, 4, 6] :
• niskie koszty (moc obliczeniowa do ceny jej uzyskania);
• przyspieszenie obliczen (dzielenie obciyzenia);
• niezawodnosc (awaria jednego urzydzenia nie powinna uniemozliwiac dzialania systemu, lecz co najwyzej pogorszyc jego wydajnosc);
• dostçpnosc (lokalnego dostçpu poprzez geograficzne rozproszenie);
• mozliwosc stopniowej rozbudowy;
• skalowalnosc (zdolnosc systemu do adaptowania siç do wzrastaj ycych wymagan).
Niewytpliwy wady systemôw rozproszonych jest ich zlozonosc i zwiçkszone
trudnosci z zapewnieniem bezpieczenstwa danych. Zlozonosc przedkladac siç moze na wystçpowanie wiçkszych ilosci awarii. W systemach tego typu jest to sytuacja trudna do przyjçcia dlatego tez mozliwosc wprowadzenia DDB w PSP musi poprzedzona odpowiedniy analizy i zwiçkszeniem ich niezawodnosci. Duzy nacisk musi byc rôwniez polozony na bezpieczenstwo danych. Informacje przechowywane w tych systemach majy charakter poufny i muszy byc nalezycie zabezpieczone. O ile w systemach scentralizowanych wystarczy odpowiednia ochrona budynku bydz pomieszczenia w ktôrym znajdujç siç komputer, o tyle w systemach rozproszonych niezbçdna jest odpowiednia globalna polityka bezpieczenstwa.
Mimo wymienionych trudnosci, systemy rozproszone posiadajy zalety potwierdzajyce ich potencjalnie duzy uzytecznosc w PSP. Teoretycznie wiçksze prawdopodobienstwo wystypienia awarii niwelowane jest faktem, iz awarie te nie wylyczajy systemu z uzycia a jedynie zmniejszajy jego funkcjonalnosc. W przeciwienstwie do systemôw scentralizowanych gdzie awaria jednego z elementôw systemu wylycza go z uzytku. Dziçki takim wlasciwosciom systemy rozproszone rozbudowane o dodatkowe mechanizmy
bezpieczenstwa znacznie lepiej nadaje si? dla sluzb bezpieczenstwa od scentralizowanych. Trudniej jest bowiem odpowiednim aktem terroru unieszkodliwic caly system.
Problematyczna staje si? natomiast polityka bezpieczenstwa w systemach rozproszonych. Konieczne jest stosowanie szyfrowania poleczen jak równiez reglamentowanie dost?pu do bazy osobom nieuprawnionym. Istniejece obecnie mechanizmy moge nie byc w stanie zapewnic bezpieczenstwa systemu na najwyzszym poziomie dlatego konieczne se dodatkowe prace w tym kierunku.
Znajomosc dziedziny rozproszonych baz danych pozwoli podjec bardziej wywazone ocen? odnosnie wyboru architektury bazy danych stanowiecej podstaw? budowy zintegrowanego systemu wymiany dokumentacji dla PSP.
6. Bibliografía
1. Date C. J.: Wprowadzenie do systemów baz danych. WNT Warszawa 2000
2. Connolly T. Begg C.: Systemy Baz Danych - projektowanie, wdrazanie i zarzedzanie w praktyce. RM Warszawa 2004
3. Mendelson H.: Economies of scale in computing: Grosch's law revisited. Communications of the ACM, vol. 30, nr 12, December 1987. str. 1066 - 1072
4. Bell D. Grimson J.: Distributed Database Systems. Addison-Wesley Reading MA 1994
5. Burleson D. K.: Managing Distributed Databases: Building Bridges between Database Islands. John Wiley & Sons New York 1994
6. Ozsu T. M., Valduriez P.: Principles of Distributed Database Systems. Prentice-Hall Wyd. drugie Englewood Cliffs, NJ 1999
7. Silberschatz A., Galvin P. B.: Podstawy systemów operacyjnych. WNT Warszawa 2000
8. Ozsu T. M., Yao B.: Distributed Databases. Encyclopedia on Distributed Computing Systems, J. Urban and P. Dasgupta (eds.), Kluwer Publishers 1999. http://db.uwaterloo.ca/~ddbms/publications/ozsu/Distdb/distdb.pdf
9. Clarke R.: Peer-to-Peer (P2P) - An Overview. Xamax Consultancy Pty Ltd, November 2004 http://www.anu.edu.au/people/Roger.Clarke/EC/P2POview.html
10. Fanconi E., Kuper G., Lopatenko A.: A robust logical and computational characterization of peer-to-peer database systems. Insternational Workshop On Databases, Information Systems ona Peer-to-Perr Computing 2003 http://www.inf.unibz.it/~franconi/papers/p2p-03.pdf
11. Fanconi E., Kuper G., Lopatenko A.: A distributed algorithm for robust data sharing and updates in P2P database networks http://www.inf.unibz.it/~franconi/papers/p2pdb-04.pdf
12. M.T. Özsu , "Distributed Database Systems", In Encyclopedia of Information Systems, Hossein Bidgoli (ed.), Academic Press, 2003, str. 673-682 http://db.uwaterloo.ca/~ddbms/publications/ozsu/EIC/eic.pdf
13. Inmon W. H.: Building a Data Warehouse (3rd Edition). John Wiley and Sons, Inc. 2002
14. Tsichritzis, D., Klug, A. (eds.): The ANSI/X3/SPARC Framework. Information Systems 3, 1978, str. 173-191
15. Wrembel R.: Integracja danych z wykorzystaniem oprogramowania gateway. Materialy pokonferencyjne Hurtownie danych i Business Intelligence. Warszawa 2004, str. 139-154.
16. Abbott K. R., McCarthy D. R.: Administration and Autonomy In A Replication-Transparent Distributed DBMS. 14th VLDB Conference Los Angeles 1988, str. 195-205. http://www.vldb.org/conf/1988/P 195 .PDF
17. Dogac A., Dengi C., Kiliac E.: METU Interoperable Database System. ACM SIGMOD Record, vol. 24, nr 3, September 1995 str. 56-61 http://citeseer.ist.psu.edu/79542.html
18. Stonebraker M., Brown P., Hebrach M.: Interoperabilty, Distributed Application and Distibuted Databases: The Virtual Table Interface. IEEE Data Engineerinng Buttetin, nr 3, vol. 21, September 1998, str. 25-34.
19. Pitkanen T.: Information searching and distributed databases. ACM Computer Survey, Vol. 13, No. 2, June 1997, str. 149—183.
http://saato014.hut.fi/Hyotyniemi/publications/97_report106/PITKANEN/node1.html
20. Harris T. J., Perrizo W., Ding Q.: Mutliversion post ordering: a new concurrency control method. North Dakota State University http://cs.hbg.psu.edu/~ding/publications/CAINE-1059A.pdf
21. Lamport L.: Time, Clocks and Ordering of Events in Distributed System. Communications of ACM, Nr 7, vol. 21, July 1978, str. 558-565. http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf
22. Munson J., Dewan P.: A concurrency control framework for collaborative systems. Computer Supported Cooperative Work. Proceedings of the 1996 ACM conference on
Computer supported cooperative work, str. 278-287 http://www.cs.unc.edu/~dewan/242/s99/notes/trans/node6.html
23. Bernstein P.A., Goodman N.: Concurrency Control in Distributed Database Systems, ACM Computing Surveys, vol. 13, no. 2, str. 185-221, June 1981.
24. Tanenbaum A. S., Steen M.: Distributed Systems: Principles and Paradigms. Prentice Hall 2002
25. Elnozahy M., Alvisi L., Wang A.: A Survey of Rollback-Recovery Protocols in Message-Passing Systems. ACM Computing Surveys 2002, vol. 34, nr 3, str. 375-408. http://citeseer.ist.psu.edu/200905.html
2 6 . System C2 - zintegrowany, ogolnopolski system powiadamiania ratunkowego i zarzydzania kryzysowego. Projekt offsetowy 2-104 A-G http://www.ziz.com.pl/cpr/PrezentacjaC2%20_Lublin.pdf
