PDF-Download - Pentasys AG

Datenbanktechnologien: NoSQL
Alternative Datenbanktechnologien
NoSQL und seine Spielarten
Die Idee, Daten nicht in einem relationalen Modell mit Tabellen und Verbindungen zwischen
diesen zu speichern, ist nicht neu. Die ersten Systeme wurden bereits in den 70er-Jahren entwickelt. In den 80er Jahren wurde Lotus Notes populär, das als erster erfolgreicher Vorläufer heutiger NoSQL-Datenbanken angesehen werden kann. Einen großen Schub erlebten die NoSQL
Datenbanken aber zur Jahrtausendwende durch den Internetboom. Neue Ideen und neue Geschäftsmodelle entstanden und mit ihnen der Bedarf, sehr große Datenmengen effizient zu verarbeiten. Man denke dabei nur an soziale Netzwerke wie Facebook oder Firmen wie Amazon. Aus
diesen Bedürfnissen heraus ist eine Reihe interessanter Datenbanken entstanden, die Alternativen
zum klassischen relationalen Modell bieten.
NoSQL und Big Data
„NoSQL“ wird häufig in einem Atemzug mit „Big Data“
verwendet. Beide Begriffe sind jedoch nicht eindeutig definiert. Die gebräuchlichsten Interpretationen sind
folgende.
NoSQL steht für „Not only SQL“ und dient als Oberbegriff für hochverfügbare, skalierbare und performante
Datenbanksysteme. Natürlich ist dabei auch die Abfrage
und Speicherung der Daten diesen Attributen unterworfen, was Alternativen zum relationalen Modell notwendig macht. Zur Abfrage und Bearbeitung der Daten ist
SQL dabei nicht unbedingt das Mittel der Wahl. NoSQL
Datenbanken stellen hierfür APIs und/oder alternative
Abfragemechanismen zur Verfügung.
Big Data ist primär - wie der Name schon sagt - die
Speicherung und Verarbeitung großer Datenmengen.
Dies lässt sich zwar auch mit „klassischen“ relationalen
Datenbanken bewerkstelligen. Allerdings stoßen diese
an ihre Grenzen, wenn die Daten z.B. unstrukturiert
sind, sie in unterschiedlichsten Datenformaten vorliegen
und die Antwortzeit bei der Abfrage eine große Rolle
spielt. Wer schon einmal in einer relationalen Datenbank
eine Auswertung großer Datenmengen über eine hohe
Anzahl von Tabellen mit vielen inner und outer Joins
gemacht hat, kann dies bestätigen.
Grundlagen
Die Vorstellung sämtlicher Grundlagen von NoSQL, vor
allem die Algorithmen wie z.B. Map/Reduce, würde
den Rahmen dieses Artikels sprengen. Hier werden
zwei wesentliche Konzepte vorgestellt, nämlich das
CAP-Theorem und das Konsistenzmodell BASE.
PENTASYS-Blickpunkte
Partition
Abbildung 1: Darstellung des CAP-Theorems
in Anlehnung an das Projektmanagementdreieck
Das CAP Modell
Im Jahr 2000 stellt Eric Brewer sein sogenanntes „CAP-Theorem“ vor. CAP
steht dabei für Consistency (Konsistenz), Availability (Verfügbarkeit) und
Partition Tolerance (Partitionstoleranz). Partitionstoleranz bedeutet, dass
einzelne Nachrichten oder Knoten im verteilten System ausfallen können,
ohne das Gesamtsystem zum Erliegen zu bringen. Das CAP-Theorem
postuliert, dass verteilte Datenbanksysteme von diesen drei Größen nur
maximal zwei erfüllen können. Man kann das quasi mit dem berühmten
„Projektmanagementdreieck“ aus Zeit, Kosten und Qualität vergleichen.
Für Datenbanken bedeutet dies nun, dass hohe Verfügbarkeit und Ausfallsicherheit zu Lasten der Konsistenz der Daten geht. Da sich das CAP-Theorem auf verteilte System bezieht, bedeutet Konsistenz hier, dass nach einer
Datenbanktransaktion die Knoten eines Cluster konsistent sind, d.h. eine
Abfrage liefert das gleiche Ergebnis unabhängig davon welcher Knoten die
Abfrage bearbeitet.
Das BASE Modell
Aufbauend auf diesem Theorem wurde nun BASE als Konsistenzmodell entwickelt. BASE steht für „Basically Available, Soft State, Eventually Consistent“. Während beim ACID-Konsistenzmodell (Atomic, Consistent, Isolated, Durable) die Datenkonsistenz im Mittelpunkt steht, legt BASE
den Schwerpunkt auf die Verfügbarkeit (Basically Available). Die Konsistenz der Daten ist zwar ebenfalls ein Ziel, aber nicht das primäre (Eventually Consistent). Verteilte Systeme erreichen den Zustand der Konsistenz
über alle Knoten unter Umständen nicht unmittelbar nach jeder Transaktion, sondern nach einem gewissen Zeitraum der Inkonsistenz.
Arten von NoSQL Datenbanken
Um nun die Anforderungen an Verfügbarkeit, Performance und Ausfallsicherheit zu erfüllen gibt es unterschiedliche Lösungsansätze, speziell was
die Art der Datenspeicherung angeht. Im Folgenden werden diese Ansätze
kurz vorgestellt.
{
}
”Nachname“:“Becher”
”Vorname”:”Horst”
”Geburtstag”:”14.11.1982”
Abbildung 2: Einfaches Beispiel eines Dokuments im JSON-Format
Document Stores
Auch wenn der Name „Document Store“ etwas anderes suggeriert handelt
es sich hierbei nicht um Dokumentendatenbanken. Document Stores speichern strukturierte Informationen, wie sie z.B. das JSON-Format (JavaScript Object Notation) bietet.
Meist werden solche Dokumente in der Datenbank mit einer eindeutigen ID
abgelegt. Wie die Informationen in einem solchen Dokument dabei aufgebaut sind, ist nicht Sache der Datenbank, sondern der Anwendung. Es
gibt also kein Datenbankschema im eigentlichen Sinn. Die Anwendung ist
verantwortlich für die Strukturierung der Daten. Dies hat zwar Nachteile
wenn es auf Normalisierung und referenzielle Integrität ankommt, bietet
aber Vorteile bei der schnellen Implementierung von Änderungen in der
Anwendung, speziell im Web-Umfeld.
Zu den bekanntesten Vertretern der Document Stores zählen CouchDB und
MongoDB. Interessant zu wissen ist, dass der „Kopf“ hinter der CouchDB,
Damien Katz, früher Senior-Entwickler bei Lotus Notes war.
Wide Column Stores
Wide Column Stores sind Datenbanken, in denen die Daten spaltenorientiert gespeichert werden. Dies bringt im Gegensatz zur reihenorientierten
Speicherung relationaler Datenbanken Vorteile bei der Datenkompression
2
PENTASYS Blickpunkte NoSQL
und der Datenanalyse. Nachteil dieser Methode ist eine geringere Performance bei der Speicherung. In den einzelnen „Zellen“ können jedoch nicht
nur einfache Attribute wie Zahlen oder Zeichenketten gespeichert werden,
sondern je nach Datenbank auch komplexe Strukturen.
Bekannte Vertreter dieser Datenbankart sind z.B. HBase (die Open Source
Nachimplementierung von Googles BigTable) und Amazon SimpleDB.
Die folgenden Tabellen stellen die zwei Methoden der Speicherung kurz
dar:
ID
Vorname
Nachname
Geburtstag
1
Maria
Huber
27.03.1966
2
Horst
Becher
14.11.1982
3
Stefan
Wagner
28.02.1973
4
Sabine
Müller
04.05.1989
ID
1
2
3
4
Vorname
Maria
Horst
Stefan
Sabine
Nachname
Huber
Becher
Wagner
Müller
Geburtstag
27.03.1966
14.11.1982
28.02.1973
04.05.1989
Tabelle 1: Reihenorientierte Speicherung bei
relationalen Datenbanken
Tabelle 2: Spaltenorientiert Speicherung bei
Wide Column Stores
Key/Value Datenbanken
Key/Value Datenbanken speichern die Daten als Schlüssel-Werte-Pärchen
und bieten somit ein einfaches Datenbankschema. Die Schlüssel können
dabei oft in Namensräume und/oder verschiedene Datenbanken aufgeteilt werden. Die Werte können nicht nur Zeichenketten, sondern durchaus
auch komplexere Datenstrukturen sein. Die Vorteile der Key/Value Datenbanken liegen im einfachen Datenmodell ohne Relationen und der damit
verbundenen Skalierbarkeit.
Neben zwei Systemen von Amazon, nämlich Dynamo und S3, gehören
Redis und Riak zu den bekanntesten Vertretern dieses Datenbanktyps.
Graphdatenbanken
Graphdatenbanken sind Systeme zur Verwaltung von (gerichteten) Graphen
und Baumstrukturen, also aus Datenstrukturen, die sich aus Elementen
(Knoten) und deren Verknüpfungen untereinander (Kanten) zusammensetzen. Die Abbildung 3 (rechts) zeigt ein einfaches Beispiel. Wie man an
diesem Beispiel sehen kann, können die Kanten eines Graphen wiederum
Attribute über die Verknüpfungsart enthalten.
Die zu Grunde liegenden mathematischen Modelle der Graphentheorie ermöglichen eine Navigation durch diese Datenstrukturen. So lässt
sich z.B. der kürzeste Weg zwischen zwei Knoten ermitteln, womit sich
Funktionen wie „Woher kenne ich…“ in sozialen Netzwerken realisieren
lassen. Auch Navigationsgeräte arbeiten nach diesem Prinzip. Hier sind die
Orte (Adresse, Point of Interest, …) als Knoten, die Verbindungsstraßen
zwischen den Orten als Kanten abgebildet. Die Frage nach dem kürzesten
Weg zwischen zwei Orten ist somit einfach zu ermitteln.
Die Knoten in einer Graphdatenbank können auch unterschiedliche „Typen“
repräsentieren, z.B. Personen, Produkte und Tätigkeiten. Auch die Kanten
können unterschiedlichste Verknüpfungsarten darstellen. Auf diese Weise
können beliebige Beziehungsnetze abgebildet werden (Abbildung 4).
Es gibt auf dem Markt eine Reihe von Graphdatenbanken, darunter Neo4J,
HypergraphDB oder auch Twitters FlockDB.
Abbildung 3: Beispiel für einen Graphen
Abbildung 4: Graph mit unterschiedlichen
Knotentypen
PENTASYS Blickpunkte NoSQL
3
Datenbanktechnologien: NoSQL
Einsatzmöglichkeiten und Grenzen
Wie wir gesehen haben gibt es nicht DIE
NoSQL-Technologie. Vielmehr verbergen sich
hinter diesem Begriff unterschiedliche Lösungsansätze zur Speicherung von Daten. Jeder dieser
Ansätze hat seine eigenen Stärken. So sind Key/
Value Datenbanken besonders für hochskalierbare Systeme geeignet, bei denen u.U. mehrere
tausend Knoten weltweit verteilt aufgebaut werden
müssen. Graphdatenbanken wiederum eignen
sich sehr gut, um komplexe Netze abzubilden.
Für Systeme, die hohe Anforderungen an Transaktionssicherheit und Datenkonsistenz stellen, sind
NoSQL-Datenbanken – unabhängig von deren
Technologie – eher nicht geeignet.
Ein interessanter Ansatz ist die „Mischform“ aus
beiden Datenbankwelten. In einem Online-Shop
beispielsweise gibt es eine Vielzahl an Funktionen
mit unterschiedlichen Anforderungen an die Transaktionssicherheit und Datenmenge. Eine Funktion
wie „Kunden, die diesen Artikel betrachteten haben
auch angesehen“ verfolgt alle Anwender (auch die
unbekannten) und speichert deren Nutzerverhalten. Hier wird eine enorme Datenmenge erzeugt,
die auch schnell wieder zur Verfügung stehen
muss. Die Datenkonsistenz ist hier nur von untergeordneter Bedeutung. Im Vergleich dazu ist die
Anzahl der eigentlichen Kauf- und Bezahlvorgänge
gering. Dafür sind dort die Transaktionssicherheit
und die Datenkonsistenz extrem wichtig.
Um nun diese – eigentlich widersprüchlichen –
Anforderungen gleichermaßen zu erfüllen kann
man ein System mit zwei Datenbanken aufbauen.
Die Funktionen, die eine hohe Datenkonsistenz und
Transaktionssicherheit benötigen, benutzen eine
relationale Datenbank im Backend. Funktionen
mit hohem Datenvolumen und geringer Anforderung an die Konsistenz arbeiten mit einer NoSQLDatenbank. Dabei können manche Informationen
auch in beiden Datenbanken redundant vorliegen,
z.B. die Information „Kunden, die diesen Artikel
kauften, haben auch gekauft“.
Fazit
Der Begriff NoSQL umfasst verschiedene Datenbanktechnologien, die allesamt Alternativen zum
klassischen relationalen Modell darstellen. Jede
dieser Technologien hat dabei ihren eigenen
Schwerpunkt. Das heißt jedoch nicht, dass relationale Datenbanken ausgedient haben. Man
hat aber durch diese unterschiedlichen Ansätze
mehr Möglichkeiten bei der Implementierung
eines Systems. Je nachdem, welche Anforderungen gestellt werden kann die eine oder die
andere Datenbank die bessere Lösung darstellen.
Oder auch die Verwendung mehrerer, wie oben
beschrieben.
Über den Autor
Manfred Schlaucher ist als
Projektleiter für PENTASYS
tätig.
Seine
fachlichen
Schwerpunkte sind Architektur, Projektvorgehen und
Projektmanagement.
PENTASYS AG
Rüdesheimer Straße 9
80686 München
Tel.: + 49 89 57 95 20
Die PENTASYS AG, mit Sitz in München, Geschäftsstellen in Frankfurt
am Main, Köln und Nürnberg, ist ein Tochterunternehmen der französischen AUSY Group mit 4.000 Mitarbeitern in 11 Ländern. Das Beratungs- und Systemhaus ist darauf spezialisiert, Geschäftsprozesse
unter besonderer Berücksichtigung spezifischer Kundenbedürfnisse
mit maßgeschneiderten IT-Anwendungen zu optimieren. Das Leistungsspektrum der ISO-9001/2008 zertifizierten PENTASYS AG reicht
dabei von der Bedarfsanalyse über das Projektmanagement bis hin zur
Entwicklung und Implementierung der IT-Lösungen, die unsere Kunden
bei der Stärkung ihrer Marktposition unterstützen. Zu den Referenzkunden gehören die Marktführer in den Branchen Finance, Telco, Travel,
Transport & Logistics, Automotive und Pharma.
Sämtliche Inhalte des Newsletters, auch Konzepte und Design, sind urheberrechtlich geschützt. Das Copyright/Urheberrecht liegt bei der PENTASYS AG.
Geschäftsstelle Frankfurt:
Solmsstraße 41
60486 Frankfurt am Main
Tel.: + 49 69 70 79 83 90
Geschäftsstelle Köln:
Dülkenstraße 9
51143 Köln
Tel.: + 49 2203 93 54 87 6
Geschäftsstelle Nürnberg
Rothenburger Straße 116
90439 Nürnberg
Tel.: +49 911 13 13 01 0
[email protected]
www.pentasys.de
©2015 PENTASYS AG. Stand April 2015
Die Blickpunkte sind ein kostenloser Newsletter
der PENTASYS AG.