Verteilte Datenbanken

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Ziele und Problemstellung

3 Verteilte Datenbanken
3.1 Anforderungen
3.2 Architektur
3.3 Datenverteilung und Katalogverwaltung
3.3.1 Fragmentierung
3.3.2 Allokation und Replikation
3.4 Synchronisationsverfahren
3.4.1 Sperrverfahren
3.4.2 Zeitmarkenverfahren
3.5 Konsistenzsicherung
3.5.1 ACID
3.5.2 BASE und CAP Theorem

4 Bewertung
4.1 Chancen
4.2 Risiken

5 Schlussbetrachtung
5.1 Fazit
5.2 Ausblick

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abb. 1 Grobarchitektur eines Verteilten Datenbanksystems „Quelle: Rahm/Saake/Sattler (2015), S. 7“

Abb. 2 Schematische Darstellung a Shared-Disk- b Shared-Nothing-Systeme „Quelle: Rahm/Saake/Sattler (2015), S. 56“

Abb. 3 Schemaarchitektur eines VDBS „Quelle: Rahm/Saake/Sattler (2015), S. 82“

Abb. 4 Die möglichen drei Optionen des CAP-Theorems „Quelle: Meier/Kaufmann (2016), S. 149“

1 Einleitung

In Unternehmen sind große Mengen an Daten heutzutage nicht mehr wegzudenken. Daten über Warenbestände, Rechnungen, Mitarbeiter etc. werden klassischerweise von Datenbanksystemen (DBS) verwaltet. Zentrale DBS stoßen allerdings schnell an ihre Grenzen, wenn es darum geht große Volumen zu speichern, die Ausfallsicherheit zu stärken oder die Anzahl der Anwender zu groß ist. Auch wenn Unternehmen von mehreren Orten mit demselben Datenbestand arbeiten möchten oder Daten aus Sicherheitsgründen nicht nur auf einem Server gespeichert werden sollen, genügen einfache DBS oft nicht. Um diesen Herausforderungen entgegenzuwirken, werden Verteilte Datenbanksysteme (VDBS) eingesetzt. In dieser Arbeit soll aufgezeigt werden, welche Vor- und Nachteile der Einsatz einer verteilten Datenbank hat und für welchen Bereich sie somit eingesetzt werden kann. Die Grundfunktionen der Verteilten Datenbanken werden beschrieben und die Qualitätsanforderungen an einer Datenbank bestimmt. Zum Schluss wird auf das Ergebnis eingegangen und eine Bewertung vorgenommen.

2 Ziele und Problemstellung

Um den Anforderungen von Standortverteilten Unternehmen gerecht zu werden, kommen VDBS zum Einsatz. Unternehmensdaten werden an verschiedenen Orten benötigt. Des Weiteren werden eine Leistungsverbesserung sowie eine Steigerung der Verfügbarkeit angestrebt. Ein VDBS bringt somit auch einen enormen Verwaltungsaufwand mit sich und muss garantiert funktionieren, da es oft essentieller Bestandteil der täglichen Vorgänge in einem Unternehmen ist. Durch die Verteilung der Daten werden diese an verschiedenen Orten gehalten und verändert. Diese verteilten Daten müssen synchronisiert werden, was zu Konflikten führen kann. Außerdem kann es bei VDBS, dadurch dass viele Prozesse gleichzeitig ausgeführt werden, zu Deadlocks kommen. Bei einem Ausfall oder einem unkontrollierten Programmabbruch muss die Atomarität und Dauerhaftigkeit von Transaktionen garantiert werden. Soll ein bisher zentrales Datenbanksystem dezentralisiert werden, so soll die Verteilung der Daten auf mehrere Sites nicht sichtbar werden. Letztlich wird eine Ortsunabhängigkeit der Anwenderprogramme angestrebt.¹

3 Verteilte Datenbanken

Dieses Kapitel beschäftig sich mit den Grundlagen von verteilten Datenbanken. Verteilte Datenbanken sind Datenbanksysteme, die auf mehreren Rechnerknoten (Sites) verteilt sind.² Wurden am Anfang eine Anzahl von fest definierten Servern festgelegt, spricht man heute von Skalierung. Des Weiteren besteht ein verteiltes Datenbanksystem aus mehreren Datenbankmanagementsystemen (DBMS) und wird durch diese zusammengehalten. Im Fall einer verteilten Datenbank kommt ein Verteiltes Datenbankmanagementsystem (VDBMS) zum Einsatz. DDB unterstützen somit eine geografisch verteile Datenbankverarbeitung sowie eine Anpassung an dezentrale Organisationsstrukturen. Wie Abb. 1 zeigt, besteht ein VDBS aus einer über ein Netzwerk gekoppelten Menge von Sites. Die Datenbasis wird auf Sites verteilt und von einem eigenen VDBMS verwaltet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1 Grobarchitektur eines Verteilten Datenbanksystems „Quelle: Rahm/Saake/Sattler (2015), S. 7“

