Studia Podyplomowe IT w Biznesie Systemy Rozproszone Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 5 Wprowadzenie do rozproszonych i federacyjnych baz danych Wykładowca: dr hab. inż. Kazimierz Subieta profesor PJWSTK subieta@ipipan.waw.pl, http://www.ipipan.waw.pl/~subieta Niniejszy materiał jest dostępny pod: http://www.si.pjwstk.edu.pl

Plan wykładu Definicja rozproszonej bazy danych Tematy i pojęcia związane z rozproszonymi BD Reguły rozproszonych baz danych Federacyjne bazy danych Podstawowe metody podziału schematu logicznego Replikacje Migracje obiektów Przetwarzanie transakcji i dwufazowe potwierdzenie (2PC) Przetwarzanie zapytań w rozproszonych bazach danych Rozproszone BD w standardzie CORBA

Co to jest rozproszona baza danych? distributed database Czy fakt, ż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 niewątpliwie istotna, lecz rozproszona baza danych musi spełniać określone kryteria dotyczące: spójności, bezpieczeństwa, zintegrowania i wygody użytkowników; dostatecznej szybkości przetwarzania; wygody programowania i niezawodności globalnych aplikacji; stabilności i modyfikowalności całego systemu. Możliwość dostania się do danych innego systemu (np. poprzez pakiety oparte o standardy ODBC, JDBC, DCOM lub CORBA) oznacza ustanowienie niezbędnej bazy technicznej. Fakt ten nie przesądza jednak o tym, czy zachodzą dostateczne warunki dla sprawnego, efektywnego oraz niezawodnego wykorzystywania danych. Przykład: rozproszona baza danych dla linii lotniczych (biuro obsługi klienta w Warszawie może dostać się do danych w Sydney, Tokio, Paryżu itd.). Jeżeli w każdym miejscu organizacja bazy danych i reguły dostępu, itd. byłyby inne, to programowanie aplikacji byłoby bardzo utrudnione.

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 łączące wiele spadkowych baz danych poprzez pewien protokół federacyjny; Przetwarzanie transakcji w rozproszonych bazach danych; dwufazowe 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 baz danych (określane także jako multidatabase interoperability). Replikacje (podtrzymywanie kopii) w rozproszonych bazach danych. Rozproszone przetwarzanie zapytań; optymalizacja zapytań w sytuacji rozproszenia zasobów.

Tematy związane z rozproszonymi BD (2) Systemy operacyjne i standardy dla podtrzymywania rozproszenia: CORBA, DCOM, ... Podtrzymywanie różnych form niewidoczności rozproszenia (distribution transparency) dla programistów i klientów baz danych; Środki wspomagające rozproszenie bazy danych i rozproszone przetwarzanie zrealizowane w konkretnych systemach zarządzania bazą danych; Niezawodność, integralność, spójność, ochrona, bezpieczeństwo i prywatność w rozproszonych bazach danych; Rozproszone bazy danych w sieciach Internet oraz Intranet; bazy danych oparte o standard XML; Rozproszenie danych i przetwarzania w systemach pracy grupowej oraz systemach zarządzania przepływem prac.

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): umożliwiający połączenie rozproszonych zasobów w jedną całość, utrzymujący spójność tych zasobów, udostępniający je użytkownikom, ukrywający rozproszenie zasobów. Dane są przechowywane w wielu miejscach, tzw. węzłach sieci komputerowej; Rozproszona baza danych jest „bazą danych”, a nie „kolekcją plików"; SZRBD posiada pełną funkcjonalność scentralizowanego SZBD.

