Systemy rozproszone (SYR)

1. Systemy rozproszone (SYR) Wykład 5: Osłony, mediatory, perspektywy, przetwarzanie rozproszonych zapytań, gridy 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. Osłona wrapper • Jest to moduł oprogramowania umożliwiającyprzystosowanie interfejsu lokalnej bazy danych do pewnego standardu obowiązującego w systemie rozproszonym. • Podstawowe zadanie: fizyczne połączenie różnych baz danych. • Osłona nie zajmuje się bardziej wyrafinowanym odwzorowaniem; chodzi o translację danych, parametrów i wywołań funkcji płynących z zewnątrz lokalnego systemu (o specyficznych formatach i reprezentacji) na analogiczne dane, parametry i funkcje wyrażone w API konkretnego lokalnego systemu bazy danych. • Dla niektórych przypadków, np. dla niektórych stron HTML lub plików XML, napisanie osłony jest bardzo trudnym zadaniem ze względu na nieregularności formatu (dane pół-strukturalne, semi-structured) oraz różnice ontologiczne. • Osłona jest niezbędna do tego, aby budować bardziej wyrafinowane środki odwzorowania schematów i aplikacji, takie jak mediatory i perspektywy

3. Osłony w federacyjnych BD Osłona udostępnia dane i usługi lokalnego systemu i (dostępne w pewnym API i) dla aplikacji globalnych (wykorzystujących wspólny API f). Osłony przystosowują lokalne SZBD do interfejsu programistycznego obowiązującego w federacji. Federacyjny SZBD API f API f API f ... Osłona 1 Osłona 2 Osłona n API 1 API 2 API n Lokalny SZBD 1 Lokalny SZBD 2 Lokalny SZBD n

4. Osłony dla lokalnych relacyjnych SZBD Problem pojawia się wtedy, gdy API f dla federacyjnej bazy danych nie jest oparty o model relacyjny, lecz o model obiektowy a la CORBA lub ODMG. Potencjalne problemy i rozwiązania: • Konieczność silnego ograniczenia modelu obiektowego, np. brak złożonych obiektów, metod, związków, hermetyzacji, polimorfizmu, itd.; • Odwzorowanie krotek tabel na złożone obiekty - wiele krotek składających się na jeden obiekt. Przetwarzanie np. w OQL+Java. Problemy koncepcyjne. • Odwzorowanie obiektowego API, np. OQL +Java na relacyjne API, np. JDBC. Ogólne rozwiązanie jest bardzo trudne. • Zredukowanie API relacyjnej BD do prymitywnych operacji (get first, get next,...), dzięki czemu relacyjną bazę danych można będzie potraktować jako prymitywną obiektową bazę danych. Następnie, zdefiniowanie obiektowych, wirtualnych, aktualizowalnych perspektyw. Problemy koncepcyjne. Problemy z wydajnością.

5. Mediatory mediator • Jest to warstwa pośrednia pomiędzy lokalną bazą danych a globalnymi aplikacjami. • Jest konieczny wtedy, gdy nie ma odwzorowania 1:1 pomiędzy ontologiami. • Np. w jednej bazie podany jest zarobek brutto z ubezpieczeniem, w innej zarobek brutto bez ubezpieczenia. Jak to sprowadzić do wspólnego mianownika? • Zadania mediatora: • Rozstrzyganie rozbieżności pomiędzy schematem lokalnym a schematem federacyjnym. • Wspomaganie dla wyłowienia cech formalnych z danych niesformatowanych. • Selekcja właściwej informacji. • Wspomaganie dla informacji sumarycznych, wyliczalnych oraz o większym stopniu abstrakcji. • Wspomaganie dla wykrywania niezidentyfikowanych związków w danych (eksploracja danych). • Zasady konstrukcji mediatorów nie są jasne. W większości przypadków mediator musi być zaprojektowany ad hoc, pisany techniką niskiego poziomu i przypisany do konkretnej aplikacji (nie uniwersalny).

