Verteilte Datenbanken

Verteilte Datenbanken - Distributed Database Management Systeme DDBMS

Struktur

Ein Datenbanksystem heißt verteilt, wenn die zugehörige Datenbasis koordiniert auf mehrere Computersysteme (Netzknoten) aufteilbar ist. Das heisst, dass die Datenbank auf mehreren, meist lokal verschiedenen Servern liegt.

Ein inhaltlich zusammengehörender Datenbestand

Gespeichert an verschiedenen, geografisch verteilten Standorten

Szenario:

Großhändler mit Zentrale und mehreren Auslieferungslagern. Die Auslieferungslager sind weitgehend autonom tätig. Die Zentrale soll aber „jederzeit“ Kenntnis über den „datentechnischen“ Zustand des Gesamtsystems haben.

In diesem Fall handelt es sich um einen gemeinsamen Datenbestand, der örtlich verteilt existiert.

Logisch handelt es sich aber um eine Datenbank.

Grundlegendes Prinzip

Für eine Anwendung verhält sich ein verteiltes Datenbanksystem wie ein nicht – verteiltes Datenbanksystem.

Es unterscheidet sich fundamental von Client – Server Systemen.

Gründe für Verteilung

Dezentralisierte Organisationsformen dezentrale Verantwortliche haben oft den Wunsch nach lokalen Datenbeständen
Sicherheitsüberlegungen, Verfügbarkeit bei Ausfall eines Netzknotens soll zumindest ein eingeschränkter lokaler Betrieb möglich sein
Flexibilitätswünsche Hinzufügen / Wegnahme eines Netzknotens bedeutet meist einen geringeren Eingriff als wesentliche Änderungen einer zentralen Datenbank
Leistungsanforderungen Datenmenge / Transaktionsvolumen können die Anforderungen eines Rechners übersteigen
Koordinierungsbemühungen sind in einem Unternehmen - historisch gesehen - viele isolierte Datenbanken 'gewachsen', so können sie im Rahmen des Konzeptes 'verteilte Datenbanken' wieder in ein Gesamtsystem integriert werden.

Schemaarchitektur

Erklärung zu den Schemata

DDBMS Typen

Homogene DDBMS

Eom homogenes DDBMS ist ein Netzwerk aus 2 oder mehreren Oracle Datenbanken, die auf 1 oder mehreren Maschinen installiert sind.

Erweiterung des Namensschema durch Synonyme für remote Objekte

SELECT * FROM emp@sales;
CREATE SYNONYM remote_emp for emp@sales;
SELECT * FROM remote_emp;

Heterogene DDBMS

Bei einem heterogenen DDBMS ist zumindest eine Datenbank eine Nicht – Oracle - Datenbank.

Fragmentierung

Horizontale Fragmentierung

Die Datensätze werden in Gruppen aufgeteilt. Jede der Gruppen wird einer lokalen Datenbank zugeteilt:

Es wird in Tabellen mit denselben Spalten, allerdings mit Projektion auf die verschiedenen Filialen, aufgeteilt.

Vertikale Fragmentierung

Vertikale Fragmentierung bedeutet die Teilung eines logischen Datensatzes in 2 oder mehrere physische Datensätze. Die verschiedenen physischen Datensätze werden in den lokalen Datenbanken gespeichert.

Hybride Fragmentierung

Hier wird eine Mischung aus horizontaler und vertikaler Fragmentierung vorgenommen. Also wird ein Teil der Daten horizontal und ein anderer Teil vertikal fragmentiert.

Verteilte Transaktionen

In verteilten Systemen können an Ausführung einer Transaktion mehrere Knoten beteiligt sein. An einem bestimmten Knoten wird die Transaktion gestartet (commit) - er wird damit zum Koordinatorrechner der Transaktion, an der weitere Knoten beteiligt sein werden (globale Transaktion).

Beispiel

