Systemy rozproszone (SYR)

© K.Subieta.Systemy rozproszone 3, Folia 1 styczeń 2005

Systemy rozproszone (SYR)

Wykładowca: Kazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, [email protected]

Instytut Podstaw Informatyki PAN, [email protected]

Wykład 3: Projektowanie i architektury rozproszonych baz danych


Podejścia do projektowania rozproszonych BD: top-down i bottom-up

Od ogółu do szczegółów (top-down): Odgórne zaprojektowanie całej bazy danych, z uwzględnieniem optymalizacji przechowywanych danych, narzuconej przez fakt geograficznego rozproszenia producentów i konsumentów informacji przechowywanej w bazie danych.

Od szczegółów do ogółu (bottom-up): Zintegrowanie już istniejących (spadkowych) lub zaprojektowanych lokalnych baz danych w jedną globalną rozproszoną bazę danych.


Projektowanie: podejście top-down

Analiza systemowa: rozpoznanie wymagań, precyzowanie kontekstu przyszłej bazy danych.

Projektowanie schematu pojęciowego

Projektowanie struktury logicznej Kryteria rozproszenia są związane z

faktem fizycznego rozproszenia źródeł i odbiorców danych oraz autonomii lokalnych baz danych.

Ustalają one decyzje, które fragmenty projektu pojęciowego będą przechowywane w poszczególnych miejscach, a także jak należy zdekomponować schemat logiczny na poszczególne miejsca

Analiza

Model pojęciowy scentralizowany

Model logiczny scentralizowany

Kryteriarozproszenia

Modele logiczne dla poszczególnych miejsc


Dalsze fazy postępowania w podejściu top-down Określenie danych podlegających replikacjom (lokalnych kopii) oraz

strategii replikacji. Zróżnicowanie logicznego schematu danych w zależności od typu SZBD

w poszczególnych miejscach. Określenie lokalnych schematów dla poszczególnych miejsc. Określenie danych autonomicznych dla poszczególnych miejsc, nie

uczestniczących w rozproszonej bazie danych; co prowadzi do określenia schematu pojęciowego i logicznego dla danych widzianych z zewnątrz.

Podział schematu logicznego: Wg różnych reguł związanych na ogół z fizycznym ulokowaniem obiektów rzeczywistych (np. osób zatrudnionych, sprzętu, co pociąga za sobą odpowiedni podział schematu logicznego) lub też z fizycznym ulokowaniem programów aplikacyjnych działających na tych obiektach.


Podstawowe metody fragmentacji schematu Fragmentacja pionowa oznacza przyporządkowanie poszczególnych

klas obiektów do poszczególnych miejsc, lub rozbicie obiektów danej klasy na dwa lub więcej podobiektów, przy czym takie podobiekty są przechowywane w różnych miejscach.

Fragmentacja pionowa może oznaczać konieczność odpowiedniego podziału informacji zawartych w klasach obiektów oraz ustalenia środków podtrzymania jednoznacznej tożsamości obiektów.

Fragmentacja pozioma oznacza rozbicie populacji obiektów danej klasy na dwa lub więcej miejsc geograficznych.

Fragmentacja pozioma może być dokonywana na podstawie różnych kryteriów, które często wiązane są z geograficznym ulokowaniem obiektów rzeczywistych, lub też z geograficznym ulokowaniem przetwarzania tych obiektów.


Fragmentacja pionowa relacyjnej bazy danych

DOSTAWCA_DANEDNR

D1D2D3D4D5

NAZW

AbackiBoberCzernyDąbekErbel

STATUS

2010302030

DCDNR

D1D1D1D1D1D1D2D2D3D4D4D4

CNR

C1C2C3C4C5C6C1C2C2C2C4C5

ILOŚĆ

300200400200100100300400200200300400

Warszawa

DOSTAWCA_MIASTODNR

D1D2D3D4D5

MIASTO

LublinPoznańPoznańLublinRadom

Gdańsk

Kutno

Sieć


Fragmentacja pozioma relacyjnej bazy danych

DOSTAWCADNR

D2D3

NAZW

BoberCzerny

STATUS

1030

MIASTO

PoznańPoznań

DCDNR

D2D2D3

CNR

C1C2C2

ILOŚĆ

300400200

Poznań

DOSTAWCADNR

D1D4

NAZW

AbackiDąbek

STATUS

2020

MIASTO

LublinLublin

DCDNR

