Systemy rozproszone (SYR)

1
Systemy rozproszone (SYR)
Wyklad 3 Projektowanie i architektury
rozproszonych baz danych
Wykladowca Kazimierz Subieta Polsko-Japonska
Wyzsza Szkola Technik Komputerowych,
Warszawa subieta_at_pjwstk.edu.pl Instytut Podstaw
Informatyki PAN, Warszawa subieta_at_ipipan.waw.pl
2
Podejscia do projektowania rozproszonych BD
top-down i bottom-up

• Od ogólu do szczególów (top-down) Odgórne
  zaprojektowanie calej bazy danych, z
  uwzglednieniem optymalizacji przechowywanych
  danych, narzuconej przez fakt geograficznego
  rozproszenia producentów i konsumentów informacji
  przechowywanej w bazie danych.
• Od szczególów do ogólu (bottom-up) Zintegrowanie
  juz istniejacych (spadkowych) lub
  zaprojektowanych lokalnych baz danych w jedna
  globalna rozproszona baze danych.

3
Projektowanie podejscie top-down
Analiza

• Analiza systemowa rozpoznanie wymagan,
  precyzowanie kontekstu przyszlej bazy danych.
• Projektowanie schematu pojeciowego
• Projektowanie struktury logicznej
• Kryteria rozproszenia sa zwiazane z faktem
  fizycznego rozproszenia zródel i odbiorców danych
  oraz autonomii lokalnych baz danych.
• Ustalaja one decyzje, które fragmenty projektu
  pojeciowego beda przechowywane w poszczególnych
  miejscach, a takze jak nalezy zdekomponowac
  schemat logiczny na poszczególne miejsca

Model pojeciowy scentralizowany
Model logiczny scentralizowany
Kryteria rozproszenia
Modele logiczne dla poszczególnych miejsc
4
Dalsze fazy postepowania w podejsciu top-down

• Okreslenie danych podlegajacych replikacjom
  (lokalnych kopii) oraz strategii replikacji.
• Zróznicowanie logicznego schematu danych w
  zaleznosci od typu SZBD w poszczególnych
  miejscach.
• Okreslenie lokalnych schematów dla poszczególnych
  miejsc.
• Okreslenie danych autonomicznych dla
  poszczególnych miejsc, nie uczestniczacych w
  rozproszonej bazie danych co prowadzi do
  okreslenia schematu pojeciowego i logicznego dla
  danych widzianych z zewnatrz.
• Podzial schematu logicznego Wg róznych regul
  zwiazanych na ogól z fizycznym ulokowaniem
  obiektów rzeczywistych (np. osób zatrudnionych,
  sprzetu, co pociaga za soba odpowiedni podzial
  schematu logicznego) lub tez z fizycznym
  ulokowaniem programów aplikacyjnych dzialajacych
  na tych obiektach.

5
Podstawowe metody fragmentacji schematu

• Fragmentacja pionowa oznacza przyporzadkowanie
  poszczególnych klas obiektów do poszczególnych
  miejsc, lub rozbicie obiektów danej klasy na dwa
  lub wiecej podobiektów, przy czym takie
  podobiekty sa przechowywane w róznych miejscach.
• Fragmentacja pionowa moze oznaczac koniecznosc
  odpowiedniego podzialu informacji zawartych w
  klasach obiektów oraz ustalenia srodków
  podtrzymania jednoznacznej tozsamosci obiektów.
• Fragmentacja pozioma oznacza rozbicie populacji
  obiektów danej klasy na dwa lub wiecej miejsc
  geograficznych.
• Fragmentacja pozioma moze byc dokonywana na
  podstawie róznych kryteriów, które czesto wiazane
  sa z geograficznym ulokowaniem obiektów
  rzeczywistych, lub tez z geograficznym
  ulokowaniem przetwarzania tych obiektów.

