Verteiltes und Paralleles Datenmanagement

Transkript

1 ERHARD RAHM GUNTER SAAKE KAI-UWE SATTLER Verteiltes und Paralleles Datenmanagement Von verteilten Datenbanken zu Big Data und Cloud

2 examen.press

3 examen.press ist eine Reihe, die Theorie und Praxis aus allen Bereichen der Informatik für die Hochschulausbildung vermittelt.

4 Erhard Rahm Gunter Saake Kai-Uwe Sattler Verteiltes und Paralleles Datenmanagement Von verteilten Datenbanken zu Big Data und Cloud

5 Erhard Rahm Institut für Informatik Universität Leipzig Leipzig, Deutschland Gunter Saake Fakultät für Informatik Otto-von-Guericke Universität Magdeburg, Deutschland Kai-Uwe Sattler Fakultät für Informatik und Automatisierung Technische Universität Ilmenau Ilmenau, Deutschland ISSN ISBN DOI / ISBN (ebook) Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. Springer Vieweg Springer-Verlag Berlin Heidelberg 2015 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Springer Fachmedien Wiesbaden GmbH ist Teil der Fachverlagsgruppe Springer Science+Business Media (

6 Vorwort Verteilte und parallele Verarbeitung in Datenbanken erlebte eine erste Blüte in den 80er- Jahren, als parallele Verarbeitung und geografisch verteilte Speicherung von relationalen Daten erstmals intensiv untersucht wurden. In dieser Ära erschienen ein ganze Reihe von fundamentalen Veröffentlichungen und Lehrbüchern, die die Grundlagen für derartige Verfahren legten. In den darauffolgenden Jahren wurden diese Verfahren genutzt, ohne dass dabei ein erneuter Hype zu beobachten war. Dies änderte sich in den letzten Jahren mit Konzepten wie der Cloud-Speicherung und der Analyse in Big-Data-Szenarien, die nun moderne Anforderungen an die Skalierbarkeit mit 20 Jahre altem Lehrbuchwissen konfrontierten. Auch wenn viele der damaligen Entwicklungen auch nach dieser Zeit unverändert gültig sind, fügen diese neuen Szenarien neue Aspekte hinzu, die damals nicht vorhersehbar waren. Es ist nunmehr Zeit für eine neue Generation von Lehrwissen, das die grundlegenden Methoden mit neuen Entwicklungen in gemeinsamem Kontext behandelt. Das vorliegende Buch ist ein Versuch, diesem Bedarf gerecht zu werden. Die Entstehung dieses Buchs basiert auf zwei Entwicklungen. Einer der Autoren, Erhard Rahm, veröffentlichte bereits 1994 ein umfangreiches Lehrbuch zu Mehrrechnerdatenbanken, das bereits lange aus dem Vertrieb genommen wurde und in den Jahren, als das Thema kein Hype-Thema war, auch nicht aktualisiert wurde. Die anderen beiden Autoren hatten in der letzten Überarbeitung des Buchs Datenbanken-Implementierungstechniken aus Platzmangel die Kapitel zu Aspekten verteilter Datenhaltung, die in den ersten Auflagen noch enthalten waren, stark zusammenkürzen müssen. Gemeinsam haben wir beschlossen, aus dieser Situation das Beste zu machen und Ideen und teilweise auch Inhalte, die nicht mehr als aktueller Lehrbuchinhalt verfügbar waren, gemeinsam in ein neues Lehrbuch zu integrieren die Idee zum vorliegenden Buch war geboren. Das vorliegende Buch ist in vier Teile gegliedert. Teil I ist eine breit angelegte Einführung, die die wesentlichen Architekturen, insbesondere Verteilte und Parallele DBS, aber auch neuere NoSQL- und Big-Data-Ansätze, überblicksartig einführt und klassifiziert. Der Teil II vertieft die Methoden der Datenverteilung als Grundlage verteilter Datenzugriffe. Ausführlich wird die Datenallokation für Parallele Datenbanksysteme, inklusive NoSQL- Systemen, betrachtet. V

7 VI Vorwort Teil III behandelt die Methoden der verteilten und parallelen Anfragebearbeitung. Der Anfragebearbeitung in verteilten Systemen, in Parallelen DBS sowie der parallelen Analyse mit MapReduce ist jeweils ein umfangreiches Kapitel gewidmet. Der abschließende Teil IV ist den Fragen der Konsistenz gewidmet. Verteilte Transaktionen und deren Synchronisationwerden in zwei Kapiteln behandelt. Replikation ist zentral für eine effiziente Anfragebearbeitung in verteilten Systemen und zwingend für eine hohe Verfügbarkeit und wird daher in einem Kapitel behandelt. Die speziellen Anforderungen an die Transaktionsverarbeitung für Shared-Disk-Architekturen werden in einem separaten Kapitel ausführlich betrachtet. Die Frage der Konsistenz in Cloud-Datenbanken, die zugunsten der Verfügbarkeit Kompromisse in der Konsistenz des Datenbestandes eingehen, wird in einem gesonderten Kapitel behandelt. Alle Kapitel sind mit Übungsaufgaben zur Vertiefung und Anwendung des erworbenen Wissens versehen. Gedacht ist das Buch als Basis für eine Master-Vorlesung bzw. fortgeschrittenen Bachelor-Veranstaltung in Informatikstudiengängen. Einzelthemen der verteilten und parallelen Datenhaltung spielen auch eine Rolle in Vorlesungen zur Datenbankimplementierung und zur skalierbaren Analyse im Big-Data-Umfeld. Das Buch ist aber auch für Praktiker geeignet, die sich einen Überblick über Methoden und Techniken der skalierbaren Datenhaltung unter Nutzung von Verteilung und Parallelisierung verschaffen wollen. Eine ganze Reihe von Mitarbeitern in den drei Arbeitsgruppen haben Kapitel Korrektur gelesen. Unser Dank gilt hier Patrick Arnold, Fabian Benduhn, David Broneske, Victor Christen, Anika Groß, Martin Junghanns, Veit Köppen, Markus Nentwig, Eric Peukert, Ziad Sehili und Christian Wartner. In der Anfangszeit war David Broneske intensiv in das Buchprojekt eingebunden. Sebastian Schultz half uns später beim Setzen der Abbildungen. Leipzig, Magdeburg und Ilmenau, im Januar 2015 Erhard Rahm, Gunter Saake und Kai-Uwe Sattler

8 Inhaltsverzeichnis Teil I Einführung 1 Einleitung Von der zentralisierten zur verteilten Datenverarbeitung Anforderungen an verteilte und parallele DMS Maße der parallelen Datenverarbeitung: Speedup und Scaleup Übungsaufgaben Grundlagen zu Datenbanken und verteilten Systemen Relationales Datenmodell Aufbau von Datenbanksystemen Schemaarchitektur Funktioneller Aufbau relationaler Datenbanksysteme Das Transaktionskonzept (ACID) DBS-Einsatz: OLTP vs. OLAP Online Transaction Processing OLAP und Data Warehouses NoSQL-Systeme Rechnernetze und verteilte Systeme Typen von Rechnernetzen Kommunikationsprotokolle Kommunikation in Clustern und Datencentern Übungsaufgaben Architekturen für verteiltes und paralleles Datenmanagement Arten der Parallelverarbeitung Transaktions-, Query- und Operatorparallelität Daten- vs. Pipelineparallelität Verarbeitungs- vs. E/A-Parallelität Klassifikationskriterien Daten-/Externspeicherzuordnung VII

9 VIII Inhaltsverzeichnis Räumliche Anordnung Rechnerkopplung Parallele DBS-Architekturen Shared Everything Shared Disk vs. Shared Nothing Architekturen mit funktionaler Spezialisierung Client-Server-Systeme Hardwareunterstützung zur DB-Verarbeitung Alternativen zur Unterstützung heterogener DBS Hadoop als Big-Data-Plattform Das verteilte Dateisystem HDFS Hadoop s MapReduce-Engine Weitere Hadoop-Komponenten Vergleich und qualitative Bewertung Vergleich verteilter Architekturen zur Datenbankverarbeitung Architekturen für Big Data Übungsaufgaben Teil II Katalogverwaltung und Datenverteilung 4 Schemaarchitektur und Katalogverwaltung Schemaarchitektur von Verteilten DBS Katalogverwaltung Namensverwaltung Objektnamen in Verteilten DBS Nutzung globaler Namensräume Übungsaufgaben Grundlagen der Datenverteilung Fragmentierung Horizontale Fragmentierung Vertikale Fragmentierung Hybride Fragmentierung Fragmentierungstransparenz Allokation und Replikation Bestimmung der Datenverteilung Übungsaufgaben Datenverteilung in Parallelen DBS Bestimmung des Verteilgrades Fragmentierung Basisansätze

10 Inhaltsverzeichnis IX Verfeinerte Bereichsfragmentierung Mehrdimensionale Fragmentierung Mehrstufige Fragmentierung Allokation Replikation Spiegelplatten/Disk-Arrays Verstreute Replikation Verkettete Replikation Datenverteilung für Shared Everything und Shared Disk Verteil- und Parallelitätsgrad Fragmentierung Indexallokation Replikation Datenallokation in NoSQL-Systemen Consistent Hashing Auto-Sharding in MongoDB Teil III Anfrageverarbeitung 7 Grundlagen der Anfrageverarbeitung Phasen der Anfrageverarbeitung Planoperatoren Scan Sortieren Verbund Pipelining Kostenmodelle Anfrageoptimierung Übungsaufgaben Verteilte Anfrageverarbeitung Phasen der verteilten Anfrageverarbeitung Datenlokalisierung und Anfragezerlegung Datenlokalisierung bei primärer horizontaler Fragmentierung Datenlokalisierung bei abgeleiteter horizontaler Fragmentierung Datenlokalisierung bei vertikaler Fragmentierung Datenlokalisierung bei hybrider Fragmentierung Kostenmodelle für verteilte Anfragen Verteilte Verbundberechnung Ship Whole vs. Fetch Matches Semiverbund

11 X Inhaltsverzeichnis Weitere Verbundvarianten Mehr-Wege-Verbunde Übungsaufgaben Parallele Anfrageverarbeitung Parallele Realisierung unärer Anfrageoperatoren Paralleles Sortieren Parallele Verbundberechnung Dynamische Replikation Dynamische Partitionierung Parallele Hash-Verbunde Verbundberechnung für Multicore-Systeme Der Exchange-Operator Optimierung und Ressourcenallokation Optimierung von Mehr-Wege-Verbunden Prozessorallokation Skew-Behandlung Übungsaufgaben Parallele Analyse großer Datenmengen mit MapReduce Grundlagen MapReduce als Programmiermodell MapReduce-Programmierung mit Hadoop Datenbankoperationen mit MapReduce Datenflusssprachen für MapReduce Apache Spark Übungsaufgaben Teil IV Konsistenzsicherung 11 Verteilte Transaktionsausführungen Struktur verteilter Transaktionen Konsensus-Protokolle Das Zwei-Phasen-Commit Das Zwei-Phasen-Commit-Protokoll Probleme beim 2PC Varianten des 2PC Lineares 2PC Verteiltes 2PC Hierarchisches 2PC Das Drei-Phasen-Commit-Protokoll

12 Inhaltsverzeichnis XI Phasen des Drei-Phasen-Commit-Protokolls Probleme des Drei-Phasen-Commit-Protokolls Das Paxos-Protokoll Recovery Klassisches Recovery Recovery in verteilten DBMS Strukturierte Transaktionen Geschachtelte Transaktionen Geschlossen geschachtelte Transaktionen Offen geschachtelte Transaktionen Eigenschaften geschachtelter Transaktionen Übungsaufgaben Synchronisationsverfahren Grundlagen der Synchronisation Serialisierbarkeitsbegriffe Abhängigkeitsgraphen Anforderungen für Verteilte DBS Sperrverfahren in Verteilten DBS Zentrale Sperrprotokolle Verteilte Sperrverfahren Zeitmarkenverfahren Prinzip des Zeitmarkenverfahrens Realisierung des Zeitmarkenverfahrens Optimistische Synchronisation Validierungsansätze Zentrale Validierung Verteilte Validierung Mehrversionensynchronisation Grundlagen Mehrversionenansätze mit zentralisierter Kontrolle Verteilte Mehrversionensynchronisation Deadlock-Behandlung Deadlock-Verhütung und -Vermeidung Timeout-Verfahren Deadlock-Erkennung Hybride Strategien Übungsaufgaben Replikation Replikation in verteilten Datenbanksystemen Klassifikation von Replikationsansätzen

13 XII Inhaltsverzeichnis Synchrone Aktualisierung mit Primärkopie Synchrone Aktualisierung mit verteilten Änderungen Verzögerte Aktualisierung mit Primärkopie Verzögerte Aktualisierung mit verteilten Änderungen Klassifikation pessimistischer Replikationsstrategien Write-All-Ansätze Primary-Copy-Verfahren Votingverfahren Mehrheitsvotieren (Majority Consensus) Gewichtetes Votieren (Quorum Consensus) Schnappschussreplikation Katastrophen-Recovery Systemstruktur Commit-Behandlung Geo-Replikation Übungsaufgaben Transaktionsverarbeitung für Shared Disk Systemeigenschaften und Herausforderungen Synchronisation in Shared-Disk-DBS Verfahrensüberblick Globale Sperrverwaltung auf dedizierten Rechnern Nutzung von Lese- und Schreibautorisierungen Verteilte Sperrverfahren mit fester GLA-Zuordnung Verteilte Sperrverfahren mit dynamischer GLA-Zuordnung Kohärenzkontrolle Behandlung von Pufferinvalidierungen Update-Propagierung On-Request-Invalidierung Einsatz von Haltesperren Zusammenfassende Bewertung Logging und Recovery Nah gekoppelte Shared-Disk-Systeme Einsatzformen der nahen Kopplung Realisierungsalternativen IBM Parallel Sysplex und DB2 PureScale Übungsaufgaben Konsistenz in Cloud-Datenbanken Konsistenzanforderungen in Cloud-Szenarien Von ACID zu BASE Das CAP-Theorem

14 Inhaltsverzeichnis XIII Abgeschwächte Konsistenzmodelle Replikation in Cloud-Datenbanken Optimistische Replikation Phasen der optimistischen Replikation Konflikterkennung und Strategien der Konfliktauflösung Vektoruhren Epidemische Propagierung Konsistenz in kommerziellen Cloud-Datenbanken Übungsaufgaben Sachverzeichnis

15 Teil I Einführung Der einführende Teil des Buchs umfasst drei Kapitel. In der Einleitung werden die Beschränkungen zentralisierter Ansätze sowie die Anforderungen an die verteilte und parallele Datenverarbeitung, auch für sogenannte Big-Data-Anwendungen, vorgestellt. Daneben werden schon wichtige Vertreter verteilter und paralleler Datenmanagementsysteme kurz vorgestellt sowie grundlegende Maße der Parallelverarbeitung (Speedup, Scaleup) eingeführt. Kapitel 2 widmet sich den Grundlagen von Datenbanken (relationale Datenbanksysteme, Transaktionskonzept) und verteilten Systemen, die für das weitere Verständnis benötigt werden. Es wird dabei auch auf wesentliche Einsatzformen von Datenbanksystemen (OLTP, OLAP) und NoSQL-Systeme eingegangen. In Kap. 3 werden dann wesentliche Architekturen zur verteilten und parallelen Datenverarbeitung klassifiziert und verglichen. Ebenso werden verschiedene Arten der Parallelverarbeitung unterschieden.

16 Einleitung 1 Unternehmen und Einrichtungen verarbeiten eine ständig wachsende Menge an Daten, die klassischerweise von Datenbanksystemen (DBS) verwaltet werden. Das DBS besteht dabei aus der eigentlichen Datenbank (DB) sowie dem Datenbankverwaltungsbzw. Datenbankmanagementsystem (DBMS). In der Praxis dominieren relationale DBS, welche die Datenbanken gemäß dem relationalen Datenmodell strukturieren und die standardisierte und mächtige Anfragesprache SQL für den DB-Zugriff unterstützen. Die Verarbeitung erfolgt innerhalb von Transaktionen, die i. Allg. aus mehreren DB-Operationen der Anfragesprache bestehen. Das DBS garantiert, dass Änderungen erfolgreich beendeter Transaktionen die Konsistenz der Datenbank bewahren und permanent sind, also auch durch Fehler wie Rechner- oder Externspeicherausfälle nicht verloren gehen. Die sichere und schnelle Verarbeitung von Transaktionen ist zur Realisierung operationaler Anwendungen für die meisten Unternehmen unabdingbar, z. B. zur Bearbeitung von Bankaufträgen wie Überweisungen sowie von Reservierungs- und Bestellvorgängen im E-Commerce. Für solche zunehmend über Webschnittstellen genutzten OLTP-Anwendungen (Online Transaction Processing) ist es notwendig, sehr kurze Bearbeitungszeiten sowie eine Skalierbarkeit für sehr viele gleichzeitig aktive Nutzer zu unterstützen. Zudem ist eine ständige Verfügbarkeit der OLTP-Anwendungen und damit der beteiligten Datenbanken essenziell. Neben OLTP-Transaktionen sind auf Datenbanken zur Unterstützung von Unternehmensentscheidungen (Decision Support) auch umfassende Analysen durchzuführen. In Abgrenzung zu OLTP spricht man dann von OLAP (Online Analytical Processing). Die Analysen werden häufig in Data-Warehouse-Systemen, auf einer eigenen für die Analysen ausgerichteten Datenbank, durchgeführt. Zur verbesserten Aussagekraft der Analysen integriert ein Data Warehouse dabei Daten aus unterschiedlichen Quellen und erfordert somit eine geeignete Integration heterogener Daten. Die Durchführung von Analysen stellt aufgrund der typischerweise großen Datenmengen und hohen Anfragekomplexität sehr hohe Leistungsanforderungen. Springer-Verlag Berlin Heidelberg 2015 E. Rahm, G. Saake, K.-U. Sattler, Verteiltes und Paralleles Datenmanagement, examen.press, DOI / _1 3

17 4 1 Einleitung Client Client Abb. 1.1 Zentralisierte Datenbankverarbeitung Applikationsserver Applikationsserver Datenbankserver Die traditionelle DB-Verarbeitung ist zentralisiert, d. h., die Datenbank wird von einem DBMS auf einem Serverrechner verwaltet. Wie in Abb. 1.1 gezeigt, laufen die Anwendungsprogramme, die auf die Datenbank zugreifen, in der Regel auf eigenen Applikationsservern. Nutzer (Clients) können über Browser von unterschiedlichen Geräten (z. B. PCs oder Smartphones) auf die Anwendungen und damit die Datenbank zugreifen. Anwendungsseitig kann die Skalierbarkeit einer solchen Konfiguration durch zusätzliche Applikationsserver verbessert werden. Die Anforderungen von OLTP- und Analyseanwendungen können zunehmend nicht mehr von zentralisierten DBS erfüllt werden. Somit werden verteilte und parallele Ansätze zur Datenbankverarbeitung benötigt, deren Behandlung den Schwerpunkt dieses Buchs darstellt. Wir werden daneben auch aktuelle Ansätze zur parallelen und verteilten Datenverarbeitung in sogenannten NoSQL-Systemen berücksichtigen. Diese basieren nicht auf relationalen Datenbanken, sondern verwalten Sätze (als Schlüssel-Wert-Paare), Dokumente oder Graphen in eigenen Arten von Datenmanagementsystemen (DMS) (s. Abschn. 2.5). Die entsprechenden Ansätze wurden vorrangig im Webumfeld, u. a. von Unternehmen wie Google und Amazon, zur Unterstützung einer hohen Skalierbarkeit bezüglich des Datenvolumens und der Anzahl von Nutzern entwickelt. Das Buch behandelt somit nicht nur parallele und verteilte Datenbanksysteme, sondern allgemeinere parallele und verteilte DMS. Der Betrieb dieser Systeme kann entweder in den Unternehmen und Einrichtungen erfolgen, in denen die Daten anfallen und verarbeitet werden, oder aber innerhalb von über das Internet erreichbaren Cloud-Plattformen. Wir werden daher auch auf die Nutzung von in der Cloud betriebenen Datencentern eingehen. In diesem einleitenden Kapitel sollen zunächst die Beschränkungen zentralisierter DBS diskutiert und einige Vertreter von parallelen und verteilten DMS kurz vorgestellt werden. Genauere Definitionen sowie eine Klassifikation und Abgrenzung der wesentlichen Alternativen erfolgen in Kap. 3. Der Abschn. 1.2 detailliert die Anforderungen an parallele und verteilte DMS, die von den einzelnen Architekturen und Realisierungsansätzen in unterschiedlichem Umfang adressiert werden. Abschließend werden noch grundlegende

18 1.1 Von der zentralisierten zur verteilten Datenverarbeitung 5 Maße zur Bewertung der parallelen Datenverarbeitung, Speedup und Scaleup, sowie die sogenannten Gesetze von Amdahl und Gustafson vorgestellt. 1.1 Von der zentralisierten zur verteilten Datenverarbeitung Die zentralisierte Datenbankverwaltung hat den Vorteil der Einfachheit, sowohl in der Nutzung durch Anwendungen als auch in der Administration. Allerdings führt ein einziger DB-Server oft zu inakzeptablen Leistungs- und Verfügbarkeitsproblemen. Die Leistungsanforderungen können bei großen Datenmengen und Nutzerzahlen selbst bei den üblichen Multiprozessorrechnern vielfach nicht ausreichend erfüllt werden. Weiterhin führt die zentralisierte Lösung zu einer geringen Verfügbarkeit, da bei Ausfall des zentralen DB-Servers kein Datenzugriff mehr möglich ist, wenn nicht ein Reserverechner die Verarbeitung fortsetzen kann. Längere Ausfallzeiten beim Datenbankbetrieb sind jedoch in vielen OLTP-Anwendungsbereichen, wie etwa im E-Commerce oder im Finanzsektor, völlig inakzeptabel. Eine weitere Beschränkung zentralisierter DBS liegt darin, dass sie der Organisationsform großer Unternehmen nicht gerecht werden. Diese verlangen oft, die Daten dort zu verwalten, wo sie anfallen und hauptsächlich verwendet werden, was geografisch verteilte Datenbanken an mehreren Standorten erfordert. Dennoch soll es dabei für übergreifende Aufgaben möglich bleiben, auf die Daten anderer Standorte zuzugreifen. Aufgrund der Beschränkungen zentralisierter Datenbanksysteme wurden unterschiedliche Typen verteilter und paralleler DBS bzw. sogenannter Mehrrechner-Datenbanksysteme [14] entwickelt, bei denen die Daten über mehrere Rechner hinweg verteilt gespeichert bzw. koordiniertverarbeitetwerden. Hierzu zählen Parallele DBS und Verteilte DBS, die wir im Folgenden kurz einführen. Zudem lassen sich diese Ansätze kombinieren, etwa in geografisch verteilten Datencentern mit replizierten Daten. Für NoSQL-DMS werden architekturseitig ähnliche Alternativen verfolgt wie für Parallele und Verteilte DBS, trotz Unterschieden hinsichtlich der angestrebten Funktionalität und damit der Realisierung. Wir sprechen daher auch die DBS-Nutzung in der Cloud sowie den Einsatz von NoSQL- DMS an. Parallele Datenbanksysteme Die Leistungs- und Verfügbarkeitsbeschränkungen zentralisierter DBS lassen sich durch den Einsatz eines Parallelen DBS [5] weitgehend beheben, in dem Transaktionen und Anfragen einer Datenbank parallel auf mehreren Prozessoren bzw. Rechnern in einem lokalen Cluster bzw. Datencenter ausgeführt werden (Abb. 1.2). Dabei werden i. Allg. mehrere DB-Server genutzt, die über ein Hochgeschwindigkeitsnetz gekoppelt sind. Pro Knoten wird eine identische Instanz des DBMS ausgeführt. Die DBMS-Instanzen arbeiten eng zusammen, um gegenüber Anwendungen sämtliche Aspekte der Verteilung zu verbergen. Für die Zuordnung der physischen Datenbank auf den Externspeichern

19 6 1 Einleitung Abb. 1.2 Einsatz eines Parallelen Datenbanksystems (vom TypSharedDisk) Client Client Paralleles DBS Applikationsserver Applikationsserver Datenbankserver Datenbankserver (i. Allg. Magnetplatten) zu den DBMS bestehen zwei wesentliche Alternativen. In sogenannten Shared-Nothing-Systemen werden die Externspeicher und Daten partitioniert, sodass jedes DBMS eine Partition der Daten zugeordnet bekommt. Dagegen kann in Shared-Disk-Systemen, wie in Abb. 1.2 gezeigt, jeder DB-Server direkt auf sämtliche Externspeicher und damit die gesamte Datenbank zugreifen. Bei der Nutzung mehrerer Prozessoren eines einzigen DB-Servers spricht man bereits ebenfalls von einem Parallelen DBS (vom Typ Shared Everything, s.kap.3), da hierbei auch eine Parallelverarbeitung beim DB-Zugriff unterstützt wird. Trotz der generell zunehmenden Anzahl von Prozessoren und Cores pro Rechner bleiben jedoch wesentliche Nachteile zentralisierter DBS bezüglich Verfügbarkeit und Skalierbarkeit bestehen, sodass Shared Disk und Shared Nothing als Hauptalternativen von Parallelen DBS anzusehen sind. Allen Parallelen DBS ist gemein, dass die Rechner und Prozessoren einerseits zur parallelen (gleichzeitigen) Verarbeitung vieler unabhängiger Transaktionen und Anfragen genutzt werden kann, was insbesondere für hohe Transaktionsraten und damit die Skalierbarkeit von OLTP-Anwendungen wesentlich ist. Andererseits kann eine parallele Bearbeitung einzelner, aufwendiger DB-Operationen erfolgen, um deren Ausführungszeit zu reduzieren. Dies ist vor allem für komplexe Analysen auf großen Datenmengen, insbesondere für Data Warehouses, erforderlich. Durch den Einsatz mehrerer DB-Server kann für Shared Nothing und Shared Disk auch der Ausfall einzelner Rechner zur Sicherstellung einer hohen Verfügbarkeit überbrückt werden. Verteilte Datenbanksysteme Verteilte Datenbanksysteme [4, 12] unterstützen, anders als Parallele DBS, eine geografisch verteilte Datenbankverarbeitung sowie eine Anpassung an dezentrale Organisationsstrukturen. Wie Abb. 1.3 zeigt, besteht ein Verteiltes DBS aus einer über ein allgemeines (Weitverkehrs-)Netzwerk gekoppelten Menge von Rechnerknoten, die ähnlich

20 1.1 Von der zentralisierten zur verteilten Datenverarbeitung 7 Abb. 1.3 Grobarchitektur eines Verteilten Datenbanksystems zu Shared-Nothing-Systemen jeweils eine eigene DBMS-Instanz ausführen sowie einen Teil der Datenbank verwalten. Somit können die an verschiedenen Unternehmensorten anfallenden Daten durch jeweils einen Knoten lokal verwaltet werden. Die DBMS kooperieren miteinander, um dennoch auf die Daten aller Knoten zugreifen zu können. Im Gegensatz zu Parallelen DBS sollen die Knoten in Verteilten DBS eine größere Unabhängigkeit oder Autonomie zur Verwaltung ihrer Daten erhalten, um lokalen Anforderungen Rechnung zu tragen. Somit könnte etwa jeder Standort die Daten seiner Mitarbeiter und Projekte selbstständig verwalten und dabei zu beachtende Besonderheiten unterstützen. Zugleich kann insgesamt der Kommunikationsaufwand zur DB-Verarbeitung begrenzt werden, wenn die Mehrzahl der Zugriffe auf lokale Daten entfällt. Gegenüber zentralisierten DBS erlaubt der Einsatz mehrerer Verarbeitungsrechner eine gesteigerte Leistungsfähigkeit und Verfügbarkeit. Der Ausfall eines Rechners betrifft lediglich dessen lokale Daten; auf die restliche Datenbank kann weiterhin zugegriffen werden. Durch replizierte Speicherung der Daten an verschiedenen Knoten lässt sich die Verfügbarkeit weiter verbessern. Nachteilig im Vergleich zu Parallelen DBS ist die gegenüber lokalen Clustern meist weit langsamere Kommunikation in Weitverkehrsnetzen. Zudem ist die Kommunikation i. Allg. weniger zuverlässig, und es kann zu sogenannten Netzwerk- Partitionierungen kommen, sodass Teile des Systems zeitweise nicht mehr miteinander kommunizieren können. Auch ist die Datenbankadministration in Verteilten DBS aufwendiger als in Parallelen DBS, da pro Knoten eine eigene Systemverwaltung vorzusehen ist, um lokalen Anforderungen Rechnung zu tragen. Ein potenzielles Problem von Parallelen DBS liegt in der eingeschränkten Verfügbarkeit gegenüber katastrophalen Fehlern wie Erdbeben, Überschwemmungen oder Terroranschlägen, die zum vollständigen Ausfall eines Clusters und damit zum kompletten Verlust der Daten führen können. Dieses Problem kann durch die Replikation der Daten an geografisch entfernten Systemen (Geo-Replikation, vgl. Abschn ) behandelt werden. Hieraus resultiert eine Kombination aus Parallelen und Verteilten DBS mit z. B. zwei oder mehr geografisch verteilten Datencentern, die jeweils von einem Parallelen DBS verwaltet werden (Abb. 1.4). Die Daten werden dabei zwischen den Datencentern repliziert, wobei durchgeführte Änderungen fortwährend auszutauschen sind, um die Replikate aktuell zu halten und einen Datenverlust im Katastrophenfall zu vermeiden.