D1D4D4

CNR

C6C2C4

ILOŚĆ

100200300

Lublin

DOSTAWCADNR

D5

NAZW

Erbel

STATUS

30

MIASTO

Radom

Radom

Sieć


Fragmentacja pionowa obiektów Pracownik

Radom Klasa danych osobistych

Nowakdane osobiste

Kowalskidane osobiste ...

Kalisz Klasa danych o ocenach

Nowakdane o ocenach

Kowalski dane o ocenach ...

Kraków Klasa danych o zatrudnieniu

Nowak dane o zatrud.

Kowalskidane o zatrud. ...

Sieć


Fragmentacja pozioma obiektów Pracownik

Radom Klasa Pracownik

PracownikNowak

PracownikKowalski ...

Kraków

PracownikMalasa

PracownikZagórny. ...

Sieć Kalisz

PracownikStyka

PracownikMalina ...

Klasa Pracownik

Klasa Pracownik

Obiekty Pracownik są przechowywane zgodnie z geograficznym położeniem pracodawcy.


Inne fragmentacje danych w rozproszonej BD Możliwe są inne, bardziej złożone fragmentacje danych, które łączą

fragmentacje pionowe, fragmentacje poziome oraz redundantne dane (replikacje).

Bardziej złożone fragmentacje rodzą trudności z:• zarządzaniem metadanymi: gdzieś muszą być ulokowane informacje

odnośnie tego w jaki sposób podzielone dane mają być scalone w kompletne obiekty lub kolekcje w ramach rozproszonej bazy danych. Jest to rola metadanych oraz mechanizmu właściwej dystrybucji metadanych pomiędzy uczestników rozproszonej bazy danych.

• przetwarzaniem zapytań: dekompozycja zapytania na pod-zapytania adresowane do poszczególnych miejsc staje się znacznie bardziej kłopotliwa. Przesyłanie fragmentów obiektów celem ich zmaterializowania po stronie klienta może być zbyt kosztowne.

Bardziej złożone fragmentacje mogą być nie do uniknięcia w rozproszonej bazie danych integrującej istniejące bazy danych (podejście bottom-up). Ma to konsekwencje dla zarządzania metadanymi.


Projektowanie: podejście bottom-up Podejście ad hoc: Budowa uniwersalnych lub specyficznych dla danego

zastosowania pomostów (gateways) umożliwiających dostęp z danego systemu bazy danych do innych baz danych. Pomost może (nie musi) zapewniać przezroczystość rozproszenia.

Podejście oparte o globalny schemat: Wszystkie składniki rozproszonej BD są objęte jednym globalnym schematem, jednakowym dla każdego miejsca i zapewniającym przezroczystość rozproszenia. Istotną wadą podejścia opartego na globalnym schemacie jest brak możliwości sterowania zakresem autonomii każdego lokalnego systemu.

Federacyjna baza danych: Każda lokalna baza danych zachowuje swoją autonomię, udostępniając tylko część danych dla innych miejsc w RBD. Podejście federacyjne zakłada, że każda lokalna baza danych jest widziana poprzez pewną perspektywę (view), ukrywającą niektóre dane dla rozproszonych aplikacji.


Baza danych 1

Miejsce 1Schemat lokalny 1

Aplikacje lokalneAplikacje lokalneAplikacje lokalne

Baza danych 2

Miejsce 2Schemat lokalny 2

Aplikacje lokalneAplikacje lokalneAplikacje lokalne

Federacyjna BD tworzona metodą bottom-up

Schemat federacyjnej bazy danych

Podejście federacyjne okazało się skuteczne ze względu na zapewnienie autonomii, bezpieczeństwa i efektywności. Rodzi jednak dużo problemów, m.in. z zapewnieniem jednolitej ontologii biznesowej, uniwersalnością aplikacji, wydajnością, itd.

PerspektywaMediatorOsłona

PerspektywaMediatorOsłona

Aplikacje globalneAplikacje globalneAplikacje globalne

.....


Architektura klient-serwer

Całość pracy wykonywanej przez system komputerowy jest podzielona na dwie części:

wykonywaną po stronie klienta (zwykle związaną z interakcją z użytkownikiem)

wykonywaną po stronie serwera (komunikacja, dostęp do

bazy danych, zarządzanie repozytoriami pamięci,

zarządzanie globalną przestrzenią nazw)

Określenie mechanizmu komunikacji pomiędzy klientem a serwerem.