Reguły rozproszonych baz danych (1) Autonomia lokalnych BD: Lokalne dane powinny podlegać lokalnym regułom własności i powinny być zarządzane lokalnie. Brak podporządkowania przetwarzania do konkretnego miejsca: Spełnienie tej reguły umożliwia 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 lub ich usunięcia Niezależność od lokalizacji: Użytkownicy lub programy aplikacyjne nie muszą wiedzieć, gdzie dane są fizycznie przechowywane. Niezależność od rozczłonkowania: Fragmenty jednego zbioru danych mogą być przechowywane i zarządzane przez rozproszony SZBD jako jedna całość Niezależność od replikacji: Pojawienie się replik danych nie powinno wpływać na postępowanie użytkowników ani na konieczność przeróbek aplikacji.

Reguły rozproszonych baz danych (2) 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. Niezależność od sprzętu i systemu operacyjnego: Dowolne oprogramowanie rozproszonego SZBD powinno pracować na różnych platformach. Niezależność od sieci: Aplikacje działające na rozproszonej bazie danych nie powinny być uzależnione od protokołów sieciowych. Niezależność od SZBD: Powinno być możliwe przyłączenie do rozproszonej bazy danych lokalnej bazy danych zarządzanej przez dowolny lokalny SZBD.

Główne aspekty rozproszenia baz danych Przezroczystość (transparency) Dotyczy konstrukcji systemów zarządzania bazami danych, które podtrzymują rozproszenie danych (poprzez odpowiednie środki dostępu do odległych zasobów), pozwalają na utrzymanie spójności, bezpieczeństwa i niezawodności rozproszonej bazy danych, optymalizują koszty transmisji, oraz izolują programistę/użytkownika od większości aspektów rozproszenia. Współdziałanie (interoperability) Oznacza współpracę zbudowanych niezależnie od siebie heterogenicznych systemów (heterogeneous systems). Ważnym aspektem współdziałania jest integracja systemów starych systemów, tzw. spadkowych (legacy)

Co to jest Federacyjna Baza Danych? Federated Database Jest to kolekcja heterogenicznych, autonomicznych baz danych, połączonych siecią komputerową, zarządzana specjalnym systemem określanym jako Federacyjny System Zarządzania Bazą Danych (FSZBD). Może włączać dziesiątki, setki, tysiące lub więcej lokalnych baz danych. FSZBD umożliwia tworzenie aplikacji globalnych, działających na całości federacyjnej bazy danych. Jest ona zdefiniowana schematem federacyjnym, będącym sumą schematów eksportowych lokalnych baz danych. FSZBD zapewnia warunki pracy twórców aplikacji globalnych określane jako przezroczystość i niezależność danych. FSZBD może być zainstalowany w wielu węzłach sieci (m.in. w każdym lokalnym miejscu FBD), umożliwiając tworzenie aplikacji globalnych w wielu miejscach geograficznych. Poszczególne FSZBD współpracują ze sobą celem zapewnienia spójności i integralności przetwarzania.

Architektura federacyjnej bazy danych Aplikacje globalne Aplikacje globalne ... FSZBD 1 Przestrzeń robocza FSZBD m Przestrzeń robocza Schemat FBD Schemat FBD Sieć komputerowa Schemat eksportowy 1 Osłona 1 API 1 Schemat eksportowy 2 Osłona 2 API 2 Schemat eksportowy n Osłona n API n ... Lokalny SZBD 1 Lokalny SZBD 2 Lokalny SZBD n BD 1 BD 2 BD n Aplikacje lokalne Aplikacje lokalne Aplikacje lokalne

Replikacje Technologia replikacji oznacza przechowywanie dwóch lub więcej kopii danych (replik) w oddalonych geograficznie miejscach. Cele: Zwiększenie dostępności danych poprzez: - zminimalizowanie czasu i kosztów ich transmisji z odległego miejsca - rozłożenie obciążenia w zakresie dostępu na wiele kopii danych Zwiększenie odporności danych na zniszczenie. Zwiększenie bezpieczeństwa