BEGIN DISTRIBUTED TRANSACTION

	-- Buchtitel in lokaler Tabelle eintragen
	INSERT INTO BOOKS VALUES ( …)

	--Autor in entfernter Tabelle eintragen
	INSERT INTO RemoteDB.DB_Name.Autor VALUES (…)

COMMIT        -- 2 Phase Commit

Oracle DDBMS

Eine Distributed Database ist eine Menge von Datenbanken auf verschiedenen Rechnern, die für die Applikation als 1 Rechner erscheinen.

Join Abfragen

SELECT *
FROM EMP,DEPT
WHERE EMP.DEPTNO = DEPT.DEPTNO

wobei EMP in DB1 und DEPT in DB2 gespeichert ist

Transfer ganzer Relationen (ship whole) dabei werden Relationen vollständig an den Join Knoten übertragen, bevor der Join durchgeführt wird. Der Transfer wird natürlich für die kleinere der beiden Relationen ausgeführt.

Satzweises Anfordern von Verbundpartnern (fetch as needed) für jedes Tupel der lokal vorliegenden Relation wird der Wert des Join Attributes ermittelt und an den anderen Rechner gesandt. Dort werden daraufhin die übereinstimmenden Werte ermittelt und an den anfordernden Rechner gesandt.

Semi Join Strategien

der Overhead des fetch as needed Ansatzes, indem für jeden Satz einer Relation der Verbundpartner einzeln angefordert wird, kann dadurch reduziert werden, dass lokal alle Werte des Join Attributes ermittelt werden, diese in Form eines gesamten Datenpaketes an den anderen Knoten übermittelt werden, der seinerseits das Ergebnis an die anfordernde Stelle zurückschickt. Der durch die mehrfache Übertragung entstehende Overhead wird durch die Paketübertragung verringert. [ Mehr zu Semijoin Strategien]

Query Arten

Ein remote query ist eine Abfrage, die sich zur Gänze auf remote Objekte bezieht. Diese Objekte befinden sich auf genau einer remote site.

Eine Abfrage könnte folgendes Aussehen haben:

SELECT * FROM scott.dept@sales.us.americas.acme_auto.com

Eine distributed query bezieht sich auf Objekte, die auf verschiedenen Knoten gespeichert sind:

SELECT ename, dname
FROM scott.emp e, 
scott.dept@sales.us.americas.acme_auto.com d
WHERE e.deptno = d.deptno;

Transaktionsarten

Remote Transaction

Distributed Transaction

<br />UPDATE scott.dept@oracledb<br />SET LOC = 'NEW YORK'<br />WHERE DEPTNO = 10;<br /><br />UPDATE scott.emp@oracledb<br />SET DEPTNO = 11<br />WHERE DEPTNO = 10;<br /><br />COMMIT;<br />

<br />UPDATE scott.dept@oracledb<br />SET LOC = 'NEW YORK'<br />WHERE DEPTNO = 10;<br /><br />UPDATE scott.emp<br />SET DEPTNO = 11<br />WHERE DEPTNO = 10;<br /><br /><br />COMMIT;<br />

Database Links und Vorgehen in Oracle DDBMS

Database Link: 'Informations - Einbahnstrasse' von einer zu einer anderen DB:

CREATE DATABASE LINK sales.us.americas.acme_auto.com ... ;

Daraus ergibt sich beispielsweise folgende DB - Abfrage:

SELECT * FROM scott.emp@sales.us.americas.acme_auto.com;

Vorgehen In Oracle

Database Link

Ein Database Link ist ein Pointer, der einen "one way" Kommunikationspfad von einem Oracle Database Server zu einem anderen Server einrichtet. Der Link Pointer entspricht einem Eintrag im Data Dictionary der lokalen Datenbank

CREATE DATABASE LINK .....;

Der lokale User hat Zugriff auf die remote Datenbank ohne User in dieser Datenbank sein zu müssen. Er ist dabei aber an die Privilegien des Object-Owners gebunden.