Określenie jednostki komunikacji klient - serwer

Podział funkcji na te, które są wykonywane po stronie klienta i te, które są wykonywane po stronie serwera

Podstawowe problemy:


Reguły architektury klient-serwer (1) Zachowanie autonomii serwera. Klienci powinni zachowywać reguły

wykorzystania serwera, nie powinni powodować jego niedostępność (np. zamykać duże ilości danych), nie powinni łamać ograniczeń integralności.

Zachowanie autonomii klienta. Klienci nie powinni zachowywać się różnie w zależności od tego, czy serwer jest lokalny czy odległy. Powinni być odizolowani od kwestii fizycznego ulokowania danych.

Wspomaganie dla aplikacji niezależnych od serwera. Dostęp do własności (danych, usług) serwera. Klienci mogą żądać od

serwera wykonanie przewidzianych dla niego funkcji. Wspomaganie dla bieżącego dostępu do danych. Dostęp ten powinien

być bezpośredni, bez pośrednictwa plików przekazywanych do/od klienta. Minimalny wpływ architektury K/S na wymagania dla klienta.

Oprogramowanie klienta w architekturze K/S nie powinno wykazywać znacznego zwiększenia zapotrzebowania na RAM lub objętość dysku.


Reguły architektury klient-serwer (2) Kompletność opcji niezbędnych do połączenia. Oprogramowanie klienta

nie powinno zawierać kodu realizującego połączenie z serwerem.Powinien to zapewniać serwer komunikacyjny.

Możliwość budowy lokalnych prototypów. Programista powinien mieć możliwość budowy i testowania aplikacji K/S wyłącznie na stacji klienta.

Kompletność narzędzi użytkownika końcowego. Projektowanie ekranów, generacja zapytań, itd. powinny być częścią środowiska.

Kompletność środowiska budowy aplikacji. Powinno przewidywać możliwość łączenia się w sieci, dostęp do usług globalnych w zakresie nazw, lokacji danych, itd.

Otwarte środowisko języka-gospodarza. Powinno zapewniać możliwość użycia uniwersalnego języka programowania do budowy aplikacji.

Szczególna troska o standardy. Im bardziej będą one przestrzegane, tym mniej będzie późniejszych kłopotów ze współdziałaniem.


Przykład architektury SZBD typu klient-serwerAplikacja generująca transakcje

Zarządzanie transakcjami

Zarządzanie buforami

Zarządzanie zasobami

Klient 1

Aplikacja generująca transakcje

Zarządzanietransakcjami


Zarządzanie zasobami

Klient n

Zarządzaniesiecią

. . .

Interfejs serwera

Zarządzanietransakcjami


Zarządzaniezasobami

Serwer

Zarządzanielogiem

Zarządzaniezamkami


Architektura klient-(multi) serwer (1)

s1

s2s3

s4

k6

k5

k4

k3k2

k1

k10

k9

k8

k7

k11

Połączenia bezpośrednie:


Architektura klient-(multi) serwer (2)

s1

s2

s3

s4

k6

k5

k4

k3k2

k1

k9

k8

k7

Połączenia poprzez sieć: nie ma bezpośrednich połączeń, zarówno serwery jak i klienci są przyłączani w jednakowy sposób do wspólnej sieci komputerowej.

Sieć komputerowa


Architektura trzywarstwowa i wielowarstowathree-tier architecture

Interfejsużytkownika

Serwerbazy

danych

Serwerbazy

danych

multi-tier architecture

Logika przetwarzania

Architektura klient-serwer podzielona na trzy warstwy:

• interfejs użytkownika, • logikę przetwarzania (reguły biznesu, logikę biznesu) • serwer (serwery) bazy danych.

Warstwy są zaprojektowane i istnieją niezależnie, co ma duże znaczenie dla pielęgnacyjności systemu ze względu na możliwość zmian w dowolnej warstwie bez konieczności zmian w pozostałych warstwach.

Często warstwy są zrealizowane na odrębnych platformach: interfejs na MS Windows, logika przetwarzania na serwerze aplikacji i baza danych na serwerze bazy danych.

Środkowa warstwa może składać się z wielu warstw, co jest określane jako architektura wielowarstwowa.


Logiczna architektura oprogramowania

Architektura klient-serwer powinna odzwierciedlać logiczny podział oprogramowania na części. Nie jest to tak istotne w systemie scentralizowanym.