6. Perspektywy view, database view • Perspektywa (view) jest to odwzorowanie schematu lokalnego w inny (zmodyfikowany) schemat. • Temu odwzorowaniu towarzyszy odwzorowanie danych rzeczywistych lokalnej bazy danych na dane wirtualne lub dane zmaterializowane (wyliczone). • Przykładem są perspektywy w SQL. • Podstawowe problemy: • W przypadku istotnych różnic pomiędzy schematami lokalnymi baz danych, odwzorowanie ich w zadany schemat może być złożone lub niemożliwe. Środki definiowania perspektyw np. w SQL są za mało uniwersalne. • Aktualizacja perspektyw (viewupdating): problem dotychczas nie był rozwiązany w stopniu zadowalającym (obecnie jest wreszcie właściwa koncepcja, ale do zastosowań biznesowych jest bardzo daleko). • Aplikacje (np. w C++) są często przywiązane do fizycznej postaci danych. Odwzorowanie ich w dane wirtualne powoduje, że większość aplikacji przestaje działać. Ograniczenie do zapytań (np. w SQL) silnie redukuje rodzaj aplikacji, które mogą działać na schemacie federacyjnym. • Wydajność (performance) aplikacji.

7. Perspektywa jak schemat zewnętrzny W szerokim znaczeniu: Perspektywą nazywa się odwzorowanie globalnego schematu bazy danych (określającego zapamiętane zasoby danych) na schemat “zewnętrzny”, przystosowany do potrzeb i przyzwyczajeń konkretnego użytkownika. Użytkownik 1 Użytkownik 2 Użytkownik 3 Architektura ANSI/SPARC: Schematy “zewnętrzne” Perspektywa 1 Perspektywa 2 Perspektywa 3 Projektant BD Administrator BD Schemat globalny W tym sensie pojęcie perspektywy funkcjonuje w literaturze z zakresu modeli danych, analizy i projektowania. Poziom fizyczny bazy danych Administrator BD

8. Perspektywa jako odwzorowanie • W wąskim znaczeniu: Perspektywą określa się nazwane odwzorowanie danych zapamiętanych w bazie danych na dane “wirtualne. • Matematycznie, perspektywa jest funkcją określoną na danych. • Ten punkt widzenia nie jest jednak dostatecznie precyzyjny, gdyż nie uwzględnia mechanizmów nazywania, wiązania i zakresu. • Nieco bardziej precyzyjny punkt widzenia: Perspektywa jest procedurą funkcyjną, która (najczęściej, ale niekoniecznie) zwraca wynik będący daną typu masowego (zbiór, wielozbiór, sekwencję). • Taki wynik powinien być wyposażony w dodatkowe nazwy (np. nazwy atrybutów wirtualnych obiektów zwracanych przez perspektywę). • Perspektywy znane z SQL mieszczą się w tej definicji. Ich ciało można sprowadzić do pojedynczego zdania: return <zapytanie SQL> • Najbardziej precyzyjny punkt widzenia: perspektywa jest bytem programistycznym zawierającym definicję odwzorowania danych rzeczywistych na dane wirtualne oraz definicje odwzorowań wszelkich operacji na danych wirtualnych na operacje na danych rzeczywistych.

9. Po co są perspektywy? Istnieje wiele ważnych zastosowań perspektyw, które czynią z nich bardzo gorący i aktualny temat. • Uproszczenie modeli pojęciowych dla poszczególnych użytkowników. • Uproszczenie zapytań poprzez “wyliczane” obiekty, atrybuty, związki. • Dostosowanie się do punktu widzenia i terminologii dziedziny zastosowań • Ograniczenie dostępu do obiektów, ochrona prywatności. • Ograniczenie dostępu w systemach rozproszonych federacyjnych baz danych. • Logiczna niezależność obiektów i aplikacji działający na obiektach. • Współdziałanie systemów heterogenicznych (wspólny schemat). • Przystosowanie systemów spadkowych (legacy) do nowszych technologii i wymagań. • Hurtownie danych: analiza informacji gromadzonych z różnych źródeł.