Eine formulierte Definition, die von C.J. Date stammt besagt:³

„A distributed database system consists of a collection of sites, connected together via some kind of communications network, in which

1. Each site is a database system site in it own right, but
2. The sites have agreed to work together so that a user at any site can access data anywhere in the network exactly as if the data were all stored at the user´s own site.“

Die einzelnen Sites des VDBS haben somit eine größere Unabhängigkeit und Autonomie zur Verwaltung ihrer Daten. Somit kann jeder Standort die Daten seiner Mitarbeiter und Projekte selbstständig verwalten. Gegenüber zentralisierten DBS steigt die Leistungsfähigkeit und die Verfügbarkeit, da mehrere Verarbeitungsrechner zum Einsatz kommen. Bei einem Ausfall eines Rechnerknotens fällt somit nicht das komplette Datenbanksystem, sondern nur die lokale Datenbank aus. Der Ausfall eines zentralen Datenbankservers beispielsweise legt das gesamte System lahm. Die dominierende Form des Datenmanagements ist die relationale Datenbanktechnologie. Ein wesentlicher Vorteil des relationalen Modells liegt darin, dass Anfragen mengenorientiert sind und somit ein größeres Optimierungspotenzial besteht.⁴

3.1 Anforderungen

Ein verteiltes System sollte sich dem Anwender gegenüber genauso wie ein zentrales verhalten. Um diese Anforderung gerecht zu werden, hat C.J. Date zwölf Regeln formuliert, die idealerweise erfüllt sein sollten:⁵

1. Lokale Autonomie
2. Unabhängigkeit von einem zentralen Rechner
3. Ununterbrochenes Arbeiten (Dauerbetrieb)
4. Ortstransparenz
5. Fragmentierungstransparenz
6. Replikationstransparenz
7. Verteilte Abfrageprozesse
8. Verteiltes Transaktionsmanagement
9. Hardwareunabhängigkeit
10. Betriebssystemunabhängigkeit
11. Netzwerkunabhängigkeit
12. DBMS Unabhängigkeit

Jedoch lassen sich nicht alle zwölf Regeln gleichzeitig erfüllen, da sie sich teilweise widersprechen. Während Regeln 1 bis 6 und 9 bis 11 heute in vielen DBS implementiert sind, sind Forderung 7,8 und 12 äußerst anspruchsvoll.⁶

3.2 Architektur

Grundsätzlich wird zwischen homogenen und heterogenen Datenbanksystemen unterschieden. Bei homogen DBS läuft auf jedem Knoten der gleiche Typ des DBMS, wobei bei heterogen DBS auf verschiedenen Knoten verschiedene DBMS laufen. Eine wichtige Aufgabe von DBS ist das Erreichen eines möglichst hohen Grades an Datenunabhängigkeit.⁷ Bei verteilten Datenbanksystemen vom Typ Shared-Disk- und Shared-Nothing-Systemen erfolgt die DB-Verarbeitung jeweils auf mehreren unabhängigen, lose oder nahe gekoppelten Sites mit einer eigenen Instanz des DBMS.⁸ Entscheidet man sich für ein “Shared-Disk-System“ (Abb. 2a), haben alle laufenden DBMS-Prozesse direkten Zugriff auf den gesamten Datenbestand. Dieses System dient einer großen Flexibilität bei der Auswahl eines Verarbeitungsrechners für anstehende Anfragen und Transaktionen und haben daher ein hohes Potenzial zur Lastbalancierung. Bei diesem System kommen meist Externspeicheranbindungen wie Storage Area Networks (SAN) zum Einsatz, die über ein schnelles Verarbeitungsnetzwerk angebunden werden. Dabei sind Bandbreiten von mehreren GB pro Sekunde und eine Anbindung zahlreicher Rechner und damit eine gute Skalierbarkeit möglich. In einem “Shared-Nothing-System“ (Abb. 2b) dagegen werden keine Systemkomponenten, bis auf das Verbindungsnetzwerk genutzt. Die Speicher sind unter den lose gekoppelten Rechnern partitioniert, sodass jeder Knoten nur auf Daten der lokalen Partition zugreifen kann.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2 Schematische Darstellung a Shared-Disk- b Shared-Nothing-Systeme „Quelle: Rahm/Saake/Sattler (2015), S. 56“

