Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 5 Wprowadzenie do rozproszonych i federacyjnych baz danych Polsko-Japońska Wyższa Szkoła Technik.

Podobne prezentacje


Prezentacja na temat: "Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 5 Wprowadzenie do rozproszonych i federacyjnych baz danych Polsko-Japońska Wyższa Szkoła Technik."— Zapis prezentacji:

1 Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 5 Wprowadzenie do rozproszonych i federacyjnych baz danych Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wykładowca: dr hab. inż. Kazimierz Subieta profesor PJWSTK Niniejszy materiał jest dostępny pod:

2 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 2 październik 2001 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 d wufazowe potwierdzenie (2PC) Przetwarzanie zapytań w rozproszonych bazach danych Rozproszone BD w standardzie CORBA

3 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 3 październik 2001 Co to jest rozproszona baza 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. Czy fakt, że z pewnego systemu można dostać się do danych innego odległego systemu jest wystarczającym wyróżnikiem rozproszonej bazy danych? distributed database

4 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 4 październik 2001 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.

5 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 5 październik 2001 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.

6 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 6 październik 2001 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.

7 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 7 październik 2001 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.

8 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 8 październik 2001 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.

9 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 9 październik 2001 Główne aspekty rozproszenia baz danych 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. 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) Przezroczystość (transparency) Współdziałanie (interoperability)

10 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 10 październik 2001 Co to jest Federacyjna Baza Danych? 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. Federated Database

11 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 11 październik Sieć komputerowa Architektura federacyjnej bazy danych Lokalny SZBD 1 Schemat eksportowy 1 Osłona 1 API 1 BD 1 Aplikacje lokalne FSZBD 1 Przestrzeń robocza Aplikacje globalne Schemat FBD Lokalny SZBD 2 Schemat eksportowy 2 Osłona 2 API 2 BD 2 Aplikacje lokalne Lokalny SZBD n Schemat eksportowy n Osłona n API n BD n Aplikacje lokalne FSZBD m Przestrzeń robocza Aplikacje globalne Schemat FBD...

12 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 12 październik 2001 Replikacje Technologia replikacji oznacza przechowywanie dwóch lub więcej kopii danych (replik) w oddalonych geograficznie miejscach. 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 Cele:

13 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 13 październik 2001 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.

14 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 14 październik 2001 Modele replikacji Transakcja aktualizacyjna Replika 2Replika 1Replika 3 Transakcja aktualizacyjna Replika 2 Replika 1Replika 3 propagacja aktualizacji propagacja aktualizacji Transakcja aktualizacyjna Replika 2 Replika 1 Replika 3 planowana aktualizacja planowana aktualizacja Transakcja czytaj ą ca Transakcja czytaj ą ca Jednoczesne aktualizacje ze sterowaniem współbieżnościa Propagacja aktualizacji Planowane odświeżanie kopii dla replik tylko do czytania

15 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 15 październik 2001 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.

16 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 16 październik 2001 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:

17 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 17 październik 2001 Dwufazowe potwierdzenie (2PC) Program aplikacyjny klienta SZBD klienta 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. SZBD serwera gotów potwierdź

18 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 18 październik 2001 Przetwarzanie zapytań 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) 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. Przetwarzanie zapytań powinno minimalizować obciążenie linii transmisyjnych.

19 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 19 październik 2001 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. Dekompozycja zapytania Z Serwer S1 Serwer S2 Serwer Sk Scalenie wyników... Klient Wynik W zapytania Z Z1 Z2 Zk W1 W2 Wk

20 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 20 październik 2001 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. Z Z1 Serwer S1 Serwer S2 Serwer S3 Scalenie wyników Klient Z1 Z2, f(W1) W1 W2 W3 (Z, W1) Z2, f(W1) (Z, W1, W2) Z3, f(W1, W2) Z3, f(W1, W2)

21 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 21 październik 2001 Przykład: technika pół-złączeń (1) DOSTAWCA DNR D1 D2 D5 NAZW Abacki Bober Erbel STATUS MIASTO Lublin Poznań Radom DC DNR D1 D2 D3 D4 CNR C4 C5 C1 C2 C4 C5 ILOŚĆ Serwer 1Serwer 2 semijoin Klient ma dokonać złączenia relacji DOSTAWCA i relacji DC: select * from DOSTAWCA, DC where DOSTAWCA.DNR = DC.DNR

22 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 22 październik 2001 Przykład: technika pół-złączeń (2) 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ŚĆ 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 celu realizacji zapytania klient musi wykonać następujące czynności: 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.

23 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 23 październik 2001 Rozproszone BD w standardzie CORBA Oprogramowanie komponentowe budowane wg standardu CORBA może być podstawą rozproszonych/federacyjnych baz danych. Host globalnej aplikacji Klient Wywołanie operacji Host lokalnej BD Pośrednik (ORB, Object Request Broker) 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. Pieniek klienta Implementacja interfejsów do obiektów (szkielety + kod) zlecenie wynik, parametry wyj Obiekty

24 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 24 październik 2001 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.

25 K.Subieta. Systemy Rozproszone, Wykład 5, Slajd 25 październik 2001 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.


Pobierz ppt "Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 5 Wprowadzenie do rozproszonych i federacyjnych baz danych Polsko-Japońska Wyższa Szkoła Technik."

Podobne prezentacje


Reklamy Google