Vergleich relationaler und nicht relationaler Datenbanken

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Relationale Datenbanken
2.1 Geschichtliches
2.2 Grundlagen
2.3 ACID-Konsistenzmodell
2.3.1 Atomicity
2.3.2 Isolation
2.3.3 Consitency
2.3.4 Durability

3 Nicht relationale Datenbanken
3.1 Geschichtliches
3.2 Warum NoSQL? - Ein Vergleich
3.3 CAP-Theorem
3.3.1 Consistency
3.3.2 Availability
3.3.3 Partition Tolerance
3.4 BASE-Modell

4 Zusammenfassung

5 Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1 Beispiel Banküberweisung 3

Abbildung 2 CAP-Eigenschaften 8

1 Einleitung

Diese wissenschaftliche Arbeit soll einen grundlegenden Überblick über die Themen relationale Datenbanken und nicht relationale Datenbanken geben. Durch die enorm wachsenden Datenmengen, extrem vielen Zugriffen auf diese Daten und der Notwendigkeit zur horizontalen Skalierung, treten neue Datenbankmodelle und -konzepte auf dem Markt auf. Der Fokus dieser Seminararbeit liegt daher auf den Charakteristika dieser beiden Datenbankmodelle und den sich ändernden Anforderungen, hervorgerufen durch das Aufkommen des Webs 2.0 an eine Datenbank.

Der Aufbau dieser Seminararbeit ist so strukturiert, dass anfänglich kurz auf die Geschichte und ein paar Grundlagen der relationalen Datenbanken eingegangen wird. Danach folgt eine detaillierte Beschreibung des ACID-Konsistenzmodells (Atomicity, Consistency, Isolation, Durability) und dessen Eigenschaften, die mit Beispielen verdeutlicht werden.

Im zweiten Teil der Seminararbeit wird detailliert auf das Thema „nicht relationale Datenbanken“ eingegangen. Zunächst erfolgt ein kurzer Überblick über die Entstehungsgeschichte der nicht relationalen Datenbanken. Danach wird näher auf die Schwachstellen von relationalen Datenbanken eingegangen und auf diesem Weg ein Vergleich zu NoSQL geschaffen. Anschließend werden Erkenntnisse aus dem CAP-Theorem bei verteilten Datenbanken vorgestellt. Im Folgenden wird das Konsistenzmodell BASE, dass von NoSQL-Datenbanken vorzugsweise eingesetzt wird, erläutert.

2 Relationale Datenbanken

2.1 Geschichtliches

Die Grundidee der Entwickler des relationalen Datenbankmodells war es, Daten in Form von Relationen abzuspeichern. Eine Studie über relationale Datenbankanken wurde erstmals 1970 von dem IBM Forscher Edgar F. Codd vorgestellt. Daraufhin wurde der erste Prototyp eines relationalen Datenbankmanagementsystems (RDBMS) mit dem Namen „System R“ entwickelt, dessen Abfragesprache anfänglich noch mit dem Namen SEQUEL (Structured English Query Language) betitelt wurde. Nach einer Weiterentwicklung wurde das System in DB2 (DataBase2) umbenannt und aus SEQUEL ging die SQL-Abfragesprache hervor.

Andere Firmen wie „Oracle“ nutzten die gewonnenen Erkenntnisse aus der Studie für ihre eigenen Datenbankmanagementsysteme. So lösten die relationalen Datenbanken kurz daraufhin im Jahre 1980 die bisherigen hierarchischen und netzwerkorientierten Systeme ab (vgl. Hochschule Offenburg).

2.2 Grundlagen

Relationale Datenbanken sind weit verbreitet, da sie in Form von SQL eine mächtige Abfragesprache und einen großen Funktionsumfang bieten. Außerdem garantieren sie die Erwartungen an eine Datenbank zu erfüllen.

Diese Erwartungen werden grob wie folgt untergliedert:

- Daten sollen dauerhaft und konsistent abgespeichert werden.
- Mehrere Benutzer sollen gleichzeitig in der Lage sein, schreibend und lesend auf die Daten zuzugreifen.

Um diese Erwartungen zu erfüllen wurde das ACID-Konsistenzmodell entwickelt (vgl. Schicker, 2014, p. 6).

2.3 ACID-Konsistenzmodell