10. Perspektywy wirtualne • Perspektywa istnieje wyłącznie w postaci definicji (np. zapytania, procedury funkc.). • Wyliczenie (materializacja) następuje w momencie użycia perspektywy. • Wynik jest “konsumowany” i następnie kasowany (tak jak wynik procedury funkcyjnej) . • Zalety: nie ma dublowania danych, problemów aktualizacji wyliczonych danych, problemów z przetwarzaniem transakcji. • Wada: czas ewaluacji perspektyw+czas ewaluacji zapytań używających perspektyw - bez optymalizacji jest bardzo często nieakceptowalny.

11. Perspektywy zmaterializowane • Perspektywa jest wyliczona “na zapas”, jej wynik jest przechowywany w bazie danych na normalnych zasadach. Aktualizacja danych stanowiących podstawę wyliczenia pociąga za sobą aktualizację zmaterializowanej perspektywy (lub jej skasowanie i ewentualnie, ponowne wyliczenie). • Tego rodzaju perspektywy określa się także jako “zdjęcie migawkowe” (snapshot). • Zalety: szybki dostęp, łatwa implementacja. • Wady: dodatkowe zapotrzebowanie na pamięć, dodatkowy koszt aktualizacji zmaterializowanych perspektyw (często prowadzący do problemów koncepcyjnych i realizacyjnych), dodatkowe wąskie gardło dla transakcji.

12. Zasada przezroczystości perspektyw view transparency • Z punkty widzenia użytkownika dowolne operacje na perspektywach nie powinny niczym różnić się od podobnych operacji na zapamiętanych danych. • Np. jeżeli w federacyjnej bazie danych administrator udostępnia tylko część danych poprzez perspektywę, wówczas programista końcowy nie powinien być zmuszany do modyfikacji programów działających na zapamiętanych danych z tego powodu, że mają one teraz działać na perspektywach. • Warunek przezroczystości perspektyw jest trudny, gdyż: • Dla pewnych odwzorowań danych zapamiętanych w wirtualne przyjęte środki definicji perspektyw (np. SQL) mogą okazać się niewystarczające (schematic discrepancies). • Problem aktualizacji perspektyw. • Pewne dane mogą być manipulowane wyłącznie przez przypisane im interfejsy, a nie przez języki zapytań. • Problemy z wydajnością mogą unicestwić rozwiązania trzech poprzednich problemów.

13. Przetwarzanie perspektyw w zapytaniach Obowiązują dwie strategie: Materializacja.Perspektywa jest całkowicie liczona w momencie, kiedy sterowanie programu/zapytania osiągnie punkt, w którym wynik tej perspektywy staje się niezbędny dla dalszego przetwarzania. Każde odwołanie się do perspektywy powoduje jej ponowne wyliczenie (dla uniknięcia niespójności związanych z ewentualną aktualizacją BD). Ta strategia może być optymalizowana poprzez zmaterializowane perspektywy. Modyfikacja zapytań(query modyfication). Tekst zapytania, w którym występuje odwołanie do perspektywy, jest scalany z tekstem definicji perspektywy. Następnie takie rozwinięte zapytanie jest wspólnie optymalizowane na normalnych zasadach. W tej strategii definicja perspektywy jest traktowana jako makro. Ponieważ wcześniejszy SQL nie dopuszczał klauzuli SELECT wewnątrz klauzuli FROM, kwestia banalnego tekstowego zastępowania przybrała cudaczne formy, owocując w super-naukowe “algorytmy” :-) (Stonebraker et al). W SQL-92 tę wadę usunięto. W różnych sytuacjach pierwsza lub druga strategia może być bardziej optymalna, ale najczęściej strategia modyfikacji zapytań jest bardziej skuteczna. Z tego powodu jest ona standardem we wszystkich relacyjnych SZBD.

14. Przetwarzanie zapytań w rozproszonych BD • Przetwarzanie zapytań powinno minimalizować zarówno obciążenie linii transmisyjnych jak i pracochłonność przetwarzania po stronie klienta (globalnej aplikacji) jak i po stronie serwerów. • Przetwarzanie wyłącznie po stronie klienta (gruby klient): ogromne obciążenie linii transmisyjnych. • Przetwarzanie wyłącznie po stronie serwerów (chudy klient): może powstać wąskie gardło wskutek tego, że jednocześnie wielu klientów będzie żądać usługi od jednego serwera. • Generalna zasada: "wyślij zapytanie do danych, a nie dane do zapytanie" nie dla wszystkich przypadków jest słuszna i rodzi problemy koncepcyjne. • 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 oraz ich przetwarzanie przez klienta w celu skonstruowania ostatecznego wyniku zapytania.