Warstwa prezentacyjna(interfejs użytkownika)

Warstwa zarządzania bazą danych

Architektura trójwarstwowa:

Warstwa przetwarzania(logika biznesu)

Staranne rozdzielenie tych warstw jest bardzo istotne z punktu widzenia tworzenia i modyfikowalności oprogramowania. Dzięki temu rozdzieleniu, możliwa jest np. poprawa interfejsu użytkownika bez jakichkolwiek interwencji w pozostałe warstwy oprogramowania.

Zasada oddzielania aspektów (separation of concerns principle, E.Dijkstra)

cienkiklient

grubyklient


Cienki i gruby klientTerminy cienki klient (thin client) oraz gruby klient (fat client) odnoszą się do mocy i jakości przetwarzania po stronie klienta w architekturze klient-serwer.

Model cienkiego klienta: klient posiada niezbyt wielką moc przetwarzania, ograniczoną do prezentacji danych na ekranie. Przykładem jest klient w postaci przeglądarki WWW.

Model grubego klienta: klient posiada znacznie bogatsze możliwości przetwarzania, w szczególności może zajmować się nie tylko warstwą prezentacji, lecz także warstwą przetwarzania aplikacyjnego (logiki biznesu).

Powyższy podział posiada oczywiście pewną gradację.

Model cienkiego klienta jest najczęstszym rozwiązaniem w sytuacji, kiedy system scentralizowany jest zamieniany na architekturę klient-serwer. Wadą jest duże obciążenie serwera i linii komunikacyjnych.

Model grubego klienta używa większej mocy komputera klienta do przetwarzania zarówno prezentacji jak i logiki biznesu. Serwer zajmuje się tylko obsługą transakcji bazy danych. Popularnym przykładem grubego klienta jest bankomat. Zarządzanie w modelu grubego klienta jest bardziej złożone.


Architektury dwuwarstwowe

Uproszczone architektury trójwarstwowe z cienkim lub grubym klientem.


Warstwa przetwarzania(logika biznesu) +


cienkiklient


+ Warstwa przetwarzania(logika biznesu)

grubyklient

Warstwa przetwarzania(logika biznesu) +


W tym modelu przetwarzanie (logika biznesu) jest dzielone pomiędzy klienta i serwera. Zaprojektowanie jej jest trudniejsze.


Bankomat

Bankomat

Bankomat

Bankomat

Serwer kont klientów banku

Monitor tele-przetwarzania

Baza danych kont klientów banku

Oprogramowanie pośredniczące organizujące komunikację z odległymi klientami i szeregujące transakcje klientów celem przetwarzania ich przez bazę danych.

Przykład architektury K/S - sieć bankomatów


klient

klient

klient

klient

Serwer Web:generacja

dynamicznych stron HTML dla klienta

+zlecenia do bazy

danych

Serwer bazy danych:

wykonywanie zapytań w SQL

zapytania SQL

wynikizapytań

SQL

interakcja poprzez HTTP

Przykład architektury K/S - portal WWW


3-warstwowa architektura aplikacji Web

Przeglądarka

SiećInternet

Baza danych

Baza danych

Serwer bazy danych

Serwer Web

Serwer aplikacji

Serwer

HTTP


2-warstwowa architektura aplikacji Web

Przeglądarka

SiećInternet

Baza danych

Baza danych

Serwer bazy danych

Serwer WebSerwer aplikacji

Serwer

HTTP

Wiele warstw pośredniczących powoduje dodatkowe obciążenie.


Zastosowanie różnych architektur K/S Dwuwarstwowa architektura K/S z cienkim klientem

• Systemy spadkowe (legacy), gdzie oddzielenie przetwarzania i zarządzania danymi jest niepraktyczne.

• Aplikacje zorientowane na obliczenia, np. kompilatory, gdzie nie występuje lub jest bardzo mała interakcja z bazą danych.

• Aplikacje zorientowane na dane (przeglądanie i zadawanie pytań) gdzie nie występuje lub jest bardzo małe przetwarzanie.

Dwuwarstwowa architektura K/S z grubym klientem• Aplikacje w których przetwarzanie jest zapewnione przez wyspecjalizowane

oprogramowanie klienta, np. MS Excel.• Aplikacje ze złożonym przetwarzaniem (np. wizualizacją danych, przetwarzaniem

multimediów).• Aplikacje ze stabilną funkcjonalnością dla użytkownika, użyte w środowisku z dobrze

