Analyse und Einsatzmöglichkeiten horizontaler Partitionierung in Oracle Datenbanken

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Listingverzeichnis

1 Einleitung
1.1 Motivation und Ziele der Arbeit
1.2 Abgrenzung
1.3 Aufbau und Struktur der Arbeit

2 Grundlagen
2.1 Online Transaction Processing (OLTP)
2.2 Konsistenzkonzepte
2.2.1 CAP-Theorem
2.2.2 BASE
2.2.3 ACID
2.3 NoSQL
2.3.1 Cassandra
2.3.2 MongoDB
2.4 Oracle DB Grundlagen
2.4.1 Oracle Global Data Services
2.4.2 Connection Pools
2.5 Sharding
2.5.1 Definition Sharding
2.5.2 Definition Skalierbarkeit
2.5.3 Architektur Oracle Sharding
2.5.4 Oracle Sharding Datenmodell und Applikationsanforderungen
2.5.5 Lizenzen
2.6 Oracle Real Application Cluster (RAC)
2.6.1 Architektur

3 Oracle Sharding
3.1 Vorbereitung
3.1.1 Vorbereitung der Applikation
3.1.2 Vorbereitung Hardware/Deployment
3.2 Aufbau einer Sharding Umgebung
3.2.1 Installation/Einrichtung
3.2.2 Erstellen der Sharded Database (SDB)
3.2.3 Erstellen des Schemas der SDB
3.3 Vergleich mit RAC unter verschiedenen Kriterien
3.3.1 Evaluieren der Kriterien
3.3.2 Architektur
3.3.3 Kompatibilität
3.3.4 Hochverfügbarkeit
3.3.5 Skalierbarkeit
3.3.6 Datenverteilung
3.3.7 Total Cost of Ownership
3.3.8 CAP-Theorem
3.3.9 Fazit
3.4 Vergleich mit NoSQL unter verschiedenen Kriterien
3.4.1 Evaluieren der Kriterien
3.4.2 Architektur
3.4.3 Skalierbarkeit
3.4.4 ACID
3.4.5 Relationale Abfragen/SQLs
3.4.6 Replikation/Hochverfügbarkeit
3.4.7 CAP-Theorem
3.4.8 Total Cost of Ownership
3.5 Entscheidungsmatrix

4 Schlussbetrachtung
4.1 Zusammenfassung
4.2 Fazit
4.3 Ausblick

Anhang

Quellenverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Quelle: Big Data: Grundlagen, Systeme und Nutzungspotenziale (Daniel Faser, Andreas Meier), S. 34

Abbildung 2: Quelle: Oracle White Paper Global Data Services, S. 5

Abbildung 3: Quelle: Eigene Zusammenstellung

Abbildung 4: Quelle: Oracle White Paper: Oracle Sharding, S.4

Abbildung 5: Quelle: Oracle White Paper: Oracle Sharding, S.10

Abbildung 6: Quelle: Oracle White Paper: Oracle Sharding, S.11

Abbildung 7: Quelle: Expert Oracle 12c, S. 5

Abbildung 8: Installation und Einrichtung für eine Sharded Database Quelle: Eigene Zusammenstellung (Aktivitätsdiagramm UML 2.0)

Abbildung 9: Installation und Einrichtung für eine Sharded Database Quelle: Eigene Zusammenstellung (Aktivitätsdiagramm UML 2.0)

Abbildung 10: Quelle: Oracle White Paper Oracle Sharding, S. 15

Abbildung 11: Quelle: Oracle White Paper Global Data Services, S. 5

Abbildung 12: Quelle: Eigen

Abbildung 13: Quelle: https://medium.com/netflix-techblog/benchmarking-cassandra-scalability-on-aws-over-a-million-writes-per-second- 39f45f066c9e

Abbildung 14: Shard Catalog Konfiguration Teil 1 Quelle: Eigen

Abbildung 15: Shard Catalog Konfiguration Teil 2 Quelle: Eigen

Listingverzeichnis

Listing 1: ’CREATE SHARDED TABLE’

Listing 2: ’CREATE SHARDED TABLE’

Listing 3: ’Umgebungsvariablen’ Quelle: vgl. Oracle, 2018g

Listing 4: ’DB-Parameter’ Quelle: vgl. Oracle, 2018g

Listing 5: ’GSMCATUSER’ Quelle: vgl. Oracle, 2018g

Listing 6: ’Create Administator Schema’ Quelle: vgl. Oracle, 2018g

Listing 7: ’Create Shardcatalog’ Quelle: vgl. Oracle, 2018g

Listing 8: ’Add GSM’ Quelle: vgl. Oracle, 2018g

Listing 9: ’Add Credential’ Quelle: vgl. Oracle, 2018g

Listing 10: ’Remote Scheduler Agent’ Quelle: vgl. Oracle, 2018g

Listing 11: ’Validate Shard’ Quelle: vgl. Oracle, 2018h

Listing 12: ’Remote Scheduler Agent’ Quelle: vgl. Oracle, 2018h

Listing 13: ’CREATE SHARD’ Quelle: vgl. Oracle, 2018h

Listing 14: ’ADD SHARD’ Quelle: vgl. Oracle, 2018h

Listing 15: ’Config’ Quelle: vgl. Oracle, 2018h

Listing 16: ’Deploy’ Quelle: vgl. Oracle, 2018h

Listing 17: ’Überprüfen’ Quelle: vgl. Oracle, 2018h

Listing 18: ’Add Service’ Quelle: vgl. Oracle, 2018h