15. Strategie optymalizacji zapytań w rozprosz. BD • Przetwarzanie wyłącznie po stronie klienta. Pobiera on wszystkie dane potrzebne do realizacji zapytania do swojego obszaru • Duży czas i koszt transmisji danych, małe problemy koncepcyjne. • "Statyczna" dekompozycja zapytania na podzapytania, wysłanie ich do lokalnych miejsc, przesłanie rezultatów podzapytań do klienta, który łączy tych rezultaty w globalny rezultat. • Skuteczna dla fragmentacji poziomej danych i zapytań ograniczonych do selekcji/projekcji, nieskuteczna dla zapytań złożonych. • "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. • Brak równoległości działania serwerów, trudności koncepcyjne. • Hybrydowa dekompozycja - połączenie dekompozycji statycznej i dynamicznej. • Hybrydowa dekompozycja z przesłaniem danych do serwera. • Klient nie tylko dokonuje wysłania podzapytania do serwera, ale również przesyła do niego część danych, które otrzymał od innych serwerów.

16. Indeksowanie rozproszonych zasobów • Szczególnie istotne w przypadku technologii P2P, ale nie tylko. • Indeks centralny, adresujący całe zasoby rozproszonej sieci. Przykładem wykorzystania indeksów centralnych jest Napster oraz liczne motorki wyszukiwawcze takie jak Google lub AltaVista, • Indeksy lokalne replikowane, trzymane przez klientów celem szybkiego zlokalizowania miejsc z interesującymi danymi. W tym przypadku duża część optymalizacji zapytania może być wykonana przez klienta zanim on wyśle zlecenia do odległych serwerów. • Problem z indeksami centralnymi - zależność całości rozproszonej bazy danych od jednego miejsca. • Problemy z indeksami lokalnymi replikowanymi: • kłopotliwa aktualizacja indeksów • możliwość powstawania niespójności wskutek opóźnień lub braku możliwości aktualizacji indeksów • straty przestrzeni dyskowej

17. Statyczny schemat przetwarzania zapytań (1) 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.

18. Statyczny schemat przetwarzania zapytań (2) • Statyczny schemat ma przede wszystkim zastosowanie w przypadku poziomej fragmentacji danych, np. rozbicia obiektów Pracownik na wiele podzbiorów o takiej samej budowie przechowywanych na poszczególnych serwerach. • W tym przypadku dekompozycja zapytania oznacza po prostu jego skopiowanie: Z = Z1 = Z2 = ... = Zk • Scalenie wyników polega na sumie mnogościowej wyników cząstkowych. Serwer S1 Klient W1 Z1 Z2 Serwer S2 Dekompozycja zapytania Z W2 ... Scalenie wyników Zk Wynik W zapytania Z Serwer Sk Wk

19. 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 do tego serwera skierować pewien fragment W1, nazwijmy go F1; .... proces jest powtarzany dla wszystkich serwerów, aż do uzyskania rezultatu. Z1 Klient Z  Z1 Serwer S1 W1 (Z, W1)  Z2, F1 Z2, F1 W2 Serwer S2 (Z, W1, W2)  Z3, F2 Z3, F2 W3 Serwer S3 Scalenie wyników

20. Technologie gridowe • Grid computing jest nową wersją starego marzenia o masowej równoległości przetwarzania. • Marzenie to miało wiele materializacji, większość nieudanych. • Chyba największą klapę można przypisać japończykom i ich projektowi 5-tej generacji komputerów (1982-1992) – 3 miliardy dolarów utopione w „programowanie w logice” i inne akademickie utopie. • Termin „grid” nawiązuje do ustawienia komputerów w siatkę (klaster). • Nowy termin wzbudza nowe nadzieje i nowe środki przeznaczone na realizację starego marzenia. • Wiele firm i zespołów badawczych skorzysta z tych środków. • Jest to jeden z najlepszych sposobów pozyskiwania pieniędzy. • Temat jest nieustannie fascynujący.

