Institut für Softwarewissenschaft - Universität WienP.Brezany 1 Verteilte und föderierte Datenbanken und das Grid Peter Brezany Institut für Softwarewissenschaft

Institut für Softwarewissenschaft - Universität Wien

P.Brezany 1

Verteilte und föderierte Datenbanken und das

Grid

Peter BrezanyInstitut für Softwarewissenschaft

Universität Wien

Tel. : 01/4277 38825E-mail : [email protected]

Sprechstunde: Dienstag 11.30-12.30


P.Brezany 2

Lernziele

• Prinzipien von verteilten und föderierten Datenbanksystemen

• Ideen, wie Datenbanken in das Grid eingebunden werden können.

• In Richtung auf Datenbankservices


P.Brezany 3

Einführung• In der ersten Generation von Grid Anwendungen

nutzten nur einige Anwendungen Datenbanken (DB), um wissenschaftliche Daten zu speichern – fast alle nutzten files.

• In der nächsten Generation wird DB-Integration in das Grid wichtig.

• Es ist nicht möglich, dieses Ziel nur durch Erweiterung von existierenden Grid services, die files behandeln, zu erreichen.

– DB bieten eine viel reichere Menge von Operationen (z.B. queries, Transaktionen, usw.) an.

– Es gibt größere Heterogenität zwischen DB-Paradigmen (z.B. relationale und objekt-orientierte (OO) DB; in einem Paradigm können verschiedene DB Produkte verschiedene Funktionalität und Schnittstellen haben) als zwischen File-Systemen.

• Es ist notwendig folgende Datenquellen zu integrieren:

– Strukturierte Daten (z.B. Daten aus relationalen und OO DB)– Semi-strukturierte Daten wie XML– Relativ unstrukturierte Daten, wie Zeitschrift- und Konferenzartikel.


P.Brezany 4

Einführung (2)• Vorhandene DB Management Systeme (DBMS)

bieten keine Grid Integration an. Sie sind doch das Resultat (Sicherheit, gute Leistung, Verlässlichkeit, usw.) langjähriger Bemühungen von Tausenden Personen.

• Ausbau neuer Grid-orientierter DBMS ganz von vorn ist nicht vernünftig; das wäre eine Aufwandverschwendung.

• Das Forschungsziel: Einbindung von existierenden DBMS in das Grid.

• Limitierung: Einige verlangten Attribute müssen trotzdem direkt in das unterliegende DBMS integriert werden.


P.Brezany 5

Bereiche von Grid DB Anwendungen• Speicherung und Zurückholung (retrieval) von

Daten – Hauptaufgabe• Metadaten. Information über Information; sie fügen

den Kontext zu den Daten hinzu; es ist möglich Daten ausfindig zu machen, ohne zu wissen, wo die Daten gespeichert sind oder ihren physischen Namen zu kennen. Relationale DB sind momentan die Hauptmetode für Speicherung von Metadaten auf dem Grid – sie unterstützen Metadatenabfragen.

• Herkunft von Daten. Sie bieten Information über die Quelle und folgende Geschichte von Daten (Datenschaffung, Quelle, Besitzer, welche Bearbeitung stattfand, welche Analyse angewendet wurde, Vetrauen in die Qualität der Information).

• ... , z.B. Abrechnungsinformation – benutzt für Gebührenberechnung.


P.Brezany 6

Grid-DB Forschung

• It is basiert auf Technologie der verteilten und föderierten Datenbanken – es gibt verschiedene Interpretationen dieser Begriffe, z.B.:

• Eine verteilte Datenbank (VDB) ist eine Datenbank, die absichtlich über gewisse Zahl von Orten verteilt wurde. Eine VDB wird als Ganzes entworfen, und ist mit ziemlich zentralisierter Steuerung assoziiert.

• In einer föderierten Datenbank (FDB) tragen viele Datenbanken Daten und Ressourcen zu einer Multi-datenbank-Föderation bei, doch hat jeder Teilnehmer volle lokale Autonomie.


P.Brezany 7

Prinzipien von Verteilten Datenbank-Systemen (Distributed Database

Systems DDBS)

DDBS = Netzwerk von Computern (Sites) + DatenbankDDBS = Verteilung + Integration

+

=

Netzwerk Datenbank

DDBS


P.Brezany 8