Listing 19: ’User app_schema’ Quelle: vgl. Oracle, 2018i

Listing 20: ’Root Tabelle’ Quelle: vgl. Oracle, 2018i

Listing 21: ’Überprüfen des Shards’ Quelle: vgl. Oracle, 2018i

1 Einleitung

In diesem Kapitel wird die Motivation, sowie die Ziele für die Anfertigung der Ar- beit, aufgezeigt. Weiterhin wird eine Abgrenzung zu nicht behandelten Themen vor- genommen. Zum Schluss erläutert der Autor den Aufbau und die Struktur der Ar- beit.

1.1 Motivation und Ziele der Arbeit

Täglich entstehen riesige Mengen an Daten. Besonders in Unternehmen werden vie- le Daten verwaltet und gespeichert. Dabei spielen Social Media, digitale Dokumente, digitale Kommunikation und viele weitere Quellen eine große Rolle. Nahezu jedes mo- bile Geräte ist miteinander vernetzt und sammelt Daten über seinen Nutzer und deren Verhalten. Diese große Menge an Daten muss gespeichert und verarbeitet werden. In diesem Bereich stoßen herkömmliche relationale Datenbanken an Ihre Grenzen.

Um diese Menge an Informationen zu verarbeiten wurden NoSQL-Datenbanken ent- wickelt, welche in diesem Bereich ihre Stärken haben. Sie verteilen die Datenbank auf mehrere Server durch das sogenannte Sharding. Dadurch sind sie in der Lage, beliebig zu skalieren und sich an die Menge der Daten anzupassen. Als Konkurrenzprodukt hat Oracle nun das Oracle Sharding entwickelt. Das Oracle Sharding soll eine Oracle Da- tenbank beliebig skalieren und dabei das relationale Datenbankmodell wahren. Damit passt sich Oracle an die „neuen“ Anforderungen der heutigen Zeit an.

Das Ziel dieser Arbeit ist es Vorteile des neuen Features Oracle Sharding zu erarbeiten und diese in einer Entscheidungsmatrix zusammenzufassen. Mithilfe der Matrix soll es möglich sein, Einsatzmöglichkeiten des Oracle Shardings abzuleiten. Dabei wird im Besonderen Wert auf das Erstellen einer Sharding Umgebung und dem Vergleich mit gleichartigen Technologien gelegt. Das Feature wird ganzheitlich analysiert im Bezug auf seine Vorteile gegenüber anderen Technologien.

Diese Arbeit richtet sich an Entscheider, welche sich mit möglichen Technologien zur Skalierung von Datenbanken auseinander setzen, als auch an Datenbankadministratoren, die eine Sharding Umgebung umsetzen.

Das Oracle Sharding wurde ausgewählt, da es sich um eine zukunftsorientierte Techno- logie handelt. Diese wird im Hinblick auf ihre Einsatzmöglichkeiten genauer analysiert.

Mit den Ergebnissen dieser Arbeit wird das Angebotsspektrum der ORDIX-Schulungen im Oracle Bereich erweitert.

1.2 Abgrenzung

Diese Arbeit bezieht sich ausschließlich auf die von Oracle angebotenen Produkte Oracle Sharding und Oracle RAC, sowie die beiden NoSQL-Datenbanken Cassandra und Mon- goDB. Produkte zur horizontalen Skalierung von Drittanbietern werden nicht betrachtet. Des Weiteren wird in der gesamten Arbeit die Version Oracle 12.2 betrachtet und somit die erste Version des Oracle Shardings. Spätere Versionen werden nicht miteinbezogen. Aufgrund des zeitlichen Rahmens und der Komplexität jeder Datenbank, wird im Ver- gleich mit NoSQL-Datenbanken nur auf die beiden Lösungen Cassandra und Mon- goDB eingegangen. Diese beiden NoSQL-Datenbanken stehen exemplarisch für alle NoSQL-Lösungen. Sie stellen aber keinen ganzheitlichen Vergleich mit allen NoSQL- Datenbanken dar.

1.3 Aufbau und Struktur der Arbeit

Die vorliegende Arbeit lässt sich in vier Bereiche gliedern.

Das erste Kapitel ist die Einleitung. Dort erfolgt eine Einführung in das Thema der Arbeit. Es werden Motivation und Ziele, sowie der Aufbau und die Struktur der Arbeit aufgezeigt. Zudem wird eine Abgrenzung zu nicht behandelten Themen und Bereichen vorgenommen.

Das Kapitel 2 behandelt die Grundlagen zum Thema der Arbeit. Dazu wird zuerst auf die Definition von Online-Transaction-Processing (OLTP)-Applikationen eingegangen. Zudem wird das CAP-Theorem und die beiden Konzepte ACID und BASE erläutert. Anschließend werden die Grundlagen der beiden NoSQL-Datenbanken aufgezeigt. Da- nach wird ein Überblick über das Sharding und die Begrifflichkeiten zu dem Thema gegeben. Im Speziellen wird das Oracle Sharding erklärt. Zum Schluss erfolgt ein kurzer Überblick über den Oracle Real Application Cluster (RAC).

Der dritte Teil der Arbeit beschäftigt sich zunächst mit dem Aufbau einer Sharding Umgebung. Hierzu werden die durchzuführenden Schritte aufgezeigt und erklärt. An- schließend führt der Autor einen Vergleich von Oracle Sharding mit dem Oracle RAC durch. Dieser Vergleich wird auf der Grundlage von zuvor festgelegten Kriterien durch- geführt. Es folgt ein Vergleich mit den ausgewählten NoSQL-Technologien. Zum Schluss werden die beiden Vergleiche in Form einer Entscheidungsmatrix und einem Fazit vom Autor zusammengefasst. Hier liefert der Autor Vorschläge für Einsatzmöglichkeiten und zeigt die Vorteile des Oracle Shardings auf.