21. Równoległe przetwarzanie • Nowy poziom technologiczny w dużym stopniu już tę równoległość zapewnia: • Rozproszone lub federacyjne bazy danych (np. Oracle10G). • Oprogramowanie komponentowe: CORBA, DCOM, .NET, EJB, RMI, J2EE+WebServices. • Nowe inicjatywy, takie jak OGSA/OGSI lub Enterprise Service Bus (ESB). • Sieci P2P (peer-to-peer), czyli korzystanie z zasobów udostępnianych przez poszczególnych uczestników sieci dla całej społeczności sieci. • Web Services, tj. utylizacja usług dostarczanych przez odlegle serwery na gruncie standardu XML. • Technologie agentowe, czyli mobilni geograficznie niewolnicy wykonujące pracę na rzecz swojego mistrza. • W technologiach gridowych najbardziej istotne będą podejścia nawiązujące do koncepcji federacyjnych baz danych. • Jakkolwiek geneza technologii gridowych jest oparta o zrównoleglenie obliczeń.

22. Krótka ocena • Największe znaczenie mają rozproszone/federacyjne bazy danych, oprogramowanie komponentowe i P2P. • Mój lekki sceptycyzm dotyczy Web Services (mimo licznych inicjatyw potencjalnych zastosowań). • Ubogość koncepcji spowoduje, że będzie ona rosnąć na zasadzie piramidy postawionej na czubku. • Mogą być użyte/przykryte przez bardziej „konceptualne” protokoły. • Niejasny (naiwny?) stosunek do heterogeniczności. • Nowe inicjatywy w tym zakresie, takie jak OGSA/OGSI lub Enterprise Service Bus (ESB) zdają się zmierzać w kierunku federacyjnych heterogenicznych baz danych na zasadzie rozwoju bottom-up. • Mój spory sceptycyzm dotyczy agentów. • Poza antropomorfizmami i pobożnymi życzeniami tam zbyt wiele nie ma. • Brak kluczowych aplikacji (killer applications) pokazujących techniczny lub biznesowy sens pomysłu. • Nadzieje w technologii workflow – ale czy uzasadnione?

23. Najważniejsze problemy • Przezroczystość (transparency): traktowanie rozproszonych zasobów i usług tak, jak gdyby były one wewnątrz przestrzeni adresowej jednego komputera. • Bezpieczeństwo (security): przeciwdziałanie losowym awariom oraz możliwościom ataku z zewnętrz. • Interoperacyjność (interoperability): umożliwienie współpracy heterogenicznych platform, aplikacji, logik biznesowych i organizacji danych. • Efektywność (performance, efficiency): uzyskanie czasów przetwarzania akceptowalnych dla szerokiego kręgu użytkowników rozproszonych aplikacji. • Jakość usług (Quality of Service, QoS): uzyskanie odpowiednich wskaźników dostępności, niezawodności, ergonomii, itp. aspektów.

24. Architektura gridu Schemat lokalny B Schemat lokalny A Perspektywa lokalna B Perspektywa lokalna A Skład lokalnych obiektów i usług Serwer lokalny B Skład lokalnych obiektów i usług Serwer lokalny A ... Klient globalny 1 Klient globalny 2 Klient globalny 3 Schemat globalny (model kanoniczny) Globalny wirtualny skład obiektów i usług Aktualizowalne perspektywy Protokół komunikacyjny Organizator gridu Informacja kontrybucyjna ...

25. Objaśnienie architektury (1) • Linie ciągłe grube: związki między oprogramowaniem w run-time (zapytania, zlecenia, odpowiedzi). • Linie i strzałki przerywane: związki definicyjne (podczas tworzenia oprogramowania). • Klient globalny: program aplikacyjny wykorzystujący globalny wirtualny skład. • Globalny wirtualny skład obiektów i usług: skład, do którego adresowane są zapytania i zlecenia ze strony klienta globalnego; w rzeczywistości nie istnieje. • Schemat globalny: definicje obiektów i usług wirtualnych wykorzystywane (głównie) przez programistów podczas tworzenia klientów globalnych.