Aktualizacja replikacji Aktualizacja dowolnej kopii danych powinna spowodować jednoczesną aktualizację wszystkich pozostałych kopii. W idealnym przypadku powinno to następować jednocześnie, aby zapobiec sytuacji, gdy dane przechowywane w różnych kopiach są wzajemnie niespójne. Ten ideał nie daje się zrealizować tak łatwo z kilku powodów: Czas transmisji zleceń aktualizacyjnych powoduje, że kopie są chwilowo wzajemnie niezgodne; Zawodność łączy i węzłów sieci może spowodować czasową niemożliwość wykonania zlecenia aktualizacyjnego; Koszt transmisji zleceń aktualizacyjnych może być nieakceptowalny w przypadku bardzo częstych zmian. Można wyobrazić sobie sytuację, kiedy każda aktualizacja dowolnej kopii jest wykonywana w ramach transakcji, która nie będzie potwierdzona aż do momentu zaktualizowania wszystkich kopii. Takie rozwiązanie w większości przypadków powoduje jednak znaczne zmniejszenie dostępności danych.

Modele replikacji Jednoczesne aktualizacje ze sterowaniem współbieżnościa Propagacja aktualizacji Transakcja aktualizacyjna Replika 2 Replika 1 Replika 3 propagacja aktualizacji Transakcja aktualizacyjna Replika 2 Replika 1 Replika 3 Planowane odświeżanie kopii dla replik tylko do czytania Transakcja aktualizacyjna Replika 2 Replika 1 Replika 3 planowana aktualizacja Transakcja czytaj ą ca

Migracje obiektów Migracja oznacza przemieszczanie się obiektów między węzłami sieci, przy czym obiekty muszą być skojarzone ze swoimi klasami i przechowywanymi w ramach tych klas metodami. Określenie jednostki migracji Śledzenie obiektów Utrzymywania porządku w katalogu systemu bazy danych Okresowa kondensacja łańcuchów obiektów pośrednich Przemieszczanie obiektów złożonych Zapewnienie globalnej przestrzeni nazw Zapewnienie właściwych mechanizmów zakresu i wiązania Dostępność metod umożliwiających przetwarzanie obiektów Podstawowe problemy: Jak dotąd, metody są składowymi aplikacji, a nie bazy danych. Konsekwencją jest to, że po przemieszczeniu obiektu aplikacja działająca w jego nowym miejscu musi mieć wbudowane (powielone) metody do jego przetwarzania.

Przetwarzanie transakcji Transakcja jednostka przetwarzania baz danych posiadająca własności określane skrótem ACID (Atomicity, Consistency, Isolation, Durability): atomowość, spójność, izolacja, trwałość Faza potwierdzenia (commit) może trwać długo. Niepowodzenie (awaria) w tej fazie może spowodować niespójność bazy danych i przetwarzania. Stąd nowe protokoły przetwarzania transakcji w systemie rozproszonym, np. protokół dwufazowego potwierdzenia (two-phase commit, 2PC). Zakleszczenie: wykrywanie, usuwanie Ziarnistość mechanizmu transakcji: bezpośrednio związana z dostępnością rozproszonej bazy danych (liczbą jednocześnie pracujących użytkowników). Wydajność (performance): złożone protokoły powodują jej zmniejszenie. Długie transakcje: konieczność zmniejszenia poziomu izolacji Podstawowe problemy:

Dwufazowe potwierdzenie (2PC) Program aplikacyjny klienta SZBD klienta potwierdź potwierdź potwierdź gotów gotów gotów SZBD serwera 1. Serwery wysyłają komunikaty “gotów “ do klienta. 2. Po skompletowaniu wszystkich zgłoszeń klient wysyła komunikat “potwierdź” do wszystkich serwerów. Jeżeli nie nadejdą wszystkie zgłoszenia “gotów”, klient wysyła komunikat “zerwij transakcję” do wszystkich serwerów. Wady: możliwość zawieszenia systemu w przypadku awarii jednego z serwerów, duże straty wykonanej pracy w przypadku zerwania. Alternatywa: bardziej złożone protokoły.