Das Akronym ACID dient der Charakterisierung von Transaktionen in relationalen Datenbanken und beschreibt erwünschte Eigenschaften von Verarbeitungsschritten in relationalen Datenbankmanagementsystemen. Im Folgenden wird auf die Bestandteile des ACID-Konstrukts, das vor allem von relationalen Datenbanken verwendet wird, näher eingegangen.

2.3.1 Atomicity

Der englische Begriff „Atomicity“ bedeutet Atomarität und Abgeschlossenheit.

Durch den Einsatz von Transaktionen wird eine Operation entweder ganz oder gar nicht ausgeführt („Alles oder Nichts-Semantik“). Die Anweisungen werden einzeln ausgeführt, aber global erst dann für gültig erklärt, wenn sie erfolgreich und vollständig abgeschlossen sind. Dies bezieht sich vor allem auf die im Rahmen der Transaktion auszuführenden Änderungen in einer Datenbank (vgl. Dr. Härder & Dr. Rahm, 2001, p. 393).

Im folgenden Beispiel wird anhand einer klassischen Banküberweisung eine Transaktion beschrieben. Diese Transaktion wird in Abbildung 1 (s. Seite 3) verdeutlicht.

Im ersten Schritt wird vom eigenen Konto mit der Kontonummer 1000 der zu überweisende Betrag über 50,00 € abgebucht. Im zweiten Schritt muss dieser Betrag auf das Konto des Empfängers mit der Kontonummer 1001 gutgeschrieben werden. Der letzte Schritt besteht aus der Protokollierung des gesamten Vorgangs, der ahnand der drei Anweisungen „Begin Transaction“, „Commit“ und „Rollback“ eingeleitet werden kann:

- „Begin Transaction“

SQL-Anweisungen wie „Insert“, „Update“ und „Delete“ werden von nun an protokolliert.

- „Commit“

Die Transaktion wird abgeschlossen, indem alle Änderungen verbucht und für den Benutzer sichtbar werden.

- „Rollback“

Alle Änderungen werden wieder verworfen. (vgl. Steiner, 2014, p. 206-207)

Wenn nach der erfolgreichen Abbuchung des Betrags vom Konto ein Übermittlungsfehler entsteht, würde der Betrag abgebucht werden, jedoch bekäme der Empfänger keine Gutschrift, wodurch Geld verloren ginge. Somit wäre die „Alles oder Nichts- Semantik“ der Atomicity bzw. Atomarität verletzt. Daher muss sichergestellt werden, dass alle bisher durchgeführten Operationen wieder rückgängig gemacht werden. Dieser Vorgang ist auch bekannt als „Rollback“. Der „Rollback-Vorgang“ ist nur mit Hilfe eines zurvor angelegten Logfiles, in dem alle durchgeführten Transkationen protokolliert werden, durchführbar (vgl. Brücher, et al., 2011, p. 225).

Abbildung in dieser leseprobe nicht enthalten

Abbildung 1: Beispiel Banküberweisung (Quelle: eigene Darstellung)

2.3.2 Isolation

Der Fachbegriff „Isolation“ bedeutete im Deutschen Isolation bzw. Abgrenzung.

Transaktionen laufen vollkommen getrennt voneinander ab und beeinflussen sich somit nicht gegenseitig. Beansprucht eine Transaktion einen bestimmten Datensatz in einer Datenbank, so ist dieser Datensatz für den Zeitraum der Bearbeitung gesperrt. Das bedeutet gleichzeitig, dass eine andere Transaktion, die den selben Datensatz bearbeiten möchte warten muss, bis dieser entsperrt wurde. Diese Art der Isolation fällt unter die Kategorie des pessimistischen Synchronisationsverfahrens, da bereits vor der Ausübung einer Transaktion davon ausgegangen wird, dass es zu einem Konflikt parallel ablaufender Transkationen kommt. Das Ergebnis ist erst nach Beendigung der Transaktion für alle anderen sichtbar (vgl. Dr. Härder & Dr. Rahm, 2001, p. 394).

2.3.3 Consitency