6
Fragmentacja pionowa relacyjnej bazy danych
Warszawa
Kutno
DC
DOSTAWCA_DANE
DNR D1 D1 D1 D1 D1 D1 D2 D2 D3 D4 D4 D4
CNR C1 C2 C3 C4 C5 C6 C1 C2 C2 C2 C4 C5
ILOSC 300 200 400 200 100 100 300 400 200 200 300
400
DNR D1 D2 D3 D4 D5
NAZW Abacki Bober Czerny Dabek Erbel
STATUS 20 10 30 20 30
Siec
Gdansk
DOSTAWCA_MIASTO
DNR D1 D2 D3 D4 D5
MIASTO Lublin Poznan Poznan Lublin Radom
7
Fragmentacja pozioma relacyjnej bazy danych
DC
Poznan
DOSTAWCA
DNR D2 D2 D3
CNR C1 C2 C2
ILOSC 300 400 200
DNR D2 D3
NAZW Bober Czerny
STATUS 10 30
MIASTO Poznan Poznan
Lublin
Siec
8
Fragmentacja pionowa obiektów Pracownik
Siec
9
Fragmentacja pozioma obiektów Pracownik
Radom
Klasa Pracownik
Obiekty Pracownik sa przechowywane zgodnie z
geograficznym polozeniem pracodawcy.
Pracownik Nowak
Pracownik Kowalski
...
Siec
Klasa Pracownik
Kraków
Pracownik Malasa
Pracownik Zagórny.
...
10
Inne fragmentacje danych w rozproszonej BD

• Mozliwe sa inne, bardziej zlozone fragmentacje
  danych, które lacza fragmentacje pionowe,
  fragmentacje poziome oraz redundantne dane
  (replikacje).
• Bardziej zlozone fragmentacje rodza trudnosci z
• zarzadzaniem metadanymi gdzies musza byc
  ulokowane informacje odnosnie tego w jaki sposób
  podzielone dane maja byc scalone w kompletne
  obiekty lub kolekcje w ramach rozproszonej bazy
  danych. Jest to rola metadanych oraz mechanizmu
  wlasciwej dystrybucji metadanych pomiedzy
  uczestników rozproszonej bazy danych.
• przetwarzaniem zapytan dekompozycja zapytania na
  pod-zapytania adresowane do poszczególnych miejsc
  staje sie znacznie bardziej klopotliwa.
  Przesylanie fragmentów obiektów celem ich
  zmaterializowania po stronie klienta moze byc
  zbyt kosztowne.
• Bardziej zlozone fragmentacje moga byc nie do
  unikniecia w rozproszonej bazie danych
  integrujacej istniejace bazy danych (podejscie
  bottom-up). Ma to konsekwencje dla zarzadzania
  metadanymi.

11
Projektowanie podejscie bottom-up

• Podejscie ad hoc Budowa uniwersalnych lub
  specyficznych dla danego zastosowania pomostów
  (gateways) umozliwiajacych dostep z danego
  systemu bazy danych do innych baz danych. Pomost
  moze (nie musi) zapewniac przezroczystosc
  rozproszenia.
• Podejscie oparte o globalny schemat Wszystkie
  skladniki rozproszonej BD sa objete jednym
  globalnym schematem, jednakowym dla kazdego
  miejsca i zapewniajacym przezroczystosc
  rozproszenia. Istotna wada podejscia opartego na
  globalnym schemacie jest brak mozliwosci
  sterowania zakresem autonomii kazdego lokalnego
  systemu.
• Federacyjna baza danych Kazda lokalna baza
  danych zachowuje swoja autonomie, udostepniajac
  tylko czesc danych dla innych miejsc w RBD.
  Podejscie federacyjne zaklada, ze kazda lokalna
  baza danych jest widziana poprzez pewna
  perspektywe (view), ukrywajaca niektóre dane dla
  rozproszonych aplikacji.