Das letzte Kapitel schließt die Arbeit mit einer ganzheitlichen Schlussbetrachtung ab. Diese enthält eine Zusammenfassung, ein Fazit, eine kritische Betrachtung und einen Ausblick.

2 Grundlagen

2.1 Online Transaction Processing (OLTP)

Die Abkürzung OLTP steht für On-line Transaction Processing. Das bedeutet im Deut- schen soviel wie transaktionsorientierte Datenverarbeitung. Dabei handelt es sich um ein Konzept für relationale Datenbanksysteme. Der Fokus liegt darauf, dass Transaktionen bzw. Operationen auf dem System direkt durchgeführt werden. Diese Transaktionen sind unabhängig von sich kurzfristig ändernden Datenbeständen.¹ Dementsprechend stellt dieses Konzept hohe Anforderungen im Bezug auf Antwortzeiten, Transaktions- sicherheit und Datendurchsatz an das jeweilige Datenbanksystem (DBS). Durch die Transaktionskriterien der OLTP-Anwendung wird Ihre Konsistenz sichergestellt. Die Effizienz hängt also unter anderem von der verwendeten Hardware und der Software (DBS) ab, da diese Komponenten die Antwortzeit beeinflussen. Die Verarbeitungsschrit- te von OLTP-Applikationen sind in der Regel eher kurz und von geringer Komplexität. Somit gibt es eher viele kurze Transaktionen, die möglichst schnell bearbeitet werden. Typische Einsatzgebiete von OLTP-Applikationen sind das operative Tagesgeschäft ei- nes Unternehmens, wie z.B. Elektronische Datenverarbeitung (EDV)-Systeme.²

Deswegen eignet sich Sharding für diese Applikationen ganz besonders. Es unterstützt die Hauptmerkmale des Konzeptes von OLTP-Applikationen. Die Antwortzeiten wer- den verkürzt durch die Aufteilung des Workloads. Der Datendurchsatz wird erhöht, da die Daten verteilt sind und jede Anfrage direkt an die Datenbank mit den relevanten Daten gestellt wird. Ein weiterer Vorteil ist das dezentrale Modell auf dem das Sharding beruht. Dies minimiert die Ausfallzeiten der OLTP-Applikation.³

2.2 Konsistenzkonzepte

Um das Oracle Sharding im Bezug auf Konsistenz mit den Konkurrenz-Technologien zu vergleichen, werden in diesem Kapitel die Grundlagen hierfür geschildert.

2.2.1 CAP-Theorem

Das CAP-Theorem wurde im Jahre 2000 von Eric A. Brewer aufgestellt und im Jahre 2002 von Gilbert und Nancy Lynch bewiesen.

CAP ist eine Abkürzung und steht für die englischen Wörter Consistency (Konsistenz), Availability (Verfügbarkeit) und Partition Tolerance (Partitionstoleranz). Dieses Theo- rem wird benutzt, um die Besonderheiten bei verteilten Datenbanken darzustellen. Es besagt, dass nur zwei der drei Kriterien bei einem verteilten Datenbanksystem vollstän- dig erreichbar sind. In einem perfekten DBS wären alle drei Kriterien erfüllt.

- Konsistenz (Consistency): Das C in dem Theorem steht für Konsistenz zwischen den Knoten bzw. Systemen einer verteilten Anwendung. Jeder Knoten eines Sys- tems hat zu jedem Zeitpunkt die gleichen Daten. Es muss sichergestellt werden, dass nach jeder Transaktion die Daten auf allen Knoten aktualisiert wurden. Somit ist es eine deutlich striktere Konsistenz als bei relationalen Datenbankmanage- mentsystemen. Die Konsistenz bei relationalen Datenbankmanagementsystemen bezieht sich auf die Transaktionskonsistenz.
- Verfügbarkeit (Availability): Verfügbarkeit meint im Sinne des CAP-Theorems, dass die Datenbank alle Anfragen in einer bestimmten Zeit beantwortet. Anfragen werden, trotz Netzwerkausfällen oder Ausfällen von einzelnen Knoten, beantwortet. Dabei ist jedoch keine Konsistenz gewährleistet bzw. es ist nicht gewährleistet, dass die Abfrage die aktuellsten Daten zurückgibt.⁴
- Partitionstoleranz (Partition Tolerance): Partitionstoleranz sagt aus, dass eine verteilte Datenbank den Ausfall einzelner Knoten im System verkraftet. Wenn die Kommunikation zu einem Teil nicht mehr möglich ist, muss das System trotz des Ausfalls funktionstüchtig bleiben. Ein Beispiel ist eine verteilte Datenbank mit zwei Servern. Wenn einer der beiden Server ausfällt, steht der andere Server weiterhin für Schreib- und Leseoperationen zur Verfügung.⁵

Durch die Einschränkung, dass nur zwei der drei Kriterien erfüllt werden können, müssen die Datenbanken Kompromisse eingehen. Im Folgenden beschreibt der Autor die drei Kompromisse.

Der erste Kompromiss ist, dass das System konsistent und verfügbar ist. Dieses System versucht Konsistenz und Hochverfügbarkeit gleichermaßen herzustellen. Dabei wird die Partitionstoleranz in den Hintergrund gestellt. Bei ihnen hat Konsistenz und Verfüg- barkeit die höchste Priorität.

