Wprowadzenie do rozproszonych baz danych (1)
- System rozproszony
- Popularne architektury rozproszenia
- Rozproszona baza danych
- Reguły rozproszonych baz danych
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Reguły rozproszonych baz danych
- 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.
- 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.
- 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.
- 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.
-
pokaż animację
- 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.
- 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).