12
Federacyjna BD tworzona metoda bottom-up
Schemat federacyjnej bazy danych
.....
Podejscie federacyjne okazalo sie skuteczne ze
wzgledu na zapewnienie autonomii, bezpieczenstwa
i efektywnosci. Rodzi jednak duzo problemów,
m.in. z zapewnieniem jednolitej ontologii
biznesowej, uniwersalnoscia aplikacji,
wydajnoscia, itd.
13
Architektura klient-serwer
Calosc pracy wykonywanej przez system komputerowy
jest podzielona na dwie czesci
wykonywana po stronie klienta (zwykle zwiazana z
interakcja z uzytkownikiem)
wykonywana po stronie serwera (komunikacja,
dostep do bazy danych, zarzadzanie repozytoriami
pamieci, zarzadzanie globalna przestrzenia nazw)
Podstawowe problemy
Okreslenie mechanizmu komunikacji pomiedzy
klientem a serwerem.
Podzial funkcji na te, które sa wykonywane po
stronie klienta i te, które sa wykonywane po
stronie serwera
Okreslenie jednostki komunikacji klient - serwer
14
Reguly architektury klient-serwer (1)

• Zachowanie autonomii serwera. Klienci powinni
  zachowywac reguly wykorzystania serwera, nie
  powinni powodowac jego niedostepnosc (np. zamykac
  duze ilosci danych), nie powinni lamac ograniczen
  integralnosci.
• Zachowanie autonomii klienta. Klienci nie powinni
  zachowywac sie róznie w zaleznosci od tego, czy
  serwer jest lokalny czy odlegly. Powinni byc
  odizolowani od kwestii fizycznego ulokowania
  danych.
• Wspomaganie dla aplikacji niezaleznych od
  serwera.
• Dostep do wlasnosci (danych, uslug) serwera.
  Klienci moga zadac od serwera wykonanie
  przewidzianych dla niego funkcji.
• Wspomaganie dla biezacego dostepu do danych.
  Dostep ten powinien byc bezposredni, bez
  posrednictwa plików przekazywanych do/od klienta.
• Minimalny wplyw architektury K/S na wymagania dla
  klienta. Oprogramowanie klienta w architekturze
  K/S nie powinno wykazywac znacznego zwiekszenia
  zapotrzebowania na RAM lub objetosc dysku.

15
Reguly architektury klient-serwer (2)

• Kompletnosc opcji niezbednych do polaczenia.
  Oprogramowanie klienta nie powinno zawierac kodu
  realizujacego polaczenie z serwerem.Powinien to
  zapewniac serwer komunikacyjny.
• Mozliwosc budowy lokalnych prototypów.
  Programista powinien miec mozliwosc budowy i
  testowania aplikacji K/S wylacznie na stacji
  klienta.
• Kompletnosc narzedzi uzytkownika koncowego.
  Projektowanie ekranów, generacja zapytan, itd.
  powinny byc czescia srodowiska.
• Kompletnosc srodowiska budowy aplikacji. Powinno
  przewidywac mozliwosc laczenia sie w sieci,
  dostep do uslug globalnych w zakresie nazw,
  lokacji danych, itd.
• Otwarte srodowisko jezyka-gospodarza. Powinno
  zapewniac mozliwosc uzycia uniwersalnego jezyka
  programowania do budowy aplikacji.
• Szczególna troska o standardy. Im bardziej beda
  one przestrzegane, tym mniej bedzie pózniejszych
  klopotów ze wspóldzialaniem.

16
Przyklad architektury SZBD typu klient-serwer
. . .
Zarzadzanie siecia
17
Architektura klient-(multi) serwer (1)
Polaczenia bezposrednie
k2
k3
k7
k1
s4
k4
s1
k8
s3
k5
s2
k9
k6
k10
k11
18
Architektura klient-(multi) serwer (2)
Polaczenia poprzez siec nie ma bezposrednich
polaczen, zarówno serwery jak i klienci sa
przylaczani w jednakowy sposób do wspólnej sieci
komputerowej.
k1
k2
s4
k3
k9
k4
s1
Siec komputerowa
k8
k5
s3
s2
k6
k7
19
Architektura trzywarstwowa i wielowarstowa
three-tier architecture
multi-tier architecture