Das zweite Szenario vereint Konsistenz mit Partitionstoleranz. Diese Datenbanken ver- nachlässigen den Aspekt der Verfügbarkeit. Datenbanken mit diesem Kompromiss sind nicht vollständig verfügbar. Ein Teil des Systems ist für eine bestimmte Zeit nicht verfüg- bar, wenn das System die Konsistenz für diesen Teil nicht garantiert. Sollte der Knoten wieder verfügbar sein, wird zuerst die Konsistenz sichergestellt. Erst danach ist die Datenbank wieder verfügbar für Abfragen. Ein solches Szenario ist sinnvoll für Anwen- dungsfälle, wie z.B einem Bankinstitut, welches viele Bankautomaten an verschiedenen Standorten hat. Diese Bankautomaten müssen jederzeit konsistent sein. Eine Verzöge- rung in der Antwortzeit hingegen ist akzeptabel.

Das letzte Szenario ist die Kombination von Verfügbarkeit und Partitionstoleranz. Das bedeutet, diese Systeme verzichten auf völlige Konsistenz der Daten. In diesem Feld siedeln sich die meisten NoSQL-Datenbanken an. Sie arbeiten mit dem Eventual Con- sistency Prinzip. Das heißt, sie reagieren auf Anfragen, aber ihre Ergebnisse müssen nicht zwingend konsistent sein. Dabei heißt Eventual Conisistency, dass sie irgendwann konsistent sind, es aber zu dem gegebenen Zeitpunkt nicht sein müssen. Ein Beispiel ist der Domain Name System Service. Dieser arbeitet mit dem AP-Prinzip. Internet Protocol (IP)-Adressen müssen zu jederzeit aufgelöst werden können, trotzdem kann es länger dauern bis ein geänderter Eintrag auf allen Systemen angekommen ist.⁶

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Quelle: Big Data: Grundlagen, Systeme und Nutzungspotenziale (Daniel Faser, Andreas Meier), 5. 34

Alles in allem lassen sich die Datenbanken den folgenden Kategorien zuordnen, vorausgesetzt die relationalen Datenbanken werden zum CAP-Theorem dazu gezahlt.

- CA: (Traditional relational databases PostgreSQL, Oracle, MySQL)
- AP: Cassandra, CouchDB
- CP: MongoDB, HBase

⁷

2.2.2 BASE

Die Abkiirzung BASE steht fiir Basically Available, Soft State, Eventually Consistent. Dabei steht Basically Available dafiir, class das System Verfiigbarkeit der Daten garan­ tiert. Ob die Daten inkonsistent oder im ,changing state" sind, also sich geandert haben, spielt keine Rolle. Mit Soft State ist gemeint, class sich der Zustand des Systems mit der Zeit verandert. Der Datenbestand kann sich sogar ohne direkten Input verandern, da das System nur ,eventual consistent" ist. Das System ist irgendwann konsistent, vorausgesetzt es bekommt keinen Input mehr. Wenn keine Updates mehr durchgeführt werden, ist es möglich, dass alle Read-Abfragen den gleichen Wert liefern.

Der BASE Ansatz ist das Gegenstück zum ACID(2.2.3) Ansatz. Es wurde entwickelt, um verteilte Systeme zu unterstützen und ihnen mehr Freiraum zu lassen. Der Kernge- danke ist, dass die Daten verändert, gelöscht oder konsistent sein können. Dies soll nicht in Konkurrenz stehen zur Verfügbarkeit, da diese beim BASE-Ansatz im Vordergrund steht. Deshalb wird bei diesem Ansatz auch von einer „Weak consistency“ gesprochen, also einer schwachen Konsistenz.⁸

2.2.3 ACID

ACID ist ein Modell für die Eigenschaften von Transaktionen. Es beschreibt die Ei- genschaften von relationalen Datenbanksystemen. Die Abkürzung ACID steht für die folgenden Begriffe:

- atomicity: Atomarität steht für das Alles oder Nichts Prinzip. Also sind entweder alle Elemente einer Transaktion erfolgreich und somit auch die ganze Transaktion oder gar keins.
- consistency: Diese Eigenschaft heißt, dass die Datenbank vor und nach dem Aus- führen einer Transaktion in einem konsistenten Zustand ist.
- isolation: Alle Transaktionen sind unabhängig voneinander und haben keine Ver- bindung zu anderen unvollständigen Transaktionen.
- durability: Sobald eine Transaktion vollendet wurde, muss sie festgeschrieben sein. Das heißt sie ist dauerhaft auf dem System gespeichert. Diese Speicherung muss Systemfehler und Diskfehler überstehen.

Dabei verfolgen einige relationale Datenbanken das multi-version concurrency control (MVCC) Modell. Das heißt während einer Transaktion sehen andere Benutzer die Verän- derungen der Transaktion nicht. Es werden „alte“ Daten gezeigt, die ebenfalls für einen rollback benutzt werden, falls eine Transaktion fehlschlägt. ⁹

2.3 NoSQL

Der Begriff NoSQL wurde zum ersten Mal im Jahre 1998 verwendet. NoSQL ist keine Technologie, die von einer Gruppe von Personen erfunden wurde, sondern ein Konzept, welches sich über mehrere Jahre entwickelt hat. Besonders im heutigen Zeitalter des World Wide Web steigt die Anzahl der Informationen und Geräte im Netz massiv an. Diese Masse an Daten muss gespeichert, verarbeitet und letztendlich interpretiert werden. Dabei haben besonders zwei große Firmen die Entwicklung von NoSQL voran gebracht. Zum Einen war das die Firma Google, welche im Jahre 2006 ein Paper über Bigtable distributed structured database herausgebracht hat. Zum Anderen die Firma Amazon, welche 2007 ein Paper zu Dynamo data storage application veröffentlichte. Heutzutage wird unter dem Begriff eine Vielzahl von NoSQL Datenbank Produkten verstanden.¹⁰

