© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 1 grudzień 2004 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz.

Prezentacja na temat: "© K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 1 grudzień 2004 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz."— Zapis prezentacji:

1 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 1 grudzień 2004 Konstrukcja systemów obiektowych i rozproszonych Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykład 9: Wprowadzenie do rozproszonych baz danych (1)

2 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 2 grudzień 2004 Co to jest system rozproszony? Systemem rozproszonym nazywamy taki system, w którym przetwarzanie informacji odbywa się na wielu komputerach, często znacznie oddalonych geograficznie (od kilku metrów do dziesiątków tysięcy kilometrów). Przeciwieństwem jest system izolowany lub scentralizowany. Obecnie właściwie wszystkie systemy są rozproszone. Ogromnym katalizatorem rozproszenia systemów jest Internet. Projektowanie i własności systemów rozproszonych w dużej mierze są takie same jak systemów scentralizowanych, ale istnieją także istotne różnice, który specjalista inżynierii oprogramowania musi być świadomy. Tendencja do budowy systemów rozproszonych jest pochodną rozbudowy tanich, szybkich, uniwersalnych i niezawodnych sieci komputerowych. Przykłady systemów rozproszonych: sieć bankomatów, system rezerwacji biletów, system pracy grupowej, itd. Nową jakość do tematu systemów rozproszonych wnoszą sieci P2P (Peer- To-Peer) oraz technologie gridowe (grid computing).

3 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 3 grudzień 2004 Zalety systemów rozproszonych (1) Podział zasobów: system rozproszony pozwala dzielić zasoby sprzętowe i programowe pomiędzy wielu użytkowników pracujących na różnych komputerach pracujących w sieci. Otwartość: jest ona definiowana jako zdolność systemu do dołączania nowego sprzętu, oprogramowania i usług. Najlepiej na platformach sprzętowych i systemach operacyjnych dostarczanych przez różnych dostawców. Współbieżność: w systemie rozproszonym wiele procesów może działać w tym samym czasie na różnych komputerach w sieci. Procesy te mogą komunikować się podczas swego działania. Skalowalność: Moc i możliwości przetwarzania może wzrastać w miarę dodawania do systemu nowych zasobów, w szczególności komputerów. W praktyce skalowalność jest często ograniczona poprzez przepustowość sieci oraz (niekiedy) poprzez np. specyficzne protokoły wymiany informacji. Niemniej skalowalność systemu rozproszonego jest nieporównywalnie lepsza w stosunku do systemu scentralizowanego.

4 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 4 grudzień 2004 Zalety systemów rozproszonych (2) Tolerancja błędów: Dostępność wielu komputerów oraz umożliwienie zdublowania informacji (replikacje) oznacza, że rozproszony system jest tolerancyjny w stosunku do pewnych błędów zarówno sprzętowych jak i programowych. Np. awaria węzła komunikacyjnego powoduje wygenerowanie innej trasy przepływu informacji. Przezroczystość: Oznacza ukrycie przed użytkownikiem szczegółów rozproszenia, np. gdzie ulokowane są zasoby lub jak są one fizycznie zaimplementowane, pod jakim systemem pracują, itd. Przezroczystość ma zasadnicze znaczenie dla komfortu działania użytkownika oraz dla niezawodności budowanego oprogramowania. Niekiedy, np. dla celów optymalizacyjnych, użytkownik może zrezygnować z pełnej przezroczystości. Przykładem przezroczystości jest Internet: klikając w aktywne pole na stronie WWW nie interesujemy się, gdzie znajduje się odpowiadająca mu strona, oraz jak i na czym jest zaimplementowana.