• Architektura klient-serwer podzielona na trzy
  warstwy
• interfejs uzytkownika,
• logike przetwarzania (reguly biznesu, logike
  biznesu)
• serwer (serwery) bazy danych.
• Warstwy sa zaprojektowane i istnieja niezaleznie,
  co ma duze znaczenie dla pielegnacyjnosci systemu
  ze wzgledu na mozliwosc zmian w dowolnej warstwie
  bez koniecznosci zmian w pozostalych warstwach.
• Czesto warstwy sa zrealizowane na odrebnych
  platformach interfejs na MS Windows, logika
  przetwarzania na serwerze aplikacji i baza danych
  na serwerze bazy danych.
• Srodkowa warstwa moze skladac sie z wielu warstw,
  co jest okreslane jako architektura
  wielowarstwowa.

Interfejs uzytkownika
20
Logiczna architektura oprogramowania
Architektura klient-serwer powinna odzwierciedlac
logiczny podzial oprogramowania na czesci. Nie
jest to tak istotne w systemie scentralizowanym.
Architektura trójwarstwowa
Staranne rozdzielenie tych warstw jest bardzo
istotne z punktu widzenia tworzenia i
modyfikowalnosci oprogramowania. Dzieki temu
rozdzieleniu, mozliwa jest np. poprawa interfejsu
uzytkownika bez jakichkolwiek interwencji w
pozostale warstwy oprogramowania.
Warstwa prezentacyjna (interfejs uzytkownika)
cienki klient
gruby klient
Warstwa przetwarzania (logika biznesu)
Zasada oddzielania aspektów (separation of
concerns principle, E.Dijkstra)
Warstwa zarzadzania baza danych
21
Cienki i gruby klient
Terminy cienki klient (thin client) oraz gruby
klient (fat client) odnosza sie do mocy i jakosci
przetwarzania po stronie klienta w architekturze
klient-serwer. Model cienkiego klienta klient
posiada niezbyt wielka moc przetwarzania,
ograniczona do prezentacji danych na ekranie.
Przykladem jest klient w postaci przegladarki
WWW. Model grubego klienta klient posiada
znacznie bogatsze mozliwosci przetwarzania, w
szczególnosci moze zajmowac sie nie tylko warstwa
prezentacji, lecz takze warstwa przetwarzania
aplikacyjnego (logiki biznesu). Powyzszy podzial
posiada oczywiscie pewna gradacje. Model
cienkiego klienta jest najczestszym rozwiazaniem
w sytuacji, kiedy system scentralizowany jest
zamieniany na architekture klient-serwer. Wada
jest duze obciazenie serwera i linii
komunikacyjnych. Model grubego klienta uzywa
wiekszej mocy komputera klienta do przetwarzania
zarówno prezentacji jak i logiki biznesu. Serwer
zajmuje sie tylko obsluga transakcji bazy danych.
Popularnym przykladem grubego klienta jest
bankomat. Zarzadzanie w modelu grubego klienta
jest bardziej zlozone.
22
Architektury dwuwarstwowe
Uproszczone architektury trójwarstwowe z cienkim
lub grubym klientem.
Warstwa prezentacyjna (interfejs uzytkownika)
Warstwa przetwarzania (logika biznesu)
Warstwa prezentacyjna (interfejs uzytkownika)
cienki klient
gruby klient
Warstwa przetwarzania (logika biznesu) Warstwa
zarzadzania baza danych
Warstwa przetwarzania (logika biznesu) Warstwa
zarzadzania baza danych
W tym modelu przetwarzanie (logika biznesu) jest
dzielone pomiedzy klienta i serwera.
Zaprojektowanie jej jest trudniejsze.
23
Przyklad architektury K/S - siec bankomatów
Bankomat
Bankomat
Bankomat
Oprogramowanie posredniczace organizujace
komunikacje z odleglymi klientami i szeregujace
transakcje klientów celem przetwarzania ich przez
baze danych.
Bankomat
24
Przyklad architektury K/S - portal WWW
interakcja poprzez HTTP
zapytania SQL
Serwer Web generacja dynamicznych stron HTML dla
klienta zlecenia do bazy danych
Serwer bazy danych wykonywanie zapytan w SQL
wyniki zapytan SQL
25
3-warstwowa architektura aplikacji Web
Serwer Web
Siec Internet
Serwer aplikacji
Serwer bazy danych
HTTP
Baza danych
Baza danych
Przegladarka
Serwer
26
2-warstwowa architektura aplikacji Web
Wiele warstw posredniczacych powoduje dodatkowe
obciazenie.
Serwer Web Serwer aplikacji
Siec Internet
Serwer bazy danych
HTTP
Baza danych
Baza danych
Przegladarka
Serwer
27
Zastosowanie róznych architektur K/S