Eine NoSQL Datenbank muss folgende Anforderungen erfüllen:

- Die Datenbank benötigt kein Schema
- Ist auf eine verteilte Architektur ausgelegt
- Benutzt kein relationales Datenbankdesign

Die erste Anforderung ist, dass die Datenbank kein Schema benötigt bzw. nur geringe Restriktionen hat. Anders als bei relationalen Datenbanken, bei denen das Datenbank- schema eine große Rolle spielt. Die Daten werden unstrukturiert abgelegt, wodurch die Notwendigkeit von Umstrukturierungen entfällt.

Die zweite Anforderung ist, dass sie auf eine verteilte Architektur ausgelegt ist. Das bedeutet, die Daten werden über mehrere Server verteilt, um eine große Menge von Daten zu verarbeiten und zu speichern. Das Skalieren der NoSQL Datenbank erfolgt durch Hinzufügen neuer Hardware.

Die dritte Anforderung ist, dass sie kein relationales Datenbankdesign hat. Es gibt keine Verknüpfung von Daten, wie z.B Fremdschlüssel oder referentielle Integritäten.¹¹

NoSQL Datenbanken sind nicht beschränkt auf den klassischen Spalten und Zeilen Ansatz von relationalen Datenbanken. Sie sind designt, um eine große Vielfalt von Daten zu verarbeiten. Diese Daten verändern Ihre Struktur mit der Zeit und Ihre Wechselbeziehungen sind nicht bekannt. Dafür gibt es vier Haupttypen von NoSQL- Datenbanken:

- Spaltenorientiert
- Key-Value
- Triple
- Dokumentorientiert

Bei spaltenorientierten Datenbanken handelt es sich um eine Erweiterung des traditio- nellen Tabellenschemas. Dabei werden Daten in spaltenweisen Tupeln¹² abgelegt. Sie sind optimiert für Spaltenabfragen, welche viele Tupel aber wenige Spalten abfragen. Das Key-Value Store Prinzip ist eine eher simple Struktur, bei der der Datensatz ein Schlüssel (Key) und ein Wert (Value) gleichzeitig ist. Das heißt die Schlüssel sind bei diesem Ansatz eindeutig und vergleichbar mit einem Primary Key von relationalen Datenbanken.

Das Triple beschreibt eine Information, die durch drei Elemente beschrieben wird. Das erste Element ist das beschriebene „Thema“. Das zweite die Beschreibung der Eigen- schaft oder der Beziehung zu einem anderen Objekt. Das dritte Element ist der Wert. Dieser Wert ist entweder ein richtiger Wert z.B eine Zahl oder eine Unique ID eines anderen Objektes.

Die dokumentorientierten Datenbanken speichern Daten in Dokumenten ab. Ein Do- kument speichert die Daten in strukturierter Form ab, in dem es Schlüsselfelder gibt, denen ein konkreter Wert zugeordnet ist.¹³

2.3.1 Cassandra

Cassandra ist ein Open Source Distributed Datenbank System. Es wurde im Jahre 2007 bei Facebook durch Avinash Lakshman und Prashant Malik entwickelt. Cassandra ist eine spaltenorientierte Datenbank. Das heißt die Daten werden in Columns¹⁴ abge- speichert. Zu den Bestandteilen der Cassandra Datenbank gehören Keyspaces, Keys, Columns, Column Familys und Super Columns. Der Keyspace ist der oberste Bereich. Er ist vergleichbar mit einem Schema von Oracle und fasst mehrere Column Familiys zusammen. Eine Column Family wiederrum ist vergleichbar mit einer Tabelle und fasst mehrere Super Columns und Columns zusammen.¹⁵ Die Super Column ist eine Zusam- menfassung von mehreren Columns zu einer. Durch diese Zusammenfassung wird auf die Columns einer Super Column deutlich effizienter zugegriffen. Das heißt Leseope- rationen sind schneller, da bestimmte Spalten bereits logisch „verknüpft“ sind. Dies ist deutlich effizienter als bei relationalen Datenbanken, da Verknüpfungen dort durch Join-Abfragen realisiert werden.¹⁶

Der Key ist, wie in der relationalen Datenbank, zur eindeutigen Identifikation jedes Datensatzes und zur Partitionierung der Daten da. Cassandras Architektur ist eine Ringstruktur. Das heißt, alle Knoten in einem Cassandra Cluster kommunizieren un- tereinander mittels Peer-to-Peer Protokoll. Dabei nimmt jeder Node die gleiche Rolle ein, denn es gibt keinen Master-Node oder Koordinator.¹⁷ Jeder Node im Cluster ist in der Lage dazu die Rolle des Koordinators zu übernehmen, eine Anfrage entgegen zu nehmen und diese an den richtigen Node weiterzuleiten.¹⁸

2.3.2 MongoDB