Da die Daten bei einer verteilten Datenbank auf mehreren verschiedenen Rechnern gespeichert werden, ist der logische Aufbau einer Datenbank durch ein globales konzeptionelles Schema (GKS) festgelegt. Daneben besitzt jeder Rechner ein lokales konzeptionelles Schema (LKS), sowie ein lokales internes Schema (LIS) (Abb.3). Diese Schemaarchitektur baut auf das Grundmodell der dreistufige Schemaarchitektur ANSI/SPARC auf.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3 Schemaarchitektur eines VDBS „Quelle: Rahm/Saake/Sattler (2015), S. 82“

3.3 Datenverteilung und Katalogverwaltung

Beim Einsatz von verteilten Datenbanksystemen, muss der Datenbestand physisch aufgeteilt werden. Die Bestimmung der Datenverteilung ist zuständig für die Leistungsfähigkeit des Systems, da sie zu einem großen Teil den Kommunikationsaufwand zur DB-Verarbeitung bestimmt.⁹ Um die Vorteile eines VDBS nutzen zu können, sollte man das Augenmerk auf die Fragmentierung und Allokation richten.

3.3.1 Fragmentierung

Werden einzelne Tabellen auf verschiedene Standorte aufgeteilt, spricht man von einer Fragmentierung. Bei der Fragmentierung werden zunächst die Einheiten der Datenverteilung (Fragmente) festgelegt. Dabei unterscheidet man zwischen einer horizontalen und einer vertikalen Fragmentierung. Bei der horizontalen Fragmentierung wird eine Tabelle anhand von Datensätzen aufgeteilt, somit befindet sich an jedem Standort die gleiche Tabellenstruktur (Spalten), jedoch nicht sämtliche Datensätze. Bei der vertikalen Fragmentierung enthält jedes Tabellenfragment alle Datensätze, jedoch nicht alle Informationen (Spalten) jedes Datensatzes.¹⁰

3.3.2 Allokation und Replikation

Nach Festlegung der Fragmentierung folgt der zweite Schritt bei der Datenverteilung: die Allokation (Ortstransparenz). Sie unterstützt die Speicherung der Fragmente bzw. Relation auf unterschiedliche Knoten. Wird dabei keines der Fragmente mehrfach allokiert, erhält man eine partitionierte, anderenfalls eine replizierte Allokation.¹¹ Der Benutzer muss nicht wissen, auf welchem Knoten die Daten gespeichert wurden. Bei der Replikation werden Kopien bestimmter Datensätze auf anderen Knoten gespeichert. So sind beim Ausfall eines Knotens die Daten trotzdem verfügbar. Des Weiteren können somit auch Zugriffszeiten gesenkt werden, da die Replikationen am Knoten mit den meisten Zugriffen auf die Daten gespeichert werden. Allerdings muss beim Mehrfachspeichern mehr Speicherplatz zu Verfügung gestellt werden und alle Kopien bei Änderungen aktualisiert werden.

3.4 Synchronisationsverfahren

Eine der Aufgaben von Datenbanksystemen ist es, dass mehrere Benutzer gleichzeitig lesend und schreibend auf gemeinsame Datenbestände zugreifen können, ohne dass die Konsistenz der Daten verletzt wird. In diesem Kapitel wird auf die meist genutzten Synchronisationsverfahren von DBS eingegangen, die auch beim VDBS zum Einsatz kommen.

3.4.1 Sperrverfahren

Mit einer Sperre werden Teile des DBS für eine Transaktion reserviert. Somit hat diese dadurch ein exklusives Schreib- und Leserecht. Unterschieden wird hier zwischen einem optimistischen und präventiven Sperrverfahren.¹² Bei dem optimistischen Sperrverfahren wird angenommen, dass es keinen Konflikt bei der Ausführung gibt und alle Änderungen durchführt werden. Erst beim Festschreiben wird die Gültigkeit geprüft oder bei Konflikten zurückgenommen. Beim präventiven Sperrverfahren hingegen wird sichergestellt, dass vor Beginn einer Transaktion kein Konflikt entstehen kann. Dies wird mit Sperren auf Datenbankobjekten erreicht, die erst nach Beendigung der Transaktion wieder entfernt werden.