Przetwarzanie zapytań Przetwarzanie zapytań powinno minimalizować obciążenie linii transmisyjnych. W systemach rozproszonych przetwarzanie zapytań odbywa się poprzez: dekompozycję zapytania na operacje wysyłane do różnych węzłów, porządkowanie tych operacji, zbieranie ich rezultatów w miejscu zapytania w celu skonstruowania ostatecznego wyniku zapytania. Istnieje kilka strategii optymalizacji przetwarzania zapytań w rozproszonych BD: Wysłanie wszystkich potrzebnych do realizacji zapytania danych do centralnego miejsca w celu przetworzenia zapytania (bardzo kosztowne!); "Statyczna" dekompozycja zapytania na podzapytania, wysłanie ich do lokalnych miejsc, przesłanie rezultatów podzapytań do centralnego miejsca i połączenie tych rezultatów w globalny rezultat (często nieskuteczne); "Dynamiczna" dekompozycja: generacja podzapytania do miejsca 1 i przesłanie wyniku 1 do centralnego miejsca; generacja podzapytania do miejsca 2 i przesłanie wyniku 2 do centralnego miejsca, itd. (trudności koncepcyjne). .....

Statyczny schemat przetwarzania zapytań 1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach S1, S2,..., Sk 2. Klient dokonuje odwzorowania zapytania Z na zapytania Z1, Z2, ... , Zk adresowane do serwerów S1, S2,..., Sk. Odwzorowanie wymaga znajomości lokalnych schematów danych. 3. Zapytania Z1,Z2,...,Zk są konstruowane z Z w taki sposób, aby wyniki tych zapytań W1, W2,...,Wk uzyskane z poszczególnych serwerów dały możliwość utworzenia globalnego wyniku W. 4. Zapytania Z1,Z2,...,Zk są kierowane do serwerów S1, S2,..., Sk, gdzie są wykonywane. 5. Serwery zwracają do klienta wyniki W1, W2,...,Wk zapytań Z1,Z2,...,Zk 6. Klient dokonuje scalenia wyników W1, W2,...,Wk w globalny wynik w. Serwer S1 Klient Z1 W1 Z2 Serwer S2 Dekompozycja zapytania Z W2 ... Scalenie wyników Zk Wynik W zapytania Z Serwer Sk Wk

Dynamiczny schemat przetwarzania zapytań 1. Klient realizuje zapytanie Z odwołujące się do danych na serwerach S1, S2,..., Sk 2. Klient dokonuje odwzorowania zapytania Z na podzapytanie Z1 adresowane do serwera S1 (na podstawie schematu S1). Z1jest konstruowane z Z w taki sposób, aby jego wynik W1 uzyskany z S1 wystarczył do realizacji zapytania Z. 3. Z1jest kierowane do serwera S1, gdzie jest wykonywane. Serwer S1 zwraca do klienta wynik W1 podzapytania Z1. 4. Na podstawie znajomości W1 klient konstruuje z Z kolejne podzapytanie Z2 kierowane do serwera S2. Może także do tego serwera skierować pewien fragment W1; .... proces jest powtarzany dla wszystkich serwerów, aż do uzyskania rezultatu. Klient Z  Z1 Z1 W1 Serwer S1 (Z, W1)  Z2, f(W1) Z2, f(W1) W2 Serwer S2 (Z, W1, W2)  Z3, f(W1, W2) Z3, f(W1, W2) W3 Scalenie wyników Serwer S3

Przykład: technika pół-złączeń (1) semijoin Serwer 1 Serwer 2 DOSTAWCA DC DNR D1 D2 D5 NAZW Abacki Bober Erbel STATUS 20 10 30 MIASTO Lublin Poznań Radom DNR D1 D2 D3 D4 CNR C4 C5 C1 C2 ILOŚĆ 200 100 300 400 Klient ma dokonać złączenia relacji DOSTAWCA i relacji DC: select * from DOSTAWCA, DC where DOSTAWCA.DNR = DC.DNR