MongoDB ist eine Open Source Datenbank. Es ist eine dokumentbasierte Datenbank. Das heißt, jeder Datensatz wird als Dokument abgelegt. Ein Dokument besteht dabei aus einem Feld und einem Wert. Diese Dokumente werden in JSON ähnlichen Objekten gespeichert, welche sich BSON¹⁹ nennen. Die Struktur der Objekte ist angelehnt an Objekte aus der Programmierung, um diese Entwicklern leichter verständlich zu ma- chen.²⁰ Die Gruppierung unter MongoDB erfolgt durch Collections. Diese Collections sind vergleichbar mit den Tabellen einer relationalen Datenbank, jedoch haben sie kein festes Schema. Die Felder der Dokumente können also unterschiedlich sein. Zusätzlich gibt es noch Capped Collections, welche eine feste Größe haben. Sobald diese Größe erreicht wird, wird der älteste Eintrag der Collection gelöscht. Zuletzt gibt es noch die System Collections. In diesen Collections speichert MongoDB die Systeminformationen und lokale Metadaten ab.²¹

2.4 Oracle DB Grundlagen

In diesem Teil werden der Global Data Service und Connection Pools erläutert, da Sie besondere Relevanz für das Oracle Sharding haben.

2.4.1 Oracle Global Data Services

Der Oracle Global Data Service wurde mit der Version 12c eingeführt. Dabei handelt es sich um eine komplette Lösung zum Verwalten von Workload bei replizierten Datenban- ken. Es wird in Verbindung mit Oracle Golden Gate, Oracle Active Data Guard, Oracle Sharding und anderen Hochverfügbarkeitslösungen eingesetzt. Durch die Features auto- matisierte Workload Verwaltung und verschiedene Service Failover Möglichkeiten wird die Performance, Verfügbarkeit und Verwaltung der replizierten Datenbanken erhöht. ²² Des Weiteren optimiert es die Ressourcennutzung, was besonders im Hinblick auf das Oracle Sharding die Performance erheblich steigert. Mit dem Global Data Service (GDS) hat Oracle das Konzept des Global Services eingeführt. Der Global Service ver- waltet mehrere Datenbanken global und managt die Verbindungen. Diese Datenbanken gehören zu einer bestimmten „Domain“, welche als GDS Pool bezeichnet wird. Der Global Service erweitert dabei die Datenbank Services um Attribute, wie Global Ser- vice Placement und Replication Lag. Diese dienen dem GDS dazu den Workload nach bestimmten Kriterien zu verteilen. Somit entfällt die Notwendigkeit für jeden Workload eine logische Abstraktion in Form eines Datenbank Services zu haben. Clients verbinden sich also nicht mehr über den Service Name, sondern über den Global Service. Dabei wird die Verbindung durch den GDS an eine Datenbank weitergeleitet, welche aktuell wenig Workload hat. Dabei ist der Global Service nicht an eine logisch verknüpfte Daten- bank gebunden, sondern ist in der Lage die Verbindung zu verschiedenen Datenbanken herzustellen.

Der GDS steht also logisch gesehen zwischen der Anwendungsebene und der Datenban- kebene. Er kontrolliert und managt den Zugriff auf die Datenbanken. Dabei lassen sich über die Attribute des GDS der Instance Load und die Netzwerklatenz zwischen den Datenzentren, sowie bestimmte Workload-Management-Richtlinien (Regionen, Load Ba- lancing Ziele, DB-Kardinalität, DB-Rolle, Replikationsauszeit) durch den Administrator konfigurieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbllduna 2: QueUe:Oracle White Paper Global Data Services, S. 5

Der GDS ist inbegriffen ffir a.lle Datenbanken, die eine Active-Data Guard oder Golden Gate Lizenzierung besitzen. Des Weiteren mfu!sen die Datenbanken und der Datenbank Katalog mindestens Version 12.1Wld eine Enterprise Edition (EE) sein.²³

2.4.2 Connection Pools

Ein Connection Pool ist ein Cache fiir Verbindungsobjekte. Die Objekte in diesem Cache repr8Bentieren physika.lische Datenbanlcverbindungen. Die Applika.tion stellt eine Verbindungsanfrage an den Pool. Dieser wihlt eine passende Verbindung aus und gibt diese zurftck. Wenn dies nicht moglich ist, wird die Anfrage an den Shard Director weitergeleitet, welcher eine neue Verbindung erstellt. Nachdem die Applikation. fertig ist, wird die Verbindung wieder an den Connection Pool zurftckgegeben und ist bereit fiir die niicbste An.&age.

Somit erm6glichen Connection Pools die Wiederverwendung von Verbindungen. Zudem wird die Wartezeit bei einer Verbindungsanfrage der Applikation reduziert.

Um die Performance beim Oracle Sharding zu erhOhen, wird daB Connection Pooling in der Sharding Umgebung verwendet.²⁴

2.5 Sharding

In diesem Teil wird zunächst erklärt, was Sharding ist und wo es eingesetzt wird. Dann wird der Begriff Skalierbarkeit definiert, da dieser eine zentrale Rolle im Bezug auf das Sharding spielt. Anschließend wird die Architektur der Sharding Lösung von Oracle erläutert und es gibt eine Übersicht über die benötigten Lizenzen.

2.5.1 Definition Sharding

