View
212
Download
0
Category
Preview:
Citation preview
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 : brezany@par.univie.ac.at
Sprechstunde: Dienstag 11.30-12.30
Institut für Softwarewissenschaft - Universität Wien
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
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 7
Prinzipien von Verteilten Datenbank-Systemen (Distributed Database
Systems DDBS)
DDBS = Netzwerk von Computern (Sites) + DatenbankDDBS = Verteilung + Integration
+
=
Netzwerk Datenbank
DDBS
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
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.“
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 11
Zentrale Datenbankin einem Netzwerk
CommunicationNetwork
Boston
ParisSan
Francisco
Edmonton
Institut für Softwarewissenschaft - Universität Wien
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
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 13
Transparentes Management
• Datenunabhängigkeit• Netzwerk Transparenz• Replizierungstransparenz• Fragmentierungstransparenz
(Fragmentierung=Aufteilung)
Institut für Softwarewissenschaft - Universität Wien
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
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 17
Architekturmodell
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 18
Architektur von DBMS
•Client - Server Architektur
•Verteilte Datenbank Architektur
•Multi Datenbank Architektur
Institut für Softwarewissenschaft - Universität Wien
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
Institut für Softwarewissenschaft - Universität Wien
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
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 21
Verteiltes Datenbanksystem
- 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
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 22
Verteiltes Datenbanksystem
4 - Ebenen - Schema - Architektur
externes Schema 1 externes Schema N
konzeptionelles Schema
lokales konzept. Schema
lokales konzept. Schema
lokales konzept. Schema
lokales internes Schema
lokales internes Schema
lokales internes Schema
. . .
. . .
. . .
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
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
...
...
Institut für Softwarewissenschaft - Universität Wien
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).
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
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
Institut für Softwarewissenschaft - Universität Wien
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
J1 Instrumentation 150000 Montreal
J2 DatabaseDevelop. 135000 New York
JNO JNAME BUDGET LOC
J3 CAD/CAM 250000 New York
J4 Maintenance 310000 Paris
horizontale Fragmentierung
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 29
Beispiel: JNO JNAME BUDGET LOCJ1 Instrumentation 150000 Montreal
J2 DatabaseDevelop. 135000 New York
J3 CAD/CAM 250000 New York
J4 Maintenance 310000 Paris
JNO JNAME BUDGET LOCJ1 Instrumentation 150000 MontrealJ3 CAD/CAM 250000 New York
JNO JNAME BUDGET LOC
J2 DatabaseDevelop. 135000 New York
J4 Maintenance 310000 Paris
JNO ImportanceJ1 low
J2 high
J3 low
J4 high abgeleitete horizontale Fragmentierung
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 30
Beispiel: JNO JNAME BUDGET LOC
J1 Instrumentation 150000 Montreal
J2 DatabaseDevelop. 135000 New York
J3 CAD/CAM 250000 New York
J4 Maintenance 310000 Paris
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
Institut für Softwarewissenschaft - Universität Wien
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
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 32
A Typical Federated System Architecture
Catalog: registers wrappersData: caches query reults
Institut für Softwarewissenschaft - Universität Wien
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:
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 34
Integrating Databases into the Grid (2)
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 35
Federating Database Systems Across the Grid
A Grid application interfacing directly to a set of DBS
Institut für Softwarewissenschaft - Universität Wien
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).
Institut für Softwarewissenschaft - Universität Wien
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).
Institut für Softwarewissenschaft - Universität Wien
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
Institut für Softwarewissenschaft - Universität Wien
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
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 40
Distributed Query Service (2)
Using up a distributed query service
Institut für Softwarewissenschaft - Universität Wien
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.
Institut für Softwarewissenschaft - Universität Wien
P.Brezany 42
Creating and Using a Grid Data Service
Recommended