Geschichtlicher RückblickEnde der 60er Anfang der 70er ging man zunehmend dazu über Datenbanksysteme zu benutzen, um• die Datenunabhängigkeit der Anwendungsprogramme zu erhöhen,• transaktionsorientierte Verarbeitung zu ermöglichen,• Mehrbenutzerbetrieb zu realisieren,• sowie die Recovery-Funktionen zu verbessern.

Entstehen von Rechenzentren, wodurch die Betriebsorganisation zentralisiert wurde!

Die Datenmenge wuchsen immer weiter an zusammengehörende Datenbestände wurden auf verschiedene Datenbanken verteilt.

Dadurch entstanden Probleme mit der Konsistenthaltung der Daten.

In den 80iger und 90iger Jahren konnten durch Onlineanwendungen bislang Getrennte Anwendungen und Datenbestände zusammengeführt werden.

Deshalb wurden integrierte verteilte Informationssysteme realisiert.


P.Brezany 9

Transaktion - Definition

• Transaktion: Besteht aus einer Sequenz von Lese- und Schreiboperationen auf eine Datenbank zusammen mit Berechnungsschritten

• Transaction management behandelt das Problem, die Datenbank immer in einen konsistenten Zustand zu halten, auch wenn gleichzeitige Zugriffe und Fehler auftreten.


P.Brezany 10

Definition

„A distributed database is a collection of multiple, logically interrelated databases distributed over a computer network. A distributed database management system is the software that permits the management of the DDBS and makes the distribution transparent to the users.“


P.Brezany 11

Zentrale Datenbankin einem Netzwerk

CommunicationNetwork

Boston

ParisSan

Francisco

Edmonton


P.Brezany 12

Verteilte Datenbankstruktur

CommunicationNetwork

Boston

ParisSan

Francisco

Edmonton

•Boston Angestellte

•Paris Angestellte

•Boston Projekte

•Paris Angestellte

•Paris Projekte

•Boston Angestellte

•Boston Projekte

•Edmonton Angestellte

•Paris Projekte

•Edmont Projekte

•San Francisco Angestellte

•San Francisco Projekte


P.Brezany 13

Transparentes Management

• Datenunabhängigkeit• Netzwerk Transparenz• Replizierungstransparenz• Fragmentierungstransparenz

(Fragmentierung=Aufteilung)


P.Brezany 14

Verbesserte Leistung

• Ein DBMS teilt die Datenbank und erlaubt es den Daten somit sehr sehr nahe ihrem Ort, wo sie gebraucht werden, gespeichert zu werden.dies hat 3 Vorteile:

1. Seit jeder Knoten einen Teil der Daten bewältigt, ist der Kampf um Ressourcen wie CPU nicht mehr so wichtig wie in zentralisierten Datenbanken

2. Lokalisierung vermindert die Verzögerung bei entfernten Aufrufen

3. Parallele Verarbeitung


P.Brezany 15

Abstraktionsebenen eines DBS• Externe Ebene – Sie erlaubt unterschiedliche

Sichten verschiedener Benutzer oder Benutzergruppen auf den Datenstand.

• Konzeptionelle Ebene – Das ist die zentrale Ebene. Sie spezifiziert die logische Gesamtsicht (d.h. unabhängig von der tatsächlichen Speicherung) aller Daten, die von irgendeinem Anwendungprogramm benötigt werden. Es erfolgt eine Beschreibung aller Objet- und Beziehungs-typen sowie deren Wertebereiche.

• Interne Ebene – Sie beschreibt die physische Datenorganisation, d.h. sie legt fest wie die im konzeptionellen Schema beschriebenen Objekte und Beziehungen physisch abgespeichert werden und welche Zugriffsmöglichkeitenbestehen. Es werden etwa Zugriffsmöglichkeiten zu den Datensätzen durch Indexstrukturen wie Hashtabellen, invertierte Listen oder B-Bäume spezifiziert.


P.Brezany 16

Architektur von DBMSDie Idee hinter dem ANSI/SPARC

Modell ist die Datenunabhängigkeit der Daten gegenüber Veränderungen der Speicherstrukturen.

Das DBMS ist eine Schnittstelle zu den Daten.


P.Brezany 17

Architekturmodell


P.Brezany 18

Architektur von DBMS

•Client - Server Architektur

•Verteilte Datenbank Architektur