• Dwuwarstwowa architektura K/S z cienkim klientem
• Systemy spadkowe (legacy), gdzie oddzielenie
  przetwarzania i zarzadzania danymi jest
  niepraktyczne.
• Aplikacje zorientowane na obliczenia, np.
  kompilatory, gdzie nie wystepuje lub jest bardzo
  mala interakcja z baza danych.
• Aplikacje zorientowane na dane (przegladanie i
  zadawanie pytan) gdzie nie wystepuje lub jest
  bardzo male przetwarzanie.
• Dwuwarstwowa architektura K/S z grubym klientem
• Aplikacje w których przetwarzanie jest zapewnione
  przez wyspecjalizowane oprogramowanie klienta,
  np. MS Excel.
• Aplikacje ze zlozonym przetwarzaniem (np.
  wizualizacja danych, przetwarzaniem multimediów).
• Aplikacje ze stabilna funkcjonalnoscia dla
  uzytkownika, uzyte w srodowisku z dobrze
  okreslonym zarzadzaniem.
• Trzywarstwowa lub wielowarstwowa archiktektura
  K/S
• Aplikacje o duzej skali z setkami lub tysiacami
  klientów.
• Aplikacje gdzie zarówno dane jak i aplikacje sa
  ulotne (zmienne).
• Aplikacje integrujace dane z wielu rozproszonych
  zródel.

28
Architektura rozproszonych obiektów (1)

• W architekturze klient-serwer istnieje wyrazna
  asymetria pomiedzy klientem i serwerem w
  szczególnosci, nie wystepuje tam komunikacja
  bezposrednio pomiedzy klientami. Model taki dla
  wielu zastosowan jest malo elastyczny i zapewnia
  zbyt mala skalowalnosc.
• Architektura rozproszonych obiektów znosi podzial
  na klientów i serwery. Kazde miejsce w
  rozproszonym systemie jest jednoczesnie klientem
  i serwerem.
• Konieczne jest sprowadzenie wszystkich danych i
  uslug do jednego standardu.
• Taki standard obejmuje
• Model (pojeciowy i logiczny) danych i uslug,
  który jest w stanie "przykryc" wszystkie mozliwe
  dane i uslugi, które moga kiedykolwiek pojawic
  sie w systemie rozproszonym
• Specjalne oprogramowanie zwane posrednikiem
  (broker), które akceptuje wspólny model danych i
  uslug umozliwiajac ich udostepnienie dla
  dowolnych miejsc w systemie rozproszonym.
• Specjalne oprogramowanie, zwane oslona, adapterem
  lub mediatorem, które przystosowuje konkretne
  miejsce do modelu przyjetego przez posrednika.

