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 12: Architektury rozproszonych baz danych, replikacje, transakcje, heterogeniczność, federacyjne bazy danych

Przyszłościowa architektura aplikacji internetowych Przeglądarka WWW Przeglądarka WWW Warstwa klienta XML XML Serwer Web Serwer aplikacji Warstwa aplikacji globalnych Aplikacja globalna Aplikacja globalna Aplikacja globalna Interakcja z aplikacjami poprzez protokoły oparte na XML Globalny wirtualny skład zasobów usług i danych Logiczna warstwa pośrednia Web Services Zasoby usług i danych Serwisy lokalne Serwisy lokalne Serwisy lokalne Serwisy lokalne Serwisy lokalne Serwisy lokalne wrappery Relacyjna baza danych Obiektowo-relacyjna baza danych Obiektowa baza danych XML-owa baza danych Dokumenty XML na Webie Inne dokumenty na Webie: HTML, Word,... Zasoby danych

Standardy łączenia rozproszonych danych (1) Open DataBase Connectivity (ODBC): standard [zdalnego] dostępu do relacyjnych baz danych bazuje na Call Level Interface (CLI) opracowanym przez konsorcjum X/Open definiuje API oraz cechy SQL które muszą być zapewnione na różnych poziomach zgodności. Java DataBase Connectivity (JDBC): analogiczny do ODBC standard dla Java. OLE-DB: API podobne do ODBC, ale wspomagające źródła nie-bazodanowe, takie jak płaskie pliki. OLE-DB program może negocjować ze źródłem danych aby znaleźć własności, które ono podtrzymuje. API jest podzbiorem SQL ADO (Active Data Objects): łatwy interfejs do funkcji OLE-DB