Sharding ist eine Methode der Datenbankpartitionierung. Dabei werden die Daten ho- rizontal partitioniert auf mehrere Server. Das bedeutet jeder Server hat seinen eigenen Teil der Daten.²⁵ Die Partition wird Shard genannt. Ein Shard ist also eine unabhängige Datenbank, welche auf einem Datenbank Server gehostet ist. Die Datenbank hat dement- sprechend ihre eigenen Ressourcen (CPU, Speicher, etc.). Sie ist Teil eines Verbunds bzw. einer Sammlung von mehreren Datenbanken, die zusammen eine logische Daten- bank darstellen. Durch das Aufteilen der Daten auf verschiedene Server wird die Last reduziert. Zudem wird der Single-Point-of-Failure (der einzelne Server mit allen Daten) eliminiert. Dabei ist das Schema der Shards immer das Gleiche, nur der Datenbestand ist unterschiedlich. Jedoch gibt es ebenfalls Szenarien, bei denen redundante Daten auf den Shards vorhanden sind. Das ist der Fall, wenn es bestimmte Daten/Datensätze gibt, die oft benötigt werden. Für diese Daten/Datensätze ist es sinnvoll sie redundant zu halten. Eine Abfrage eines weiteren Shards ist deutlich „kostenintensiver“, als minimal mehr Speicherplatzverbrauch.²⁶ Die Vorteile des Shardings sind:

- Hochverfügbarkeit: Das Eliminieren des Single-Point-of-Failure (SPOF) ermöglicht es Anfragen an alle Shards zu stellen, unabhängig davon ob ein anderer Shard ausgefallen ist
- Verkürzung der Antwortzeiten: Durch das Aufteilen der Last auf mehrere Maschi- nen und das Aufteilen der Daten wird die Antwortzeit deutlich herabgesetzt
- Erhöhte Write-Leistung: Das Aufteilen ermöglicht es Änderungen parallel auf jedem einzelnen Shard durchzuführen
- Erhöhung der möglichen Transaktionen: Durch das Aufteilen der Last können mehr Useraktionen an der Applikation durchgeführt werden bzw. es können mehr User an der Applikation arbeiten.

²⁷

Wie in der folgenden Grafik (Abb. 3) zu sehen, wird die Datenbank „User“ einschließlich der Tabelle „User Table“ auf zwei unabhängige Datenbanken aufgeteilt. Diese heißen ebenfalls User und beinhalten die gleiche Tabelle „User Table“ mit der dazugehörigen Tabellenstruktur. Jedoch sind die vier Datensätze der Tabelle aufgeteilt, sodass die ersten beiden Datensätze in der ersten Datenbank und die letzten beiden in der zweiten sind. Die erste Datenbank befindet sich auf dem „Server 1“ und die zweite Datenbank auf dem „Server 2“. Die beiden Datenbanken sind somit komplett unabhängig voneinander und befinden sich nicht mehr auf einem gemeinsamen Server.

Abbildung in dieser Leseprobe nicht enthalten

Abblldun 1 3:Quelle:Eigene Zusammenstellunt

2.5.2 Definition Skalierbarkeit

Sk.alierbarkeit beschreibt die Fiihiglreit eines Systems sich qU&Dtitativ steigenden ADforderungen anzupasseD.. Meist bezieht sich dies auf die Fihigkeit des Systems zu wa.cbsen.²⁸ Im Zusammenhang mit Datenbanksystemen gibt ea zwei Anfordenmgen., die steigeo. kOnnen. Das ist die Anzahl der Zugriffe und wie viele Daten geachrieben bzw. geapeichert werden.

Es gibt zwei Arten bzw. Mog lichkejten mit denen SkaJierba.rkeit erreicht wird.

Die erste Moglicbkeit ist die vertJkale Skalierung, auch scale up geo.amat. Dies beschreibt das Aufriisten eines vorhandenen Servers durcb bessere Hardwarekomponenten, wie z.B. bessere CPU oder Hauptspeicher. Da.bei ist daa Ziel dieaer Verbesserung, entweder eine Verbesserung der Schnelligkeit der Komponenten, eine größere Kapazität oder eine er- höhte Ausfallsicherheit. Der Vorteil dabei ist, dass es keine Anpassungen an der Software geben muss.²⁹ Jedoch ist diese Variante der Verbesserung nicht unbegrenzt möglich, da die Kosten für bessere Komponenten exponentiell steigen und der Verbesserungsspiel- raum immer weiter sinkt. Ein weiterer negativer Punkt ist, dass das Ausfallrisiko bei wenigen oder einem Server steigt. Außerdem benötigt die Aufrüstung der Hardware Zeit, in der der Server nicht für den normalen Betrieb zur Verfügung steht.

Die zweite Möglichkeit ist das horizontale Skalieren, auch scale-out genannt. Dabei wird die Anzahl der Server erhöht. Es können beliebig viele Server miteinander vernetzt werden. Der einzelne Server ist nicht ausfallsicherer oder leistungsfähiger als die anderen Server im bereits vorhandenen Verbund. Er kann trotzdem das Gesamtsystem erwei- tern. Dies ist ein Vorteil gegenüber dem vertikalen Skalieren, der Ausfall eines Servers oder einer Verbindung zwischen zwei Servern ist für das Gesamtsystem nicht relevant. Dadurch wird die Ausfalltoleranz und die Verfügbarkeit enorm gesteigert. Jedoch ist es für die horizontale Skalierung nötig den Programmcode anzupassen, da sich nicht jede Software parallelisieren lässt.³⁰

Datenbanksysteme, die horizontal skalieren, werden verteilte Datenbanksysteme genannt. Deswegen wird beim Oracle Sharding von einem verteilten Datenbanksystem gesprochen, welches die Daten durch horizontale Partitionierung skaliert.³¹

2.5.3 Architektur Oracle Sharding

