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
UPDATE scott.dept@oracledb SET LOC = 'NEW YORK' WHERE DEPTNO = 10; UPDATE scott.emp@oracledb SET DEPTNO = 11 WHERE DEPTNO = 10; COMMIT;	UPDATE scott.dept@oracledb SET LOC = 'NEW YORK' WHERE DEPTNO = 10; UPDATE scott.emp SET DEPTNO = 11 WHERE DEPTNO = 10; COMMIT;

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

Semijoin Strategie

SELECT * 
FROM TEIL_STADT, TEIL 
WHERE TEIL.T# = TEIL_STADT.T#

Wobei TEIL_STADT an Standort A und TEIL an Standort B

1. Berechne an Standort A die Projektion auf das Join-Attribut. (Zwischentabelle mit der Spalte T# der TEIL_STADT Tabelle)
2. Übertrage diese Zwischentabelle an Standort B
3. Berechne an Standort B den Join von Zwischentabelle mit der Tabelle TEIL
4. Übertrage die Ergebnistabelle an Standort A
5. Berechne nun den Join von Ergebnistabelle mit TEIL_STADT

Performanceoptimierung

Distributed Query Optimization optimiert das Zugriffsverhalten in distributed SQL Queries.

Es entscheidet, welche Daten übertragen werden sollen bzw. wo die Abfrage ausgeführt werden soll.

SELECT /*+DRIVING_SITE(dept)*/ * 
FROM emp, dept@remote.com 
WHERE emp.deptno = dept.deptno; 

Spezifikation durch den Benutzer auf welcher site das Query ausgeführt werden soll.

Transparenz duch Views / Synonyme

Transparenz: Die Implementierungsdetails sind dem Benutzer gegenüber „verborgen“.

Definition einer View	Definition eines Synonyms
CREATE VIEW TAB_VIEW AS SELECT * FROM TAB@ATLAS	CREATE PUBLIC SYNONYM TAB FOR TAB@ATLAS;

SQL-Abfragen ohne Kenntnis des Datenbank-Links

Update einer View	Update eines Synonyms
UPDATE TAB_VIEW SET PREIS = PREIS*1.03 WHERE ......;	UPDATE TAB SET PREIS=PREIS*1.03 WHERE .......;

• Auflösen der View Definition für TABELLE über das DD
• Identifizierung eines DB-Links hinter der View-Definition
• Auflösen des DB-Link-Namen und der TNS-Adresse beim Zielrechner
• Verbindungsaufbau zur Remote-Datenbank
• SQL-Befehl an die Zieldatenbank senden
• Ziel-Datenbank führt den SQL-Befehl aus
• Ergebnis-Rückgabe an den lokalen DB-Server

Transparent Network Substrate (TNS) dient in einem Rechnernetz zum Herstellen von Peer-to-Peer - Verbindungen zwischen Rechnern. Das TNS dient insbesondere zur Kommunikation mit Oracle Datenbanken.

Data Replication

• Data Replication ist der Prozess des Kopierens und Verwaltens von Datenobjekten in verschiedenen DBs, die gemeinsam ein DDBMS ausmachen.

• Die replizierten Daten werden meist an verschiedenen Orten gespeichert und auch synchronisiert.

• Die einfachste Form einer Replikation ist die Speicherung einer Kopie einer Datei.

Anwendungsmöglichkeiten

Verteilung von Produktinformationen an alle Verkaufsstellen. Diese Produktinformationen existieren lokal in jeder Datenbank.

Für Benutzer, die mobil sind und hinsichtlich der UnternehmensDB 'disconnected' sind. Änderungen werden in ihrer 'persönlichen' Datenbank durchgeführt - beim Anschluss an die Unternehmensdatenbank ist ein Abgleich der Daten notwendig.

Oracle unterstützt 2 Arten von Datenrepliken:

• Basic Replication Environment

Die Datenreplik stellt nur einen Lesezugriff auf Daten, die von einer primary site (master site) stammen, zur Verfügung.

• Advanced Replication Environment

Applikationen können die Datenrepliken im gesamten System lesen und ändern. Dazu muss der Oracle Server speziell konfiguriert sein.

Materialized View

Ist ein Datenbankobjekt, das das Ergebnis eines Query enthält.

Das Query basiert auf den „Mastertables“.

In diesem Zusammenhang ist die Konsistenz zwischen M-View und Mastertable ein wesentlicher Faktor.

Materialized Views in Oracle:

CREATE MATERIALIZED VIEW MV_MY_VIEW 
   REFRESH FAST                  -- eine Änderung in der Mastertable wird sofort an die M- View “weitergereicht”
    START WITH …                 -- Spezifikation des Zeitpunktes des 1. Refreshs
AS SELECT * FROM …….             -- Festlegung des M-View Inhalts

2 Phasen Commit

Alle an einer globalen Transaktion beteiligten Knoten müssen ein gemeinsames Commit Ergebnis erreichen. Es muss also insgesamt die "Alles oder Nichts Eigenschaft" gewährleistet sein.

Verteiltes 2 Phasen Commit Protokoll:

• Bei Transaktionsende sendet der Koordinator eine Nachricht an alle Agenten um deren lokales Commit Ergebnis zu erfahren.
• Das Ergebnis (commit/rollback) der beim Agenten gelaufene Subtransaktion wird an den Koordinator zurückgemeldet.
• Nachdem alle Rückmeldungen beim Koordinator eingetroffen sind, ist die Phase 1 abgeschlossen. Der Koordinator kann jetzt entscheiden, ob die globale Transaktion erfolgreich gelaufen ist
• Das Ergebnis wird den Agenten mitgeteilt, die das mitgeteilte Ergebnis lokal nachvollziehen (commit/rollback)