5 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 5 grudzień 2004 Wady systemów rozproszonych Złożoność: systemy rozproszone są trudniejsze do zaprogramowania i do administrowania niż systemy scentralizowane. Zależą od własności sieci, np. jej przepustowości i czasu transmisji, co utrudnia zaprojektowanie i zrealizowanie wielu algorytmów i procesów przetwarzania. Ochrona: Dla systemu scentralizowanego wystarcza w zasadzie strażnik z karabinem. System rozproszony nie może być chroniony w ten sposób, przez co może być narażony na różnorodne ataki (włamania, wirusy, sabotaż, odmowa płatności, itd.) z wielu stron, które trudno zidentyfikować. Zdolność do zarządzania: jest ona utrudniona wskutek tego, że konsekwencje różnych działań administracyjnych w systemie rozproszonym są trudniejsze do zidentyfikowania. Podobnie z przyczynami sytuacji anormalnych, w szczególności awarii. Nieprzewidywalność: system rozproszony jest nieprzewidywalny w swoim działaniu, ponieważ zakłócenia mogą być powodowane przez wiele przyczyn: małą przepustowość i awarię łączy, awarię komputerów, zbyt duże obciążenie danego serwera, lokalne decyzje administracji serwera, itd.; patrz WWW.

6 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 6 grudzień 2004 Identyfikacja zasobów: zasoby są podzielone pomiędzy wiele komputerów, w związku z czym schematy ich nazywania muszą być zaprojektowane tak, aby użytkownicy mogli zidentyfikować interesujące ich zasoby. Przykładem takiego schematu jest URL znany z WWW. Komunikacja: może być zaprojektowana w sposób uniwersalny, na bazie np. protokołu internetowego TCP/IP. Niektóre wymagania dotyczące szybkości, kosztu, niezawodności lub bezpieczeństwa mogą prowadzić do specjalnych technik komunikacyjnych. Jakość obsługi: odzwierciedla wydajność systemu, jego dostępność i niezawodność. Podlega ona wielu czynnikom, w szczególności, przypisaniu zadań do procesorów, optymalności geograficznego podziału danych, itd. Architektura oprogramowania: opisuje ona w jaki sposób funkcjonalności systemu są przypisane do logicznych i fizycznych komponentów systemu. Wybór dobrej architektury przesądza o spełnieniu kryterium jakości obsługi. Krytyczne zagadnienia projektowe dla systemów rozproszonych

7 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 7 grudzień 2004 Popularne architektury rozproszenia Klient-serwer: rozproszony system ma wyróżniony węzeł zwany serwerem, oraz szereg podłączonych do niego węzłów zwanych klientami. Związek nie jest symetryczny: serwer wykonuje usługi zlecane przez klientów, nie może im odmówić i nie może im zlecić wykonanie usług. Klient-multi-serwer: podobnie jak dla architektury klient-serwer, ale istnieje wiele serwerów, np. WWW. Koleżeńska (peer-to-peer, P2P): wiele węzłów świadczy sobie wzajemne usługi poprzez bezpośrednie połączenie; nie ma wyraźnego podziału na usługodawców i usługobiorców. Np. Gnutella, NXOR, Napster, Kazaa; JXTA jako narzędzie do P2P. Komercyjny buzz dookoła P2P. Architektura oparta na oprogramowaniu pośredniczącym (middleware): nie występuje podział na klientów i serwery, np. CORBA i WebServices. Architektury gridowe: wirtualny komputer sumujący zasoby wielu komputerów w sposób przezroczysty dla użytkowników.

8 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 8 grudzień 2004 Co to jest rozproszona baza danych? Termin ten jest powtarzany w wielu kontekstach, często bez przypisywania mu konkretnego, technicznego znaczenia. Czy to, że z pewnego systemu można dostać się do danych innego odległego systemu jest wystarczającym wyróżnikiem rozproszonej bazy danych? Dla wielu zastosowań cecha ta jest istotna, ale: Rozproszona baza danych musi spełniać określone kryteria dotyczące spójności, bezpieczeństwa, zintegrowania i wygody użytkowników. Możliwość dostania się do danych innego systemu (np. poprzez pakiety oparte o technologie ODBC, JDBC,.NET, CORBA, J2EE, WebServices) oznacza wyłącznie ustanowienie niezbędnej bazy technicznej. Fakt ten nie przesądza jednak o tym, czy zachodzą dostateczne warunki dla sprawnego, efektywnego oraz niezawodnego wykorzystywania danych. distributed database