Standardy łączenia rozproszonych danych (2) Kilka standardów bazujących na XML dla E-commerce Np. RosettaNet (łańcuchy dostaw), BizTalk Definiują katalogi, opisy usług, faktury, zamówienia, itd. osłony XML są używane do eksportu informacji z relacyjnej BD do XML Resource Description Framework (RDF): specyfikacja ontologii dla zasobów Web. Web Services i Simple Object Access Protocol (SOAP): bazujący na XML standard dla zdalnego wołania usług. SOAP jest mniej elastyczny i uniwersalny w stosunku do CORBA. Używa XML do zakodowania danych, HTTP jako protokołu transportowego Kilka dalszych standardów: WSDL (opis danych i usług), UDDI (rejestry usług), itd. Dalsze standardy są oparte na SOAP dla specyficznych aplikacji, np. OLAP i Data Mining (standardy Microsoft'u)

Standardy łączenia rozproszonych danych (3) Object Data Management Group (ODMG) standard obiektowych baz danych jest raczej używany hasłowo, nie jest znana całościowa implementacja. OMG CORBA (Common Object Request Broker Architecture) - najbardziej uniwersalny standard obejmujący ogromną liczbę aspektów. W szczególności, notacja UML jest jego składową. Pakiety ORB (Object Request Broker) są oprogramowaniem realizującym tę architekturą. .NET/DCOM (Distributed Component Object Model) - standard Microsoftu zintegrowany z systemami operacyjnymi Microsoftu. Ograniczony w stosunku do standardu CORBA. RMI (Remote Method Invocation) - oprogramowanie firmy Sun, ograniczone w stosunku do standardu CORBA do oprogramowania pisanego w Java. Java Beans i Enterprise Java Beans wykorzystują RMI jako transport.

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 aktualizująca Transakcja aktualizująca propagacja aktualizacji propagacja aktualizacji Replika 3 Replika 1 Replika 1 Replika 2 Replika 3 Replika 2 Planowane odświeżanie kopii dla replik tylko do czytania Transakcja aktualizująca planowana aktualizacja Transakcja czytająca planowana aktualizacja Replika 3 Replika 1 Transakcja czytająca Replika 2

Wady replikacji Konieczna dodatkowa przestrzeń dyskowa Możliwość powstania niespójności pomiędzy repliką i oryginałem => zagrożenie dla spójności procesów biznesowych Np. jeżeli dane o wysokości kont są powtórzone w wielu miejscach, wówczas ktoś korzystając z (celowo) uszkodzonych linii transmisyjnych może dokonać nielegalnych wypłat. Zwiększenie kosztów aktualizacji danych: aktualizacja oryginału pociąga za sobą dodatkowy koszt aktualizacji replik reguła kciuka (bardzo uproszczona): Przy dokładnej analizie należy utworzyć bardziej złożone modele kosztów, które ustalą opłacalność replik. ilość zapytań czytających ilość zleceń aktualizujących Jeżeli > ilość replik to warto tworzyć repliki. W przeciwnym przypadku - nie warto.

Przetwarzanie transakcji Problemy z transakcjami w systemach rozproszonych: 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: 2PC, 3PC. Zakleszczenie: wykrywanie i usuwanie jest znacznie trudniejsze, gdyż wymaga przesyłania w sieci informacji która transakcja czeka na którą. 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; stąd 2PC i 3PC są często nieadekwatne. Długie transakcje: konieczność zmniejszenia poziomu izolacji aby umożliwić dostęp do zablokowanych danych.

Implementacja transakcji poprzez zamki Zamek (lock): jedna z transakcji rezerwuje sobie dostęp do obiektu. Spójność przetwarzania transakcji jest zachowana, jeżeli cała transakcja ma dwie fazy: rosnącą i skracającą. potwierdzenie (commit) koniec start zakładanie zamków (nie ma zwalniania) zwalnianie zamków (nie ma zakladania) czas Awaria w fazie potwierdzenia jest krytyczna, gdyż grozi utratą spójności. W systemach rozproszonych faza potwierdzenia może trwać minuty i włącza zawodne zawodne elementy infrastruktury (łącza). Warunek atomowości oznacza, że jeżeli transakcja dzieli się na wiele podtransakcji wykonywanych na odległych serwerach, to nie może zajść sytuacja, gdy podtransakcja na serwerze A jest potwierdzona, zaś podtransakcja na serwerze B jest zerwana. Stąd konieczność dodatkowej ochrony fazy potwierdzenia => 2PC.

Dwufazowe potwierdzenie (2PC) Koordynator (program aplikacyjny klienta) SZBD klienta potwierdź potwierdź potwierdź gotów gotów gotów SZBD serwera 1. Serwery wysyłają komunikaty “gotów “ do koordynatora. 2. Po skompletowaniu wszystkich zgłoszeń koordynator wysyła komunikat “potwierdź” do wszystkich serwerów. Jeżeli nie nadejdą wszystkie zgłoszenia “gotów”, koordynator wysyła komunikat “zerwij transakcję” do wszystkich serwerów. Wada: duże straty wykonanej pracy w przypadku zerwania.

2PC - zarządzanie awariami Dość złożone postępowanie zależne od tego, czy awarii uległ serwer czy też koordynator. Protokół 2PC określa: Czas graniczny (timeout) nadesłania sygnału "gotów" od wszystkich serwerów do koordynatora . Jeżeli czas graniczny minął oraz nie ma wszystkich sygnałów "gotów", to koordynator wysyła do wszystkich serwerów sygnał "zerwij". Sposób rejestracji sygnałów od koordynatora w dzienniku serwera. W razie awarii serwera, po jego ponownym postawieniu, analizowany jest dziennik celem stwierdzenia, czy transakcja ma być potwierdzona, czy zerwana. Problem blokowania: w razie awarii koordynatora wszystkie transakcje na serwerach, które zgłosiły "gotów" są przyblokowane. Serwery "nie wiedzą", co dalej robić. Postawienie koordynatora może trwać długo. Bardziej złożony protokół 3PC uwzględnia awarie koordynatora . 3PC nie znalazł jednak szerszego zastosowania ze względu na duże narzuty na wydajność aplikacji.

Transakcje w federacyjnej bazie danych (1) Lokalne transakcje są wykonywane autonomicznie przez lokalny SZBD. Federacja nic o nich nie wie i (z reguły) nie może się dowiedzieć. Globalne transakcje są wykonywane przez aplikacje globalne. Mogą składać się z wielu podtransakcji, wykonywanych przez lokalne SZBD. Z punktu widzenia lokalnego SZBD podtransakcja globalnej transakcji jest normalną lokalną transakcją. W związku z tym, zapewnienie szeregowalności globalnych transakcji (niezbędny warunek dla utrzymania spójności przetwarzania) w FBD jest trudne lub wręcz niemożliwe. Dlaczego? - następny slajd.

Transakcje w federacyjnej bazie danych (2) Lokalne bazy danych mogą stosować różnorodne algorytmy przetwarzania transakcji. Autonomia oznacza, że federacja nie ma wpływu na te algorytmy. Lokalna BD może w każdej chwili z różnych powodów (np. zakleszczenia) zerwać dowolną transakcję, w tym podtransakcję indukowaną przez globalną transakcję. Informacja o wewnętrznym stanie lokalnie przetwarzanych transakcji (np. stan dziennika transakcji, zamki zakładane przez transakcje, itd.) nie jest widoczna na zewnątrz. Stosowanie typowych algorytmów, np. 2PC (two phase commit) jest niemożliwe, gdyż lokalna BD może nie posiadać możliwości zawieszenia podtransakcji w stanie “gotowa” i czekać na sygnał potwierdź ze strony globalnej transakcji.

Niezgodności schematów schematic discrepancies Przy integracji niezależnie zaprojektowanych baz danych w jeden schemat należy się liczyć z tym, że organizacja, struktura i semantyka danych będzie niezgodna. Nie istnieje ani “jeden” ani “najlepszy” sposób odwzorowania dziedziny przedmiotowej w struktury danych zapamiętane w bazie danych. Różni projektanci projektują całkowicie odmienne struktury dla tego samego problemu. Dlaczego? Obiekty tej samej dziedziny problemowej mogą być widziane przez różnych projektantów całkowicie odmiennie. Systemy zarządzenia BD mają ograniczenia struktur danych, które wymuszają sposób myślenia projektantów nad koncepcją struktur danych. Różne środki manipulacji strukturami dostarczane przez SZBD wymuszają często różną koncepcję. Projektanci podejmują różnorodne decyzje co do koncepcji struktur danych w związku z zamierzonymi własnościami użytkowymi, np. szybkością dostępu.

Niezgodności ontologii w rozproszonych BD (1) Są one poważną przeszkodą, która pojawia się podczas konstruowania federacyjnych rozproszonych BD. Niezgodności te dotyczą różnych aspektów organizacji i działania: Niezgodności pomiędzy modelami danych: relacyjna vs. obiektowa vs. hierarchiczna XML-owa, itd. Niezgodności pomiędzy schematami pojęciowymi. Np. w jednej BD informacja o dzieciach pracownika jest atrybutem jego obiektu, zaś w innej jest związkiem łączącym obiekt pracownika z obiektami osób. W zależności od BD te same dane mogą występować raz jako nazwy (obiektów, atrybutów), a raz jako ich wartości. Nawet gdy zespoły stosują tę samą metodykę projektowania, to na ogół ich projekty pojęciowe są zasadniczo różne. Niezgodności pomiędzy schematami logicznymi. Można oczekiwać, że w niezależnie zbudowanych bazach danych nazwy obiektów, nazwy atrybutów oraz ich zestaw będą inne. Mogą występować poważniejsze różnice w zakresie organizacji logicznej; np. w pewnej lokalnej bazie danych informacja o pracownikach może być rozbita na dwie lub więcej tablic.

Niezgodności ontologii w rozproszonych BD (2) Niezgodności w zakresie interpretacji semantycznej danych. W jednej bazie danych zarobek pracownika może być zarobkiem brutto, w innej - netto, zaś jeszcze w innej może być rozbity na pensję, premię i dodatki. Niezgodności dotyczące budowy i środków dostępu do katalogów. W relacyjnej BD katalog jest zbiorem relacji dostępnym przy pomocy SQL, w innej bazie katalog może nie istnieć explicite, zaś informacje katalogowe są dostępne poprzez zmienne środowiskowe oraz specjalne procedury i funkcje. Niezgodności dotyczące reprezentacji danych. W jednej BD informacja o zawodzie pracownika jest przechowywana na przykład w postaci ciągu znaków, a w innej przy pomocy numeru zawodu i specjalności, którym towarzyszy tabela umożliwiająca interpretację (niekoniecznie przechowywana w BD). Mogą występować różnice w reprezentacji dat, czasu i innych atrybutów, różnice w zakresie precyzji reprezentacji wielkości liczbowych oraz zarezerwowanych długości obszarów dla wartości znakowych, itp.

Niezgodności ontologii w rozproszonych BD (3) Niezgodności dotyczące odniesienia danych do skali czasowej. Informacje mogą być np. aktualizowane natychmiast, zaś w innej BD raz na miesiąc. Niezgodności w sposobach dostępu. W jednej BD dostęp do danych będzie realizowany na przykład przy pomocy standardowego SQL, a w innej poprzez środki dostępu pewnego języka czwartej generacji lub API. Różna strukturalizacja informacji. Np. w jednej BD utworzono odrębną tabelę PrzynależnośćDoZwiązkuZawodowego, zaś w innej ta przynależność jest atrybutem tabeli Pracownik; w jednej BD atrybut Adres jest polem tekstowym, w innej zaś strukturą z polami Miejscowość, Ulica, NrDomu, itd. Podział danych i metadane. Np. w jednej BD atrybut Zawód tabeli Pracownicy jest stringiem, zaś w innej utworzono odrębne tabele. Piekarze, Stolarze, itd. Niezgodności jest bardzo dużo. Niezależnie zbudowane lokalne bazy danych zawsze będą obciążone tego rodzaju konfliktami.

Kanoniczny model danych canonical data model Jeżeli wiele baz danych ma tworzyć jedną federacyjną bazę danych w której będzie obowiązywać jeden wspólny API f, wówczas potrzebny jest model danych w terminach którego dadzą się wyrazić wszystkie inne modele danych. Model powinien także uwzględniać fakt, że w federacji mogą pojawić się nowe bazy danych, których założeń nie rozpatrywaliśmy podczas jej tworzenia. Który z modeli danych mógłby być podstawą takiego kanonicznego modelu danych? Relacyjny? Encja-związek? UML? CORBA? ODMG? Jakiś inny?

Wybór kanonicznego modelu danych Jeżeli nie chcemy debaty religijnej o wyższości modelu A nad B, to powstaje pytanie o obiektywne kryteria. Czy istnieją? Debata nad kanonicznym modelem danych traktuje modele danych jako obiektywne byty o ostro zarysowanych własnościach i granicach. Nie jest to słuszne. Modele danych są tworami subiektywnymi, o niejasnych granicach, podlegają ciągłej ewolucji, możliwe są różnorodne ich mutacje i rozszerzenia. Istnieje potencjalnie wiele modeli relacyjnych i wiele modeli obiektowych. Niektóre modele danych są bardzo rozbudowane: język zapytań jako składowa modelu ograniczenia integralnościowe cechy obiektowości określane jak behaviour Niektóre są bardzo proste, a reszta jest swobodnie kształtowana: np. XML, w istocie ograniczony do prymitywnej konwencji składniowej

Kryteria wyboru kanonicznego modelu danych Ekspresyjność (expressiveness): w jakim stopniu dany model jest w stanie bezpośrednio odwzorować pojęcia z modelu pojęciowego dziedziny aplikacyjnej oraz definiować nowe operacje, typy danych i więzy integralności. Np. model relacyjny nie ma bezpośrednich odwzorowań złożonych obiektów, dziedziczenia, agregacji, informacji behawioralnych, itd., wobec czego ma niską ekspresyjność. Pod tym względem model obiektowy ma przewagę. Relatywizm semantyczny (semantic relativism): stopień, w jakim dany model umożliwia wiele punktów widzenia na tę samą dziedzinę aplikacyjną. Miarą relatywizmu semantycznego danego modelu jest możliwość budowania dowolnych schematów zewnętrznych (perspektyw) nad schematem bazy danych. Model relacyjny posiada pewien stopień relatywizmu, dzięki jego zdolności definiowania perspektyw (ograniczonej, szczególnie w zakresie aktualizacji perspektyw). Definiowanie perspektyw nie jest mocną stroną systemów obiektowych, jakkolwiek nie istnieją tu ograniczenia koncepcyjne.

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 (schematem kanonicznym) 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. Obecnie zamiast terminu FSZBD używa się grid, lub data-intensive grid.

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

Architektura dostępu do lokalnej BD Global schema (in an extended ODL) External sub-schemata (through an accessibility matrix) Lokalna baza danych Lokalny schemat eksportowy Zewnętrzne podschematy użytkowników (macierz dostępu) Zewnętrzny podschemat 1 Zewnętrzny podschemat 2 Zewnętrzny podschemat 3 Obiekty A Dane A Interfejs IA1 Dostęp Zakaz Zakaz Interfejs IA2 Zakaz Zakaz Dostęp Obiekty A Dane B Interfejs IB1 Dostęp Zakaz Dostęp API Osłona Mediator Obiekty A Dane C Interfejs IC1 Zakaz Dostęp Zakaz Ob.wirt. V3 Dane wirt. V1 Perspektywa V1 Zakaz Dostęp Dostęp Ob.wirt. V3 Dane wirt. V2 Perspektywa V2 Dostęp Zakaz Zakaz ustala definiuje Administrator lokalnej bazy danych Użytkownik 1 Użytkownik 2 Użytkownik 3

3-warstwowa architektura federacyjnej BD Użytkownik 1 Użytkownik 2 Użytkownik 3 3 Schemat zewnętrzny 1 Schemat zewnętrzny 2 Schemat zewnętrzny 3 2 Schemat federacyjny FSZBD Przestrzeń robocza Sieć 1 Schemat eksportowy 1 Osłona 1 API 1 Schemat eksportowy 2 Osłona 2 API 2 ... Lokalny SZBD 1 Lokalny SZBD 2 BD 1 BD 2

Przetwarzanie zapytań w FBD Podstawowe algorytmy przetwarzania zapytań w homogenicznych i federacyjnych relacyjnych BD są podobne. Różnice dotyczą cech autonomii i heterogeniczności, które znacznie komplikują problem. Algorytmy polegają na dekompozycji zapytania na pewne podzapytania kierowane do lokalnych BD, następnie na skomponowaniu globalnego wyniku z wyników cząstkowych zwróconych przez lokalne BD. Komplikacje Niezgodności schematów, które wymagają mechanizmu refleksji lub nowych operatorów w SQL. Brak algorytmicznej uniwersalności SQL. Ograniczona moc mechanizmu definiowania perspektyw. Problem został rozwiązany dla niektórych przypadków, ale nie dla generalnego. Wygląda na to, ze w ramach obecnych paradygmatów modelu relacyjnego niewiele więcej da się zrobić. W obiektowych bazach danych problem jest na początku drogi.

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 rozwiązuje problemów związanych z przetwarzaniem transakcji w rozproszonych/federacyjnych bazach danych. Model obiektowy 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.