26. Objaśnienie architektury (2) • Aktualizowalne perspektywy: oprogramowanie, którego celem jest wytworzenie globalnego wirtualnego składu. • Wykorzystanie aktualizowalnych perspektyw: • jako integratora wielu rozproszonych danych i serwisów • jako osłon i mediatorów dla poszczególnych lokalnych serwerów. • Protokół komunikacyjny: zestaw funkcji działających na odległych serwerach używanych do definicji perspektyw. • Organizator gridu: osoba, zespół osób lub program definiujący perspektywy na podstawie schematów lokalnych, sch.globalnego i i informacji kontrybucyjnej. • Schemat lokalny: informacja katalogowa o obiektach i usługach udostępnianych przez serwer lokalny (IDL, WSDL, ODL, ...) • Serwer lokalny: jednostka sprzętowa/programowa identyfikowana przez system rozproszony.

27. Informacja kontrybucyjna • Określa w jaki sposób poszczególne serwery kontrybuują do globalnego wirtualnego składu obiektów. • Określa redundancje w danych trzymanych na poszczególnych serwerach. • Określa replikacje. • Określa sposoby aktualizacji danych. • Określa zależności pomiędzy poszczególnymi serwerami. • Jest podstawą definicji odpowiednich perspektyw.

28. Przykład: fragmentacja pozioma Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Schemat globalny: • Informacja kontrybucyjna: • Jednoznacznym identyfikatorem pracowników jest NIP. • Nie występują powtórzenia NIPu w lokalnych bazach danych. • Globalna baza danych jest wirtualną sumą lokalnych baz danych. Schematy lokalne: Kalisz Radom Kielce