29
Architektura rozproszonych obiektów (2)
Aplikacja napisana w C
Aplikacja na relacyjnej bazie danych
Aplikacja na Lotus Notes
Oslona 1
Oslona 2
Oslona 3
...
...
Posrednik
Posrednik
Posrednik
Szyna oprogramowania (software bus)
Miejsce 1
Miejsce 2
Miejsce 3
30
Struktura logiczna rozproszonych obiektów
O7
O3
O5
O1
O2
O9
Obiekty
O4
O8
O6
K1
K3
Operacje na obiektach
K2
K4
Szyna oprogramowania (software bus)
A1
A2
A3
Aplikacje
Szyna oprogramowania tworzy jedna przestrzen
obiektów. Obiekty te sa dostepne dla dowolnego
miejsca poprzez operacje (zgrupowane w klasach).
Miejsca i sposoby implementacji obiektów sa
niewidoczne. Aplikacje korzystaja z calej puli
obiektów.
31
Architektura serwera stron
Aplikacja
Przedmiotem zarzadzania sa fizyczne strony dyskowe
strony
32
Architektura serwera obiektów
Przedmiotem zarzadzania sa obiekty
obiekty
33
Przyszlosciowa architektura aplikacji
internetowych
Przegladarka WWW
Przegladarka WWW
Warstwa klienta
XML
XML
Serwer Web Serwer aplikacji
Warstwa aplikacji globalnych
Aplikacja globalna
Aplikacja globalna
Aplikacja globalna
Interakcja z aplikacjami poprzez protokoly oparte
na XML
Globalny wirtualny sklad zasobów uslug i danych
Logiczna warstwa posrednia
Web Services
Zasoby uslug i danych
Serwisy lokalne
Serwisy lokalne
Serwisy lokalne
Serwisy lokalne
Serwisy lokalne
Serwisy lokalne
wrappery
Obiektowo-relacyjna baza danych
Obiektowa baza danych
Relacyjna baza danych
XML-owa baza danych
Inne dokumenty na Webie HTML, Word,...
Dokumenty XML na Webie
Zasoby danych
34
Standardy laczenia rozproszonych danych (1)

• Open DataBase Connectivity (ODBC) standard
  zdalnego dostepu do relacyjnych baz danych
• bazuje na Call Level Interface (CLI) opracowanym
  przez konsorcjum X/Open
• definiuje API oraz cechy SQL które musza byc
  zapewnione na róznych poziomach zgodnosci.
• Java DataBase Connectivity (JDBC) analogiczny do
  ODBC standard dla Java.
• OLE-DB API podobne do ODBC, ale wspomagajace
  zródla nie-bazodanowe, takie jak plaskie pliki.
• OLE-DB program moze negocjowac ze zródlem danych
  aby znalezc wlasnosci, które ono podtrzymuje.
• API jest podzbiorem SQL
• ADO (Active Data Objects) latwy interfejs do
  funkcji OLE-DB

35
Standardy laczenia rozproszonych danych (2)

• Kilka standardów bazujacych na XML dla E-commerce
• Np. RosettaNet (lancuchy dostaw), BizTalk
• Definiuja katalogi, opisy uslug, faktury,
  zamówienia, itd.
• oslony XML sa uzywane 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) bazujacy na XML standard dla zdalnego
  wolania uslug. SOAP jest mniej elastyczny i
  uniwersalny w stosunku do CORBA.
• Uzywa XML do zakodowania danych, HTTP jako
  protokolu transportowego
• Kilka dalszych standardów WSDL (opis danych i
  uslug), UDDI (rejestry uslug), itd.
• Dalsze standardy sa oparte na SOAP dla
  specyficznych aplikacji, np. OLAP i Data Mining
  (standardy Microsoft'u)

36
Standardy laczenia rozproszonych danych (3)

• Object Data Management Group (ODMG) standard
  obiektowych baz danych
• jest raczej uzywany haslowo, nie jest znana
  calosciowa implementacja.
• OMG CORBA (Common Object Request Broker
  Architecture) - najbardziej uniwersalny standard
  obejmujacy ogromna liczbe aspektów. W
  szczególnosci, notacja UML jest jego skladowa.
  Pakiety ORB (Object Request Broker) sa
  oprogramowaniem realizujacym te architektura.
• .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 wykorzystuja RMI
  jako transport.