Benennung von Schema Objekten in DDBMS

schema.schema_object@global_database_name

Benennung und Erklärung der Statementteile

Name	Beschreibung
`schema`	Logisch zusammengehörende Tabellen und andere Datenbankobjekte unter einem Schemanamen, der mit dem Benutzernamen identisch ist. Ein unter einem Schemanamen angemeldeter Benutzer ist ein `User`
`schema_object`	Sind logische Datenstrukturen wie `Tabelle`, `View`, `Index`, `Synonym`, `Procedure`, `Package` oder `Database Link`
`global_database_name`	Ist der einer remote Datenbank eindeutig zugeordnete und bezeichnende Name

Schritt für Schritt Anleitung

Database Link erstellen

CREATE DATABASE LINK oracle_db_link USING 'orackedb'

Verwendung von Username/Passwort des aktuellen Users

Verlinken des Users mit dem Database Link

CREATE DATABASE LINK oracle_db_link TO scott IDENTIFIED BY tiger USING ‘oracledb’

In der Using Klausel wird der Datenbankname aus der Datei TNSNAMES.ORA angegeben

Daraus ergibt sich beispielsweise folgende DB - Abfrage:

SELECT * FROM scott.emp@oracle_db_link

Bei einem public database link haben alle User der Datenbank Zugriff auf die remote Datenbank.

Performanceüberlegungen

Tabelle	Standort	Anzahl
`STADT(ST#,NAME)`	A	10000
`TEIL(T#,FARBE)`	B	100000
`TEIL_STADT(ST#,T#)`	A	1000000

Annahmen: 10 rote Teile, 100.000 Wiener – Tupel in TEIL_STADT Jedes Tupel habe eine Länge von 25 Byte

SELECT St#
FROM STADT, TEIL, TEIL_STADT
WHERE Stadt.St# = TEIL_STADT.St#
AND TEIL.T# = TEIL_STADT.T#
AND Name = ‘WIEN‘
AND FARBE = ‘rot‘

Kostenmodell

C1 Datenrate = Zahl übertragener Bits pro Sekunde C0 Initialisierungszeit = Dauer des Verbindungsaufbaus n Menge der zu übertragenden Daten

Gesamtkosten C = C0 + n/C1 in Sekunden

Im Beispiel:

C1 = 50.000 Bits pro Sekunde 
C0 = 0.1 Sekunden

Variante 1

Am Standort A kann ermittelt werden:

WHERE STADT.St# = TEIL_STADT.St#
AND Name = ‘WIEN‘

Ergebnis: 100.000 Tupel

Pro Tupel des Standortes A wird durch „Nachfrage“ an Standort B ermittelt, ob die Farbe „rot“ zutrifft. Ergebnis: 100.000 Nachrichten (pro Nachricht wird die Teilenummer hingeschickt und die Farbe zurück)

Pro Nachricht wird die T# hin- und die Farbe zurückübertragen: Das sind ca. 25 Byte (=200 Bit) pro Übertragung

C = 0.1 + 200/50.000 = 0,104

Also für 100.000 Nachrichten:

C = 0.1 x 100.000 ~ 10.000 Sekunden ~ 2.78 Stunden

Variante 2

Übertragen der kompletten Tabelle TEIL von B nach A. Berechnung des Ergebnisses am Standort A

Mengen- und Zeitüberlegungen: Übertragung von 100.000 Datensätzen:

C = 0.1 + (100.000 x 200) / 50.000 = 400 Sekunden 
~ 6.67 Minuten

Variante 3

Berechnung am Standort B die Restriktion auf die Teile mit der Farbe rot. Übertragung der 10 gefundenen Tupel von B nach A. Berechnung der Ergebnismenge am Standort A.

Übertragung von 10 Datensätzen von B nach A:

C = 0.1 + (10 x 200) / 50.000 
~ 0.1 Sekunden

Verteilte Datenbanken

Contents