29. Integrująca perspektywa • Ziarno obiektów wirtualnych ma postać dwóch binderów: struct{ m(adres serwera), p(OID obiektu na tym serwerze)} • Nazwy Kalisz, Radom i Kielce są niewidoczne dla klientów; posługują się oni tylko nazwą MoiPrac i nazwami atrybutów, np. (MoiPracwhereNazwisko = ”Kolski”).NIP create viewMoiPracDef { virtual objectsMoiPrac { return((Kalisz as m)join(m.Prac as p))  (((Radom as m)join (m.Prac as p)) (((Kielce as m)join (m.Prac as p)) } on_retrieve do { connect (m); returnp.(deref(NIP) asNIP, deref(Nazwisko) asNazwisko, deref(Zar) asZar, deref(Stan) asStan) }; on_delete do { connect (m); remoteDelete (p) }; ... Ewentualnie dalsze części definicji perspektywy... }

30. Przykład: fragmentacja pozioma z replikacją Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Prac NIP Nazwisko Zar Stan Schemat globalny: • Informacja kontrybucyjna: • .... jak poprzednio.... • Radom i Kielce zawierają te same dane. • Użytkownik powinien używać tej repliki, do której ma szybszy dostęp. • Aktualizacja danych w Radomiu spowoduje tę samą aktualizację danych w Kielcach. • Użytkownik nie może aktualizować danych w Kielcach. Schematy lokalne: Kalisz Radom Kielce

31. Integrująca perspektywa create viewMoiPracDef { virtual objectsMoiPrac { intczasDoRadomia := 1000000; intczasDoKielc := 1000000; if alive(Radom) then czasDoRadomia := checkAccessTime(Radom); if alive(Kielce)then czasDoKielc := checkAccessTime(Kielce); ifmin(bag(czasDoRadomia, czasDoKielc)) > 100 then { exception(CzasRealizacjiJestNieakceptowalny); return;} return((Kalisz as m)join(m.Prac as p))  ifczasDoRadomia < czasDoKielc then ((Radom as m)join (m.Prac as p)) else ((Kielce as m)join (m.Prac as p)) } on_retrieve do { ...jak poprzednio... }; on_delete do { ifserverName(m) = ”Kielce” then { connect(Radom); remoteDelete (PracwhereNIP = (p.NIP))} else { connect (m); remoteDelete (p)} }} alive, checkAccessTime, serverName, connect, remoteDelete, ... – funkcje protokołu

32. Problemy do rozwiązania • Zaimplementowanie aktualizowalnych perspektyw. • Ustalenie i zaimplementowanie zestawu funkcji protokołu komunikacyjnego, które są niezbędne dla definicji perspektyw. • Opracowanie precyzyjnego języka informacji kontrybucyjnej: • Pełna formalizacja tego języka, wraz z formalizacją globalnego i lokalnych schematów, umożliwiłaby automatyczną generację perspektyw. • Przypisania informacji kontrybucyjnej do pojedynczych serwerów i automatyczne uzupełnianie perspektyw na jej podstawie stworzyłoby coś w rodzaju szyny CORBA lub sieci P2P. • Opracowanie systemu rejestracji danych i usług (trading service, UDDI, ...) • Przetwarzanie rozproszonych transakcji. • Optymalizacje zmierzające do uzyskania odpowiedniego QoS, w szczególności optymalizacja rozproszonych zapytań.

33. Optymalizacje • W przedstawionej koncepcji całość przetwarzania zapytań jest po stronie klienta. Trzeba to przetwarzanie przesunąć na stronę serwera, np. poprzez przesłanie tam odpowiednich części stosów i (pod-) zapytań. • Obecna koncepcja nie zakłada równoległości przetwarzania. Przesunięcie przetwarzania na stronę serwera i analiza postaci zapytania stwarzają szansę na równoległość (jest to dość łatwe dla fragmentacji poziomej, trudniejsze w ogólnym przypadku). • Dekompozycja zapytań przy fragmentacji pionowej. • Wykorzystanie scenariuszy dynamicznych, w których wynik przetwarzania na jednym serwerze jest wykorzystany do optymalizacji przetwarzania na innym serwerze. • Obiekty i usługi „proxy” ulokowane wewnątrz perspektywy integrującej. • Przezroczyste indeksy zasobów globalnych wykorzystywane automatycznie przez klientów i/lub perspektywy. • ..... wiele innych optymalizacji...

34. Podsumowanie (1) • Globalizacja przestrzeni informacyjnej powoduje nacisk na tworzenie rozproszonych i federacyjnych baz danych, które umożliwiłyby tworzenie aplikacji globalnych, działających na zestawie dziesiątków, tysięcy lub milionów lokalnych BD. • Połączenie tych lokalnych baz danych siecią komputerową stwarza niezbędną infrastrukturę techniczną, ale nie rozwiązuje ogromnej ilości problemów koncepcyjnych, których część została omówiona na tym wykładzie. • Pewna część problemów jest rozwiązana dla rozproszonych relacyjnych baz danych. Rozproszone obiektowe bazy danych znajdują się na początku drogi. • Niektóre problemy, takie jak: przetwarzanie globalnych transakcji, aktualizowalne perspektywy, rozstrzyganie niezgodności schematów, akceptowalna wydajność globalnych aplikacji, itd., prawdopodobnie nie mają ogólnego rozwiązania. Pozostają nadzieje na rozwiązania cząstkowe.

35. Podsumowanie (2) • Problemy rozproszenia są skutkiem “spadku” pozostawionego nam przez naszych poprzedników. Znaczna część problemów może rozwiązać się sama poprzez rezygnację ze spadku, tj. poprzez wymarcie kłopotliwych SZBD i powstanie nowych SZBD, lepiej przystosowanych do tworzenia rozproszonych federacji. • Konieczna jest standardyzacja: • w zakresie modeli danych • w zakresie ontologii biznesowej i metamodeli • w zakresie wymiany danych • w zakresie API realizującego dostęp do do danych, w szczególności języków zapytań • Konieczne są dalsze prace badawcze i wdrożeniowe w zakresie przetwarzania i optymalizacji rozproszonych obiektowych zapytań, protokołów dostępu, obiektowych perspektyw, ontologii, metamodeli, formatów wymiany danych, rozproszonych transakcji, itd.