określonym zarządzaniem. Trzywarstwowa lub wielowarstwowa archiktektura K/S

• Aplikacje o dużej skali z setkami lub tysiącami klientów.• Aplikacje gdzie zarówno dane jak i aplikacje są ulotne (zmienne).• Aplikacje integrujące dane z wielu rozproszonych źródeł.


Architektura rozproszonych obiektów (1) W architekturze klient-serwer istnieje wyraźna asymetria pomiędzy klientem i

serwerem; w szczególności, nie występuje tam komunikacja bezpośrednio pomiędzy klientami. Model taki dla wielu zastosowań jest mało elastyczny i zapewnia zbyt małą skalowalność.

Architektura rozproszonych obiektów znosi podział na klientów i serwery. Każde miejsce w rozproszonym systemie jest jednocześnie klientem i serwerem.

Konieczne jest sprowadzenie wszystkich danych i usług do jednego standardu.

Taki standard obejmuje:• Model (pojęciowy i logiczny) danych i usług, który jest w stanie "przykryć" wszystkie

możliwe dane i usługi, które mogą kiedykolwiek pojawić się w systemie rozproszonym;

• Specjalne oprogramowanie zwane pośrednikiem (broker), które akceptuje wspólny model danych i usług umożliwiając ich udostępnienie dla dowolnych miejsc w systemie rozproszonym.

• Specjalne oprogramowanie, zwane osłoną, adapterem lub mediatorem, które przystosowuje konkretne miejsce do modelu przyjętego przez pośrednika.


Pośrednik Pośrednik Pośrednik ......Szyna oprogramowania (software bus)

Miejsce 1 Miejsce 2 Miejsce 3

Osłona 1 Osłona 2 Osłona 3

Aplikacja napisana w

C++

Aplikacja na relacyjnej

bazie danych

Aplikacja na Lotus

Notes

Architektura rozproszonych obiektów (2)


Operacje naobiektach

Struktura logiczna rozproszonych obiektów

O6

O5O3

O2O1

O4

O7

O8O9

K1K2

K3K4

Obiekty

Szyna oprogramowania tworzy jedną przestrzeń obiektów. Obiekty te są dostępne dla dowolnego miejsca poprzez operacje (zgrupowane w klasach). Miejsca i sposoby implementacji obiektów są niewidoczne. Aplikacje korzystają z całej puli obiektów.

Szyna oprogramowania (software bus)

A1 A2 A3Aplikacje


Architektura serwera stron

strony

Zarządzanie zamkamiZarządzanie składem

Zarządzanie kieszenią stron

Obiektowabaza

danych

Aplikacja

Przeglądarkaobiektów

InterfejszapytaniowyOptymalizacja

zapytań

Interfejsprogramistyczny

Zarządzanie obiektamiZarządzanie plikami i indeksami

Zarządzanie kieszenią stron

Przedmiotem zarządzaniasą fizyczne strony dyskowe


Architektura serwera obiektów

obiekty

Zarządzanie obiektamiOptymalizacja zapytań

Zarządzanie zamkamiZarządzanie składem

Zarządzanie stronami i kieszeniami

Obiektowabaza

danych

Aplikacja

Przeglądarkaobiektów

Interfejszapytaniowy

Interfejsprogramistyczny

Zarządzanie obiektamiPrzedmiotem zarządzaniasą obiekty


Przyszłościowa architektura aplikacji internetowych

Logiczna warstwa

pośrednia

Zasoby danych

Warstwa klienta

XML XMLPrzeglądarka

WWWPrzeglądarka

WWW

Serwer WebSerwer aplikacji

Globalny wirtualny skład zasobów usług i

danych

Interakcja z aplikacjami poprzezprotokoły oparte na XML

Obiektowo-relacyjna

baza danych

Obiektowa baza danych

Inne dokumenty na Webie:

HTML, Word,...

Dokumenty XML na

Webie

Relacyjna baza

danych

XML-owa baza

danych

Serwisy lokalne

Serwisy lokalne

Serwisy lokalne

Serwisy lokalne

Serwisy lokalne

Serwisy lokalne

Zasoby usług i danych

wrappery

Web ServicesWeb Services

Aplikacja globalna

Aplikacja globalna

Aplikacja globalna

Warstwa aplikacji

globalnych


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.

Systemy rozproszone (SYR)

Documents

Transcript of Systemy rozproszone (SYR)