9 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 9 grudzień 2004 Podstawowe pojęcia związane z rozproszeniem Rozproszona baza danych: zbiór składający się z wielu logicznie ze sobą powiązanych elementów bazy danych, oddalonych geograficznie i połączonych ze sobą poprzez sieć komputerową. System zarządzania rozproszoną bazą danych (SZRBD): oprogramowanie umożliwiające połączenie rozproszonych zasobów w jedną całość, utrzymanie spójność zasobów oraz udostępnianie ich użytkownikom przy założeniu przezroczystości rozproszenia. Dane są przechowywane w wielu miejscach - węzłach sieci. Rozproszona baza danych jest bazą danych, a nie kolekcją plików, które mogą być indywidualnie przechowywane w każdym węźle sieci komputerowej. SZRBD posiada pełną funkcjonalność systemu zarządzania scentralizowaną BD. Nie jest to system zarządzania rozproszonymi plikami, ani też wyłącznie system przetwarzania transakcji.

10 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 10 grudzień 2004 Przykład rozproszonej bazy danych Rozproszona baza danych dla linii lotniczych (biuro obsługi klienta w Warszawie może dostać się do danych linii lotniczych w Sydney, Tokio, Paryżu, i setkach innych miast). Jeżeli w każdym miejscu organizacja bazy danych, środki manipulacji, reguły dostępu, itd. byłyby inne, to praca byłaby bardzo utrudniona, o ile w ogóle możliwa. Zatem konieczne są: standardy w zakresie połączenia (protokoły), standardy w zakresie organizacji danych i dostępu do danych, moduły dla odwzorowania pewnej specyficznej bazy danych na format oczekiwany przez danego klienta, przezroczystość rozproszenia (a la CORBA), zabezpieczenia przed niepowołanym dostępem.

11 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 11 grudzień 2004 Tematy związane z rozproszonymi BD (1) Architektury rozproszonego przetwarzania: bazy danych oparte o architekturę klient-serwer, bazy danych oparte o schemat globalny. Federacyjne bazy danych - (przezroczyste) połączenie wielu (relewantnych części) heterogenicznych i autonomicznych baz danych w jedną całość. Przetwarzanie transakcji w rozproszonych bazach danych; globalne transakcje, lokalne transakcje, dwufazowe i trójfazowe potwierdzenie (two-phase commit, 2PC). Długie transakcje, wymagające osłabienia poziomu izolacji i minimalizujące ryzyku utraty już wykonanej pracy. Współdziałanie heterogenicznych, autonomicznych, rozproszonych (Heterogeneous, Autonomous, Distributed, HAD) baz danych (określane także jako współdziałanie multi baz danych, multidatabase interoperability). Replikacje, czyli utrzymywanie kopii danych w wielu miejscach w rozproszonych bazach danych.

12 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 12 grudzień 2004 Tematy związane z rozproszonymi BD (2) Rozproszone przetwarzanie zapytań; optymalizacja zapytań w sytuacji rozproszenia zasobów. Mediatory, osłony, adaptery, perspektywy baz danych. Systemy operacyjne dla podtrzymywania rozproszenia: OSF DCE i inne systemy oparte o wołanie odległej procedury (Remote Procedure Call, RPC). Podtrzymywanie różnych form niewidoczności rozproszenia (distribution transparency) dla programistów i klientów baz danych. Standardy w zakresie rozproszenia: OMG CORBA, DCOM firmy Microsoft, RMI i Java Beans, OpenDoc, ActiveX, WebServices. Pośrednicy (broker, ORB) wg standardu CORBA, np. Orbix, Visibroker. Sieci Peer-To-Peer (P2). Technologie gridowe.