Przykład: technika pół-złączeń (2) W celu realizacji zapytania klient musi wykonać następujące czynności: 1. Sciagnąć dane z serwera 1przy pomocy zapytania Z1: select * from DOSTAWCA Uzyska w ten sposób wynik W1 2. Uzyskać projekcję na DNR relacji DOSTAWCA: (D1, D2, D5). 3. Wysłać tę projekcję do serwera 2 i dokonać złączenia przy pomocy zapytania Z2: select * from DC where DNR in (D1, D2, D5) Uzyska w ten sposób wynik W2: DNR D1 D2 CNR C4 C5 C1 C2 ILOŚĆ 200 100 300 400 Jest to tzw. pół-złączenie relacji DC, parametryzowane relacją DOSTAWCA 4. Przesłać to pół-złączenie do klienta 5. Dokonać scalenia wyników, czyli złączenia relacji DOSTAWCA (W1) z powyższą relacją (W2). W zależności od oceny kosztów przetwarzania i transmisji klient może oczywiście zacząć od ściągnięcia danych z serwera 2 i następnie dokonać pół-złączenia relacji DOSTAWCA.

Rozproszone BD w standardzie CORBA Oprogramowanie komponentowe budowane wg standardu CORBA może być podstawą rozproszonych/federacyjnych baz danych. Host globalnej aplikacji Host lokalnej BD Obiekty Obiekty Klient Obiekty Implementacja interfejsów do obiektów (szkielety + kod) Wywołanie operacji Pieniek klienta zlecenie Pośrednik (ORB, Object Request Broker) wynik, parametry wyj Implementacja interfejsów do obiektów po stronie serwera powstaje ze szkieletu automatycznie generowanego z wyrażenia IDL, który jest wypełniany kodem operacji. Taki szkielet pełni jednocześnie funkcję osłony oraz funkcję perspektywy. ORB jest w stanie zapewnić autonomię lokalnej BD.

Problemy z RBD w standardzie CORBA CORBA nie jest nastawiona na przetwarzanie danych trwałych i masowych przy pomocy języków zapytań. Jest to poziom języków takich jak C++ i Java, znacznie niższy. Obecny stan standardyzacji w zakresie Query Service i Persistence Service jest uważany za niezadowalający. CORBA nie wprowadza pojęcia perspektywy. Osłony w CORBA są pisane w językach niskiego poziomu, są zorientowane na daną aplikację, nie dają konceptualizacji takiej, jaką dają perspektywy. Mogą być znaczne narzuty na wydajność maszynową i produktywność programistów globalnych aplikacji. CORBA nie wnosi nic do rozwiązania problemów związanych z przetwarzaniem transakcji w rozproszonych/federacyjnych bazach danych. Model obiektowy standardu CORBA jest ograniczony, m.in. nie uwzględnia związków i zagnieżdżonych kolekcji. Te możliwości są uwzględniane w usługach (np. Relationship Service), które nie są realizowane.

Podsumowanie Rozproszone bazy danych mają wiele zalet, w szczególności umożliwiają znaczne obniżenie obciążenia sieci oraz zwiększenia stopnia autonomii i bezpieczeństwa danych. Federacyjne bazy danych są w zasadzie jedynym rozwiązaniem w sytuacji, gdy należy zintegrować wiele baz danych (dziesiątki, setki, tysiące) w jedną całość przy zachowaniu logiki i autonomii dotychczas działających aplikacji. Rozproszone/federacyjne bazy danych rodzą wiele problemów koncepcyjnych, z których niektóre (przezroczystość, przetwarzanie transakcji, przetwarzanie zapytań, bezpieczeństwo,...) nie są do końca rozwiązane. Problemy koncepcyjne oraz coraz niższy koszt łączy powodują, że wielu projektantów decyduje się na scentralizowaną bazę danych raczej niż ryzyko napotkania nieznanych problemów, które mogą wystąpić w rozproszonej/federacyjnej bazie danych.