3.4.2 Zeitmarkenverfahren

Bei diesem Verfahren wird ein eindeutiger Zeitstempel zugeordnet, der beim Zugriff am Objekt hinterlegt wird. Dieser Zeitstempel besteht aus der lokalen Uhrzeit und der Rechner-ID. Der Vorteil bei diesem Verfahren gegenüber dem Sperrverfahren liegt darin, dass keine Deadlocks vorkommen können.¹³ Ein Lesezugriff einer Transaktion mit Zeitstempel auf ein Objekt ist nicht zulässig, wenn bereits eine jüngere Transaktion das Objektgeändert hat. So können nur Daten verändert werden, wenn der Schreibzeitstempel kleiner ist, als die vom zugreifenden Benutzer.

3.5 Konsistenzsicherung

Die Integrität der Daten zu gewährleisten ist eine wichtige Forderung aus der Sicht vieler Datenbankanwendungen. Die Transaktionenverwaltung eines Datenbanksystems dient dazu, mehreren Benutzern ein konfliktfreies Arbeiten zu ermöglichen.¹⁴ Dabei dürfen Änderungen in der Datenbank nach außen erst sichtbar werden, wenn die von den Benutzern definierten Integritätsbedingungen alle respektiert sind. Da bei einem Mehrbenutzerbetrieb einer Datenbank mehrere Benutzer gleichzeitig auf Daten zugreifen und diese gegebenenfalls verändern, muss verhindert werden, dass Konfliktsituationen entstehen. Gegenseitige Behinderung (Deadlocks) oder Konsistenzverletzungen (z.B. doppelte Buchungen im Bankenumfeld) dürfen unter keinen Umständen vorkommen. Im Folgenden wird auf das ACID-Protokoll, BASE und das CAP-Theorem eingegangen.

3.5.1 ACID

Die vier Begriffe Atomarität, Konsistenz, Isolation und Dauerhaftigkeit beschreiben das sogenannte ACID-Prinzip einer Transaktion.¹⁵ Dieses Prinzip dient dazu, mehreren Benutzern ein konfliktfreies Arbeiten zu ermöglichen. Konsistente Datenbankzustände werden garantiert und inkonsistente Zustände bleiben nach außen unsichtbar. Bei einem Fehlerfall werden diese rückgängig gemacht. Atomarität bedeutet, dass eine Transaktion entweder komplett durchgeführt wird oder keine Spuren auf der Datenbank hinterlässt.¹⁶ Damit wird ausgeschlossen, dass Transaktionen nur teilweise Änderungen auf der Datenbank ausführen. Bei der Konsistenz können einzelne Konsistenzbedingungen zeitweise verletzt werden, müssen jedoch am Transaktionsende wieder erfüllt werden. Durch das Prinzip der Isolation wird verhindert, dass sich Datenoperationen gegenseitig beeinflussen.¹⁷ Die Dauerhaftigkeit ist zuständig für die Datenbankzustände. Diese müssen so lange gültig sein und erhalten bleiben, bis sie von Transaktionen verändert werden. Bei Systemabbrüchen oder Programmfehlern wird die Wirkung einer korrekt abgeschlossenen Transaktion garantiert.

[...]

¹ Vgl. Dadam (1995), S. 5

² Vgl. Burkhardt (2015), S. 220

³ Date (1995), S. 593f

⁴ Vgl. Rahm/Saake/Sattler (2015), S. 23

⁵ Date (1995), S. 291ff

⁶ Vgl. Schicker (2014), S. 306

⁷ Vgl. Dadam (1996), S. 83

⁸ Vgl. Rahm/Saake/Sattler (2015), S 55

⁹ Vgl. Rahm (1994), S. 59

¹⁰ Vgl. Gunter/Sattler/Heuer (2010), S. 127

¹¹ Vgl. Rahm/Saake/Sattler (2015), S.101

¹² Vgl. Rahm/Saake/Sattler (2015), S. 256

¹³ Vgl. Rahm/Saake/Sattler (2015), S. 258

¹⁴ Vgl. Meier/Kaufmann (2016), S. 135

¹⁵ Vgl. Ernst/Schmidt/Beneken (2016), S. 356

¹⁶ Vgl. Rahm/Saake/Sattler (2015), S. 30

¹⁷ Vgl. Fasel/Meier (2016), S. 30