13 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 13 grudzień 2004 Tematy związane z rozproszonymi BD (3) Środki wspomagające rozproszenie bazy danych i rozproszone przetwarzanie zrealizowane w konkretnych systemach relacyjnych (Oracle, Sybase, Ingres, i inne), post-relacyjnych lub obiektowo- relacyjnych (Informix Universal Server, DB2 Universal Database, Oracle8, UniSQL/X, OSMOS, OpenIngres, Sybase Adaptive Server i inne) oraz obiektowych (Gemstone, Versant, O2, Objectivity/DB, ObjectStore i inne). Niezawodność, spójność, bezpieczeństwo i prywatność w rozproszonych bazach danych. Rozproszone bazy danych w sieciach Internet oraz Intranet. Rozproszenie danych i przetwarzania w systemach pracy grupowej oraz systemach zarządzania przepływem pracy.

14 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 14 grudzień 2004 Rozproszone BD: relacyjne czy obiektowe? Prace prowadzone nad rozproszonymi BD (w ciągu ostatnich 20-tu lat), były oparte głównie o relacyjny model danych. część tych badań nie uzyskała sukcesu, np. przetwarzanie zapytań. Zaletami modelu relacyjnego jest prosta, ujednolicona struktura danych oraz prosta organizacja katalogów bazy danych. W ostatnich latach obserwuje się odchodzenie od modelu relacyjnego w stronę modeli obiektowych. Złożoność samego problemu rozproszenia danych jest prawdopodobnie niezależna od modelu danych. Niektóre metody systemów relacyjnych związane z rozproszeniem dają się przenieść na grunt systemów obiektowych. Problemy nowe: metamodel (ontologia), przetwarzanie zapytań. W przeciągu najbliższych 10-ciu lat obiektowość będzie prawdopodobnie odgrywać główną rolę w rozwijaniu koncepcji rozproszonych baz danych, w różnych wariantach, np. XML/RDF.

15 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 15 grudzień 2004 Reguły rozproszonych baz danych (1) 12 reguł: w praktyce spełnienie wszystkich jest trudne lub niemożliwe. Jest to spekulacyjny ideał. Autonomia lokalnych BD: lokalne dane powinny podlegać lokalnym regułom własności i powinny być zarządzane lokalnie. Dotyczy to funkcji związanych z bezpieczeństwem, integralnością i reprezentacją wewnątrz pamięci. Wyjątki dotyczą sytuacji, kiedy więzy integralności muszą obejmować jednocześnie wiele miejsc oraz sytuacji, kiedy rozproszone transakcje muszą być sterowane przez pewne zewnętrzne miejsce. Brak podporządkowania przetwarzania do konkretnego miejsca: uniknięcie wąskich gardeł dzięki decentralizacji wszystkich funkcji rozproszonego SZBD. Ciągłość funkcjonowania: Przestoje w wykonywaniu operacji nie powinny być skutkiem dodania nowych miejsc, ich usunięcia ze środowiska rozproszonej BD, dokonania zmian w meta-informacji lub unowocześnienia wersji SZBD w pewnym indywidualnym miejscu.

16 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 16 grudzień 2004 Reguły rozproszonych baz danych (2) Niezależność od lokalizacji: Użytkownicy lub programy aplikacyjne nie muszą wiedzieć, gdzie dane są fizycznie przechowywane. Niezależność od fragmentacji: Fragmenty jednego zbioru danych mogą być przechowywane i zarządzane przez rozproszony SZBD jako jedna całość, bez uświadamiania użytkowników lub aplikacji o sposobie ich rozczłonkowania. Pożądaną własnością rozproszonego SZBD jest to, aby w sposób automatyczny unikał przetwarzania nierelewantnych fragmentów. Np. jeżeli grupa obiektów jest podzielona geograficznie ze względu na atrybuty w ten sposób, że atrybuty A 1...A m są w miejscu X, zaś atrybuty A m+1...A n są w miejscu Y, i konkretne zapytanie odwołuje się wyłącznie do atrybutów A 1...A m, należy pominąć odwołania do miejsca Y podczas realizacji tego zapytania. Podobnie, fragmenty tej samej tabeli w różnych miejscach rozproszonej bazy danych powinny być widocznej jako jedna tabela.