•Multi Datenbank Architektur


P.Brezany 19

Client/Server Architektur

Hier gibt es typischerweise einen zentralen Datenbank-Server und eine größere Anzahl vernetzter Arbeitsplatzrechner, die keine relevanten Daten speichern. Der Benutzer am Arbeitsplatzrechner sieht die volle Funktionalität des DBMS. Das System verhält sich wie ein zentrales Datenbanksystem, die Kommunikation ist für den Benutzer transparent


P.Brezany 20

Verteiltes Datenbanksystem

• Hier gibt es mehrere Datenbankserver, wobei bestimmte Daten auf nur einem Rechner oder auch auf mehreren (replizit) gespeichert sein können.

• Eine virtuelle Datenbank, deren Komponenten physisch in einer Anzahl unterschiedlicher, real existierender DBMS abgebildet werden.

• Transaktionen können in diesem Fall über mehrere DBMS laufen.

• Sammlung von Daten, die• Aufgrund gemeinsamer, verknüpfender Eigenschaften dem

gleichen System angehören• Auf versch. Rechnern im Netzwerk verteilt sind• Wobei jeder Rechner seine eigene Datenbank besitzt• Autonom lokal Aufgaben abwickeln kann


P.Brezany 21


- gleichzeitige Benutzung der Rechenleistung mehrerer Rechner - Engpaß in zentralen Datenbanksystemen bei Zugriff auf die Daten

wird vermieden, da die Daten verteilt sind (ggf. repliziert)- Daten werden von einem Datenbanksystem verwaltet- Verteilungstransparenz- Grundlage: 4-Ebenen-Schema-Architektur


P.Brezany 22


4 - Ebenen - Schema - Architektur

externes Schema 1 externes Schema N

konzeptionelles Schema

lokales konzept. Schema



lokales internes Schema



. . .

. . .

. . .


P.Brezany 23

Multidatenbanksystem

- Ein MDBS ist ein Verbund von mehreren Datenbanksystemen.

- Das Konzeptionelle Schema repräsentiert nur den Teil von Daten, den die lokalen DBMS teilen wollen.

- Auf jedes DBS können lokale Anwendungen zugreifen.

- Jedes DBS kann Daten enthalten, welche keine Beziehung zu Daten anderer DBS haben.


P.Brezany 24

Multidatenbanksystem

Modell mit globalem konzeptionellem Schema

LES LES LES LES LES LES

GES GES GES

GKS

LKS 1 LKS n

LIS 1 LIS n

...

...


P.Brezany 25

DesignEntwurfsmethodik• top-down: von den Anforderungen zum

Systementwurf; geeignet für Neuentwicklungen.• bottom-up: Integration bestehender Datenbanken zu

einer verteilten; typisch bei heterogenen Datenbanken.

Datenverteilung• Fragmentierung der Daten zur Bildung logischer Einheiten,• Verteilung der Fragmente auf den Sites: Allokation aller

Fragmente an jeder Site (volle Replikation) oder jedes Fragment an mehr als einer Site (partielle Replikation) oder jedes Fragment an genau einer Site (Partitionierung).


P.Brezany 26

Die Trennung von Fragmentierung und Allokation dient der Vereinfachung des Entwurfs.

• Globales Schema: Definition der Relationen eines vDBS ohne Berücksichtigung der Verteilung,

• Fragmentierungsschema: Definition der Abbildung zwischen globalen Relationen und Fragmenten,

• Allokationsschema: Definition der Abbildung zwischen Fragmenten und Sites.

Der Zugriff zu den Daten soll hinsichtlich Fragmentierung, Lokation, und Replikation transparent sein.


P.Brezany 27

R1

R2

R3

R4

R1,1

R2,1

R1,2

R2,2

R3,3R4,3

Globale Relation

Fragmente

Allokation an den Sites

S1

S2

S3

Fragmente und ihre Allokation

R


P.Brezany 28

Beispiel: JNO JNAME BUDGET LOC

J1 Instrumentation 150000 Montreal

J2 DatabaseDevelop. 135000 New York

J3 CAD/CAM 250000 New York

J4 Maintenance 310000 Paris

JNO JNAME BUDGET LOC






horizontale Fragmentierung


P.Brezany 29

Beispiel: JNO JNAME BUDGET LOCJ1 Instrumentation 150000 Montreal




