Konstrukcja systemów obiektowych i rozproszonych

1. Konstrukcja systemów obiektowych i rozproszonych Wykład 9: Wprowadzenie do rozproszonych baz danych (1) 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

2. 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. 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. 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. 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. Krytyczne zagadnienia projektowe dla systemów rozproszonych • 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.

7. 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. Co to jest rozproszona baza danych? distributed database • 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.

9. 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. 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. 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. 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. 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. 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. 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. 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 A1...Am są w miejscu X, zaś atrybuty Am+1...An są w miejscu Y, i konkretne zapytanie odwołuje się wyłącznie do atrybutów A1...Am, 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. 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. 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. 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. 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).