17 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 17 grudzień 2004 Reguły rozproszonych baz danych (3) Niezależność od replikacji: Istnienie replik danych w wielu miejscach, ich pojawianie się lub usuwanie nie powinno wpływać na postępowanie użytkowników ani na poprawność bądź spójność aplikacji. Rozproszone przetwarzanie zapytań: System powinien zapewniać sprawne przetwarzanie rozproszonych zapytań umożliwiające zredukowanie zarówno czasu przetwarzania, jak i obciążenia sieci transmisji danych. Zarządzanie rozproszonymi transakcjami: Zasady zarządzania transakcjami oraz sterowania współbieżnością powinny obowiązywać dla operacji w rozproszonej bazie danych. Zasady te włączają: wykrywanie i usuwanie zakleszczeń (deadlocks), zarządzanie przekroczeniami dopuszczalnego czasu (timeout), rozproszone protokóły potwierdzenia (commit) i odwracania (rollback), oraz inne metody. Niezależność od sprzętu: oprogramowanie rozproszonego SZBD powinno pracować na różnych platformach sprzętowych.

18 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 18 grudzień 2004 Reguły rozproszonych baz danych (4) Niezależność od systemu operacyjnego: oprogramowanie rozproszonego SZBD powinno pracować pod różnymi systemami operacyjnymi. Niezależność od sieci: Miejsca mogą być połączone poprzez szeroką gamę środowisk sieciowych i komunikacyjnych. Modele warstwowe istniejące dla współczesnych protokółów komunikacyjnych (obowiązujące w większości obecnych systemów informacyjnych, takich jak OSI 7, TCP/IP, warstwy SNA i DECnet) zapewniają środki do osiągnięcia tego celu nie tylko dla rozproszonych baz danych, lecz w ogólności dla systemów informacyjnych. Niezależność od SZBD: Powinno być możliwe przyłączenie do rozproszonej bazy danych lokalnej bazy danych zarządzanej przez dowolny lokalny SZBD.

19 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 19 grudzień 2004 Reguła: niezależność od centralnego miejsca Rozproszona baza danych nie może zależeć od jednego, centralnego miejsca odpowiedzialnego za całość funkcjonowania. No single point failure, no concentration points Zależność taka może "wkraść się" niepostrzeżenie, jako konsekwencja pewnych (wydawałoby się drugorzędnych) decyzji projektowych, np. powołanie jednego serwera nazw, lub rejestracja nowych miejsc przyłączających się do rozproszonej bazy danych. Zależność taka jest niekorzystna, gdyż: Centralne miejsce może stać się wąskim gardłem dla operacji na danych Awaria centralnego miejsca powoduje awarię całej rozproszonej bazy danych. Dla niektórych zastosowań brak centralnego miejsca jest niekorzystny: z powodu nadmiernego wzrostu obciążenia sieci związanego z wymianą metadanych; z powodu zbyt niskiej wydajności (indeksy w jednym miejscu) z powodów biznesowych: centralne miejsce jest wygodne dla kontrolowania pozostałych miejsc.

20 © K.Subieta. Konstrukcja systemów obiektowych i rozproszonych 9, Folia 20 grudzień 2004 Nazwy elementów danych w rozproszonych BD Problem nazywania i identyfikacji danych w rozproszonych BD staje się znacznie bardziej trudny niż w scentralizowanych BD. Kryteria zarządzania nazwami: 1. Każda dana, która ma być niezależnie identyfikowana w systemie rozproszonym, musi mieć swoją unikalną nazwę (identyfikator). 2. Nazwa powinna zapewniać efektywne odszukanie lokalizacji danej. 3. Nazwa nie powinna utrudniać zmiany lokalizacji danej. 4. Każde lokalne miejsce w rozproszonej BD powinno powinno mieć możliwość autonomicznego nadawania unikalnych nazw dla danych. Centralny serwer nazw - nadaje wszystkie nazwy, udziela informacji o lokalizacji nielokalnych danych na podstawie ich nazw: nie spełnia warunku 4, może powodować wąskie gardło dla transakcji, jest pojedynczym powodem awarii całości. Rozwiązanie: prefiksowanie nazwy identyfikatorem miejsca - trudności ze zmianą lokalizacji danych (przy zachowaniu tożsamości).