JNO JNAME BUDGET LOCJ1 Instrumentation 150000 MontrealJ3 CAD/CAM 250000 New York




JNO ImportanceJ1 low

J2 high

J3 low

J4 high abgeleitete horizontale Fragmentierung


P.Brezany 30

Beispiel: JNO JNAME BUDGET LOC





vertikale Fragmentierung

JNO BUDGET

J1 150000

J2 135000

J3 250000

J4 310000JNO JNAME LOC

J1 Instrumentation Montreal

J2 DatabaseDevelop. New York

J3 CAD/CAM New York

J4 Maintenance Paris


P.Brezany 31

Sei F = {F1, ..., Fn} eine Menge von Fragmenten, S = {S1, ..., Sm} ein Netzwerk gegeben durch die Menge seiner Sites, und Q = {Q1, ..., Qp} die Menge der relevanten Anwendungen.

Allokationsproblem: Was ist die „optimale“ Zuordnung von F zu S bzgl. Q?

Optimaltätskriterium:•Minimalität der Kosten gegeben durch die Speicherkosten der Fi an den Sites Sj, der Anfragekosten für Fi an Site Sj, der Änderungskosten der Fi an allen Sites an den sie gespeichert sind, und die Kosten der Datenkommunikation.•Performanz im Sinne von Antwortzeiten oder Systemdurchsatz.

Allokation


P.Brezany 32

A Typical Federated System Architecture

Catalog: registers wrappersData: caches query reults


P.Brezany 33

Integration von Datenbanken in das Grid

• Grid-enabled version of JDBC/ODBC - The core set of functionality offered by JDBC/ODBC does not include a number of operations to fulfill Grid database requirements.

• Better solution: Service-based approach shown in the next slide, with a service wrapper placed between the Grid and the DBS

Two possible approaches:


P.Brezany 34

Integrating Databases into the Grid (2)


P.Brezany 35

Federating Database Systems Across the Grid

A Grid application interfacing directly to a set of DBS


P.Brezany 36

Federating Database Systems Across the Grid (2)

The virtual database service providesthe illusion that a singe DB is accessed.The services can be transient (Grid-enabled)or persistent (operated independently of the Grid).


P.Brezany 37

Database Database Service (GDS)

Entdeckung des DB services

• Die Beschreibung der DB services mußt publiziert (registriert) werden:

– Inhalt der DB– Details über DB Operationen– usw.

• Registry Look-up gibt Grid Service Handle (GSH) zurück. GSH ist ein global eindeutiger Name für jeden einzigen service Fall (instance).


P.Brezany 38

Database Statements• DB statements ermöglichen Abfragen (queries),

Modifikationen (updates) und Ladungen (loads) an ein DB für Ausführung zu schicken.

• Grundlegendes database statement interface

query (IN queryNotation, IN query, OPTIN expires, OUT resultHandle, OUT fail) update (....) bulkLoad (....) schemaUpdate (....)

..................................................................... z.B. queryNotation = “SQL92“ expires – Beschränkung von Ressourcen-Anwendung


P.Brezany 39

Distributed Query ServiceThe role of a distributed query service is to allow individual queries to access multiple DB, thereby allowing the system to take responsibility for query optimizationand efficient evaluation.

Setting up a distributed query service


P.Brezany 40

Distributed Query Service (2)

Using up a distributed query service


P.Brezany 41

Database Services in OGSA• DB services bekommen zusätzliche

Eingeschaften, when sie mit OGSA integriert werden.

• Life cycles – OGSA unterscheidet zwischen:– persistent service: er wird außerhalb der Grid-Service-

Umgebung hergestellt; er kann durch standard Grid-Service-Konventionen benutzt werden.

– transient Grid service: er wird innerhalb von OGSA von factory hergestellt. Es ist möglich seine Lebensspane (lifespan) zu spezifizieren.

Auch schema, Datenbank, usw. kann spezifiziert werden.• Es ist notwendig zu ermöglichen, dass DB

Authoriesierungsfunktionalität innerhalb von OGSA zugreifbar ist.


P.Brezany 42

Creating and Using a Grid Data Service

Documents

Institut für Softwarewissenschaft - Universität WienP.Brezany 1 Verteilte und föderierte Datenbanken und das Grid Peter Brezany Institut für Softwarewissenschaft