Bei Consistency (dt. Konsistenz) soll gewährleistet werden, dass eine schon bereits vorher konsistente Datenbank nach Beendigung einer Sequenz von Datenoperationen in eine konsistente Datenbank überführt wird (vgl. Dr. Härder & Dr. Rahm, 2001, p. 393). Erreicht wird dies beispielsweise zum einem durch den Einsatz der Normalisierung, die Redundanzen verhindern soll und zum anderen durch bestimmte Integritätsbedingungen. Letzteres beinhaltet die referentielle Integrität, die verschiedene Regeln aufstellt (vgl. Steiner, 2014, p. 15). Neue Datensätze, die einen Fremdschlüssel besitzen, können nur dann gespeichert werden, wenn in der referenzierten Tabelle ein Primärschlüssel mit entsprechendem Wert existiert. Des Weiteren ist die Löschung eines Datensatzes, die einen Primärschlüssel beinhaltet, nur dann möglich, wenn keine anderen Datensätze existieren, die auf diesen verweisen. Es gibt jedoch SQL-Statements wie beispielsweise „ON DELETE CASCADE“, die neben der Löschung eines Primärdatensatzes auch sicherstellen, dass alle Datensätze aus der Kind-Tabelle gelöscht werden, die auf diesen verweisen (vgl. Dr. Klug, 2012, p. 331).

2.3.4 Durability

Der Fachbegriff „Durability“ kommt aus dem englischen und bedeutet Dauerhaftigkeit. Erfolgreiche Änderungen, verursacht durch eine Transaktion, werden dauerhaft in einer Datenbank gespeichert und sind auch nach einem Systemabsturz, verursacht beispielsweise durch einen Hardware-Ausfall, verfügbar. Durability bzw. Dauerhaftigkeit kann durch den Einsatz von Transaktionslogs, die im Falle eines Systemabsturzes zum Tragen kommen, um fehlende Schreiboperationen zu reproduzieren, garantiert werden.

Gerade bei In-Memory-Datenbanken, in denen alle Daten im Hauptspeicher vorliegen, ist der Einsatz von Transaktionslogs unabdingbar (vgl. Dr. Härder & Dr. Rahm, 2001, p. 394).

3 Nicht relationale Datenbanken

3.1 Geschichtliches

Der Begriff „nicht relationale Datenbanken“ (NoSQL) wurde erstmals durch den IBMEntwickler Calo Strizzi im Jahre 1998 bekannt. Dieser entwickelte zwar eine relationale Open-Source-Datenbank, jedoch ohne die SQL-Abfragesprache zu nutzen. Aus diesem Grund wurde damals der Begriff NoSQL im Sinne von „kein SQL“ genutzt. Im Jahr 2009 wurde die Bedeutung des Begriffs NoSQL jedoch bei einem Treffen über verteilte strukturierte Datenspeicher von Johan Oskarsson neu in „Not only SQL“ (NoSQL) definiert. Der Begriff NoSQL bezeichnet von diesem Zeitpunkt an Datenbanken, die einem nicht relationalen Ansatz folgen. NoSQL stellt somit die traditionellen relationalen Datenbankmodelle, die als Lösung für alle Probleme gesehen werden, in Frage (Technische Hochschule Köln, NoSQL).

3.2 Warum NoSQL? - Ein Vergleich

Mit dem Aufkommen von Web 2.0 ist die NoSQL-Bewegung eine Reaktion auf die sich ändernden Anforderungen an Datenbanken.

Durch die enorm wachsenden Datenmengen, die oftmals in unstrukturierter Form vorliegen, sowie den extrem vielen Zugriffen auf diese Daten, treten bei den herkömmlichen relationalen Datenbanksystemen vermehrt Engpässe auf, da diese nur schlecht horizontal skalieren (vgl. Steiner, 2014, p. 1). Je größer die Tabellen in einer relationalen Datenbank, um so größer der Performance-Verlust, sodass früher oder später die vorhandene Hardware durch leistungsstärkere ersetzt werden muss. Dieses Phänomen bezeichnet man auch als vertikale Skalierung. Diese stößt jedoch irgendwann an ihre Grenzen, sodass man auf die Idee kam, die Rechenleistung auf mehrere Systeme zu verteilen.

Spätestens seit dem der Begriff „Cloud“ einen hohen Bekanntheitsgrad erlangt hat, steigt das Interesse an der horizontalen Skalierbarkeit. Hierbei sind bezüglich der Hardware keine Grenzen gesetzt. Es werden weitere Rechner zur Verfügung gestellt, um die Leistung des gesamten Systems zu steigern.

[...]