Oracle Sharding ist ein Feature von Oracle, welches Hochverfügbarkeit und Skalierbar- keit für OLTP-Applikationen verspricht. Es ermöglicht die Verteilung und Replikation von Daten über mehrere Oracle Datenbanken, die keine Hardware oder Software teilen. Der Pool aus Datenbanken erscheint für die Applikation als eine logische Datenbank. Applikationen können auf jeder Ebene skaliert werden, sei es Daten, Transaktionen oder Benutzer. Dazu werden neue Datenbanken bzw. Shards zur Sharded Database hinzugefügt. Im ersten Release mit der Datenbankversion 12.2.0.1 können bis zu 1000 Shards verbunden werden.

Das Oracle Sharding bietet gegenüber Eigenentwicklungen eine deutlich bessere Laufzeit- Performance und leichtere Administration an. Zudem können die Vorteile der Enterprise Datenbank genutzt werden, denn Oracle Sharding unterstützt relationale Schemas, Struc- tured Query Language (SQL), komplexe Datentypen, ACID-Eigenschaften und viele mehr.³²

Der Verbund von mehreren Shards nennt sich Sharded Database. Ein Shard kann in verschiedenen Regionen oder Rechenzentren platziert werden. Eine Region ist im Oracle Sharding Kontext ein Rechenzentrum oder mehrere Rechenzentren, welche nah beiein- ander liegen. Dadurch wird die Performance von Abfragen erhöht, indem bestimmte Shards die Daten für eine bestimmte Region enthalten. Für eine Sharding Architektur wird kein gemeinsamer Speicher benötigt, wie z.B. in einer RAC-Umgebung.

Wie in der folgenden Grafik (Abb. 4) zu sehen, gehören zu der Sharding Architektur die folgenden Schlüsselkomponenten: Shards, Shard Director(GSM), Shard Catalog, Global Service und Connection Pools.

Shards wurden bereits im Kapitel Definition Sharding (Abschnitt 2.5.1) beschrieben. Um Hochverfügbarkeit und Disaster Recovery zu erreichen werden die Shards über Replikationsmethoden repliziert, wie z.B Active Data Guard. Für Hochverfügbarkeit wird der Standby Shard in der selben Region platziert. Für Disaster Recovery wird der Standby Shard in einer anderen Region platziert.

Der Shard Catalog ist eine spezielle Datenbank für die Sharding Architektur. Sie spielt eine Schlüsselrolle in der gesamten Architektur. Der Shard Catalog speichert die Konfi- gurationsdaten der Sharded Database und ist unter anderem zuständig für das automa- tisierte Deployment und das zentrale Management der Sharded Database.

Alle Änderungen an der Konfiguration, wie zum Beispiel das Hinzufügen oder Entfernen von Shards und Global Services, werden mit Hilfe des Shard Catalogs durchgeführt. Alle Data Definition Language (DDL) Kommandos in einer Sharded Architektur werden durch Verbinden mit dem Shard Catalog durchgeführt. Der Ausfall des Shard Cata- logs beeinflusst die Verfügbarkeit der Sharded Database nicht. Lediglich administrative Aufgaben und Queries über mehrere Shards werden in Ihrer Performance negativ be- einflusst. Die Transaktionen der OLTP Applikation werden ebenfalls nicht beeinflusst. Diese werden von der Sharded Database ausgeführt und geroutet. Um diese Ausfälle abzufangen, empfiehlt Oracle einen Active Data Guard zu konfigurieren.

Der Shard Director übernimmt die Rolle der Koordination der verschiedenen Shards. Er koordiniert die Anfragen der Clients mit Hilfe des Global Service Managers zum richtigen Shard. Dabei stellt der Shard Director einen regionalen Netzwerk Listener dar. Dieser leitet die Verbindungen der Clients, unter Verwendung des jeweiligen Sharding Keys, der im Connection Request übergeben wird, an den richtigen Shard weiter.

[...]

---

¹ vgl. Roland Gabriel, Peter Gluchowski, Alexander Pstwa, 2009, S.11

² vgl. solid IT GmbH, 2018b

³ vgl. solid IT GmbH, 2018b

⁴ vgl. TH Köln, 2015-01-23

⁵ vgl. solid IT GmbH, 2018a

⁶ vgl. solid IT GmbH, 2018a

⁷ vgl. Lior Messinger, 2013-02-17

⁸ vgl. Drazena Gaspar, 2017, S.16 ff.

⁹ vgl. Guy Harrison, 2015, S.128

¹⁰ vgl. Adam Fowler, 2015, S.8 ff.

¹¹ vgl. Adam Fowler, 2015, S.19 ff.

¹² Sammlung von Werten, die auch als Datensatz bezeichnet wird.

¹³ vgl. Adam Fowler, 2015, S.28 ff.

¹⁴ Spalten

¹⁵ vgl. Guy Harrison, 2010-08-23

¹⁶ vgl. Rudolf Jansen, 2011-06-29

¹⁷ vgl. DataStax, 2018

¹⁸ vgl. Abu Fazal Abbas, 2016-09-10

¹⁹ „MongoDB represents JSON documents in binary-encoded format called BSON behind the scenes“ MongoDB, o.D.

²⁰ vgl. MongoDB, 2018d

²¹ vgl. MongoDB, 2018g

²² vgl. Oracle, 2018b

²³ vgl. Oracle, 2013

²⁴ vg1. Oracle Help Center, 2018

²⁵ vgl. solid IT GmbH, 2018c

²⁶ vgl. Rahul Roy, 2008

²⁷ vgl. Rahul Roy, 2008

²⁸ vgl. TH KUln, 2012-07-23

²⁹ vgl. solid IT GmbH, 2018d

³⁰ vgl. TH Köln, 2012-07-23

³¹ vgl. solid IT GmbH, 2018d

³² vgl. Oracle, 2018d