Untitled - Offene

1
In diesem Abschnitt geht es um NoSQL.
Da dieser Themenbereich sehr umfangreich ist und die eingesetzten Technologien
stark im Wandel sind, werden wir uns im wesentlichen die grundlegenden
Prinzipien und Lösungsansätze ansehen.
Hierzu werden wir folgenden Fragstellungen nachgehen:
• Was ist NoSQL?
• Warum braucht man NoSQL?
• Welche Lösungsansätze gibt es?
• Was ist das besondere an NoSQL?
• Welche Kategorien von NOSL gibt es?
• Was hat der NoSQL Markt zu bieten?
In dem kurzen Abschnitt „NoSQL unter der Haube“ werden wir uns kurz
befassen mit den wichtigsten allgemeinen Lösungsansätzen von NoSQL
Datenbanken. Hierzu werden die wichtigsten Stichworte kennenlernen. Eine
Vertiefung der einzelnen Ansätze würde den Rahmen dieser Vorlesung sprengen.
Die einzelnen Lösungsansätze und das Arbeiten der mit NoSQL kann man nur in
einem gesonderten Kurs gerecht werden.
2
Die Abkürzung NoSQL steht für „Not-Only-SQL“ und bietet einen gänzlich
anderen Ansatz als die relationalen Datenbanken.
Bei den relationalen Datenbanken liegt ein relationales Modell zu Grunde. Die
Daten werden durch ein Datenmodell beschrieben, welches als Grundlage für die
Definition von Tabellen dient, die durch das Datenbank Managementsystem
verwaltet werden.
Mit dem „No-Only-SQL“ Ansatz möchte man nun weg von einem starren
Datenmodell und starren Tabellen.
• Zum einen kann es dazu führen, dass bei sehr großen Mengen die max. Größe
eines Transaktionslogs überschritten wird. Dies würde dazu führen, dass die
Transkation nicht durchgeführt werden kann.
• Zum anderen kann es passieren, dass die Tabelle über Minuten und ggf.
Stunden gesperrt ist und entsprechende Applikationen blockiert sind.
Es liegt daher der Gedanke nahe, sich von einem starren Datenbank Schema zu
lösen und nach alternativen Konzepten zu suchen.
3
SQL unterstützt zwar das Ändern von Tabellen in Form der SQL Anweisung
„Alter table“.
Wenn wir uns das Szenario in der Abbildung näher ansehen, werden wir sehr
schnell feststellen, wo das Problem liegt.
Das betrachtete Szenario ist dabei wie folgt.
• Es gibt eine Tabelle „Person“ mit den Spalten/Attributen:
• ID – welches den Primärschlüssel beinhaltet
• Name – Name/Nachname einer Person
• Vorname – Vorname einer Person
• Nun möchten wir die Tabelle um eine Spalte erweitern und eine Spalte „Title“
hinzufügen.
Wenn wir nun annehmen, dass in der Tabelle über 1 Million Einträge/Zeilen sind,
werden zwangsläufig alle Datensätze innerhalb einer Transaktion gesperrt, um
die Änderungen durchführen zu können. Nach dem Einfügen müssen
4
gegebenenfalls Index-Verzeichnisse wieder neu aufgebaut werden. Um die ACIDGarantie zu erfüllen, werden zusätzlich alle Aktionen in einem Transaktions-Logging
protokolliert. Dies kann dazu führen, dass die Tabelle über eine längeren Zeitraum (
Minuten bis hin zu Stunden) gesperrt ist.
Die Antwortzeiten für Anwendungen insb. im Web-Bereich sind somit nicht akzeptabel.
Es ist somit offensichtlich, dass man das man nach alternativen Ansätzen gesucht hat, und
diese unter dem Stichwort NoSQL zusammengefasst hat.
4
Die Suche nach alternativen Konzepten hat aber noch weitere Gründe.
Es werden in der Praxis immer mehr Daten zur Verarbeitung herangezogen, die
zum Beispiel aus den „sozialen Medien“ und von „Internet-of-Things““ Geräten
stammen.
Diese Datenquellen liefern :
• Sehr große Datenmengen. Nicht selten bewegen wir uns dabei im PetabyteBereich.
• Die Daten unterliegen keinem festen Schema
• Die Werte ändern sich in der Regel sehr schnell
Dies entspricht dem Grundgedanken, der mit dem Schlagwort „Big-Data“
umschrieben wird.
Hinweis. Dies merkt man schon daran, dass im Zusammenhang von Big data
auch immer das Schlagwort NoSQL genannt wird.
5
Ein weiteres Problem ist die Skalierbarkeit.
Relationale Datenbanken sind nur in begrenztem Umfang „Horizontal“
skalierbar.
Horizontal skalierbar bedeutet , man fügt einen weiteren Datenbank Server in
seiner Arbeitsumgebung hinzu.
Der Grund in der begrenzten horizontalen Skalierbarkeit für relationale
Datenbank liegt darin, dass das ACID Modell zu Grunde gelegt wird, welches
sich nur schwer in verteilen Systemen umsetzen lässt.
Wie wir noch sehen werden, rückt man bei NoSQL von diesem ACID Model ein
und verwendet ein sogenanntes BASE Model.
Das BASE Model werden wir später noch kennenlernen.
Relationale Datenbank Systeme bieten meist nur vertikale Skalierbarkeit.
Horizontale Skalierbarkeit:
Unter horizontaler Skalierbarkeit (auch Scale-out genannt) versteht man das
einfache Hinzufügen bzw. Entfernen von einzelnen Knoten des Systems.
6
Vertikale Skalierbarkeit:
Bei der vertikalen Skalierbarkeit (Scale-up) bei der die Leistungsfähigkeit einer
einzelnen Maschine erhöht wird.
6
Um besser zu verstehen, was NoSQL genau ist, schauen wir uns man einige
Merkmale / Charakteristiken von NoSQL Systemen an.
Die wichtigsten Merkmale sind:
• Es liegt KEIN relationales Datenmodell zu Grunde
• Es handelt sich um ein hochverteiltes und horizontal skalierbare System
• Einhergehend mit Skalierbarkeit ist es notwendig, die Daten auf mehrere
Knoten zu verteilen, was eine Datenreplikation beinhaltet. Diese
Datenreplikation wird auch data shading genannt.
• Es wird gefordert, dass das System einfache APIs anbietet, auf denen
Applikationen erstellt werden können. Komplexe Operationen wie JOINS
sind nicht notwendig.
Ein weiteres Merkmal betrifft die Konsistenz der Daten. In der NoSQL Welt ist
dies das BASE-Model .
7
Auch wenn einige bisher genannten Merkmale auch von relationalen
Datenbanken unterstützt werden, gibt es noch weitere Aspekte, die wir uns
ansehen müssen, um ein tieferes Verständnis zu bekommen.
Wie wollen uns daher nun der folgenden Fragstellung nachgehen:
„Was NoSQL“ überhaupt ist?
´Vorab:
• NoSQL ist nicht gleich NoSQL.
• NoSQL ist zunächst mal ein Schlagwort, unter dem alle NICHT-relationalen
Datenbanken zusammengefasst werden.
Um den Überblick nicht zu verlieren, schauen wir uns nun die einzelnen
Kategorien an, in die NoSQL System sich einteilen lassen.
Relationale Welt:
Aus der relationalen Welt kennen wir bereits die bekannten Herstellen wie
Microsoft SQL Server, Oracle, IBM DB2 sowie die unterschiedlichen
OpenSource Lösungen wie MySQL etc.
8
Dieser relationalen Welt steht die NoSQL Welt gegenüber.
NoSQL Welt
In der NoSQL Welt unterscheidet man zweit Kategorien.
1. „Soft-NoSQL“ Kategorie
In diese Kategorie fallen alle Objektorientierten Datenbanken, XML-Datenbanken
etc. Wie wir sehen werden , unterscheiden sich diese vom Konzept schon sehr von
den eigentlichen NoSQL Systemen.
Einen Überblick über OODB und XML-DB finden Sie in den jeweiligen
Abschnitten über Entwicklungstendenzen.
2. Kern-NoSQL
Als Kern-NoSQL oder auch „Core NoSQL“ bezeichnete System sind von Hause
aus „schemalos“. Es liegt also kein Schema für die Daten zu Grunde. Wie wir
später noch sehen werden. gibt es in diesem Bereich unterschiedliche OpenSource
Lösungen. Daher sind hier in der Abbildung keine Produkt Namen aufgeführt.
Stattdessen sehen Sie in der Abbildung die unterschiedlichen Unterkategorien von
NoSQL-Systemen.
Im einzelnen sind dies:
• Wird-Column Stores
• Document Stores
• Key-Value Stores
• GraphStores
Die ersten drei Unter-Kategorien werden wir uns nun näher ansehen um das
Core-No-SQL Paradigma besser zu verstehen zu lernen.
8
Aus der relationalen Welt kennen wird, dass die Daten in Tabellen abgelegt
werden. Die Sichtweise ist dabei „zeilen-orientiert“. Dies bedeutet, wir haben in
einem Tupel alle Werte einer Zeile.,
Bei dem Column Family Systemen stehen die Spalten im Mittelpunkt.
In der Abbildung ist zu sehen, dass alle Werte in einem Tupel, die gleiche
Bedeutung haben. So sehen Sie, dass es ein Tupel ( 48, 8, 32,..) gibt, welches die
Altersangaben einzelner Personen enthält.
9
In der Abbildung sehen Sie nun die Namen einzelner Column-System, die zur
Zeit auf dem Markt sind.
Wenn Sie also nun in Zukunft in einem Fachartikel oder in einer
Produktbeschreibung das Schlagwort Hadoop oder Cassandra lesen, wissen Sie
nun, das es sich um einen NoSQL Datenbank aus der Kategorie Column-Family
handelt.
10
Eine weitere Kategorie von NoSQL Datenbank sind die Key-Value Systeme.
Im Zentrum der Betrachtungen stehen hier Daten, die sich als Tupel auffassen
lassen.
Ein Element wird als Key ( Schlüssel) interpretiert, welcher einen Wert genau
identifiziert.
Der Wert selbst wird in einem weiteren Element des Tupels hinterlegt.
Solche Tupel lassen sich sehr gut in Hash-Tabellen ablegen, wie wir sie von z.B.
Java her kennen.
Bei dem Wert selbst kann es sich um:
• Einfache skalare Werte handeln ( z.B. einen Integer Wert)
• Es kann sich aber auch um ein Array, Liste, etc. handeln
11
In der Abbildung sehen Sie nun die Namen einzelner Key-Value Systemen, die
zur Zeit auf dem Markt sind.
Wenn Sie also nun in Zukunft in einem Fachartikel oder in einer
Produktbeschreibung das Schlagwort Volemort lesen, wissen Sie nun, das es
sich um einen NoSQL Datenbank aus der Kategorie Key-Value Store handelt.
12
Bei den Document Store Systemen stehen Dokumente im Mittelpunkt.
Unter Dokument werden hier aber nicht Textdokument wie zum Beispiel
WinWord verstanden.
Vielmehr versteht man hier unter Dokument, Daten, die in XML, HTML,
JSON Format vorliegen. Im allgemein also alle Daten, die einer Struktur
vorliegen, die man mit einer Software weiter verarbeiten kann.
Jedem Dokument wird hierbei eine ID zugewiesen, welches das Dokument
eindeutig identifiziert.
13
In dieser Abbildung sehen Sie noch einmal genauer:
• Was ist ein Dokument und
• Das Mapping von ID zu Dokument
Auf der linken Seite sehen Sie ein kleines Anwendungs-Szenario. Es wird
gezeigt, dass zum Beispiel eine Person, die einen Internet Blog betreibt ( hier
Blogger genannt) die einzelnen Beiträge in einem ‚Blog‘ bereitstellt. Jeder
Blog-Betrag stellt in diesem Sinne ein Dokument dar.
14
In der Abbildung sehen Sie nun die Namen einzelner Dokument Store Systemen,
die zur Zeit auf dem Markt sind.
Wenn Sie also nun in Zukunft in einem Fachartikel oder in einer
Produktbeschreibung das Schlagwort CouchDB oder MongoDB lesen, wissen
Sie nun, das es sich um einen NoSQL Datenbank aus der Kategorie Dokument
Store handelt.
15
In dieser Abbildung sehen Sie eine Gegenüberstellung bzw. Zusammenstellung
der wichtigsten Begriffe, aus dem Bereich NoSQL.
Zum Vergleich wurden auch die Begriffe aufgeführt, die Sie bereits aus der
relationalen Welt kennen.
Relationale Welt.
Dort haben wir es mit Server, Databases , Tabellen und Primärschlüsseln zu tun
Key Value DB
Hier werden die Daten auf Clustern verarbeitet und zur Identifikation wird der
Begriff Key verwendet.
Column Family DB
Hier werden die Daten ebenfalls auf Clustern verarbeitet und anstelle von
Tabellen, redet man von Column Familie.
Document DB
Hier werden die Daten ebenfalls auf Servern verwaltet und anstelle von Database
redet man hier von DocSpace. Als Schlüssel wird hier der Dokument Name (=
16
Id) verwendet.
Quelle:
Die Tabelle in der Abbildung ist angelehnt an das Buch:
„NoSQL, EINSTIEG IN DIE WELT NICHT RELATIONALER WEB 2.0
DATENBANKEN
Hanser Verlag
16
Dies sind nur einige wenige Beispiele von NoSQL Datenbanken und ihre
Einordnung in die unterschiedlichen Kategorien.
Mehr finden Sie unter: http://www.nosql-database.org/
17
Um ein tieferes Verständnis von NOSQL Datenbanken zu erhalten, schauen wir
uns zunächst die wichtigsten allgemeinen Lösungsansätze an, wie NoSQL
Datenbanken eingesetzt werden und wie diese im Prinzip arbeiten.
Im wesentlichen schauen wir aus drei verschiedenen Perspektiven auf die NoSQL
Landschaft
Dies sind im einzelnen
• App – Wie arbeiten eigentlich Anwendungen
• API – Welche Schnittstellen gibt
• NoSQL intern – Hier interessieren uns im wesentlichen die Lösungsansätze
bzgl. Der Skalierbarkeit.
App
Da ist zum einen die Anwendungswelt.
Wenn wir davon ausgehen, dass wir riesige Datenmengen verarbeiten wollen,
dann müssen die Applikationen in einem sogenannten Streaming Mode arbeiten.
Dies bedeutet, dass Eingabedaten kontinuierlich eingelesen, verarbeitet und
ausgegeben werden. Es werden also nicht erst ALLE Daten eingelesen und dann
verarbeitet, sondern die Daten werden in einzelnen „Blöcken“ verarbeitet.
Darüber hinaus handelt es sich in der Regel um verteilte Anwendungen . Dies
beutet, dass die zu erledigende Aufgabe auf unterschiedliche Applikationen
18
aufgeteilt sind und diese wiederum auf unterschiedlichen Rechnern ablaufen.
API
Sofern eine Kommunikation notwendig ist, werden einfache APIS gefordert, die wenn
möglich Plattform und Programiersprachen unabhängig sind.
NoSQL – intern
Für den Einsatz eine NoSQL DB ist es sinnvoll sich etwas genauer mit den allgemeinen
Konzept zu beschäftigen, die den verschiedenen NoSQL Datenbanken zu Grunde liegen.
Hierbei interessiert besonders das Erreichen der Skalierbarkeit.
18
Betrachten wir nun zunächst die Anwendungssicht.
Dort hat sich das sogenannte MAP-REDUCE durchgesetzt.
MAP-REDUCE stellt einen allgemeinen Ansatz dar, bei dem der Fluss der Daten
im wesentlichen aus zwei Schritten besteht.
Zur Verdeutlichung betrachten wir ein Beispiel. Stellen wir uns vor, wir haben
Datenströme und wollen die Häufigkeit von Worten zählen.
Schritt 0: Aufteilen und Starten der MAP/REDUCE Prozesse
Da es sich um sehr große Datenmengen handelt, werden die Ausgangsdaten auf
unterschiedliche MAP-Prozesse verteilt, die sich auch auf unterschiedlichen
Rechnern befinden können.
Schritt 1: MAP
In einem MAP-Schritt, werden die Ausgangsdaten eingelesen und mittels einer
map() Funktion transformiert und als Zwischenergebnis abgelegt.
In unserem Beispiel würde die map() Funktion als Eingabe Parameter einen
String erhalten, in dem ein beliebiger Text abgelegt ist. Ein weitere Parameter
enthält einen Key, welche den String identifiziert.
19
Die map() Funktion würde nun die Anzahl der gefundenen Wörter als Zwischenergebnis
ausgeben.
Schritt 2: REDUCE
In einem weiteren Schritt werden die Zwischenergebnisse mittels ein reduce() Funktion
weiter verarbeitet. Die reduce() Funktion erhält nun eine Liste aus den
Zwischenergebnissen und kann für ein gestimmtes Wort die Gesamtanzahl ermitteln.
Die map() und die reduce() Funktion muss natürlich von dem
Anwendungsprogrammierer/rinnen bereit gestellt werden.
Das Verteilen und Starten der einzelnen Anwendungen wird vom dem NoSQL System
übernommen.
Wie Sie hier schon erahnen können, handelt es sich bei NoSQL-DBs nicht nur um ein
System für die reine Datenablage, sondern um ein Framework/Plattform für die
Anwendungen.
19
Bei den Schnittstellen handelt es sich in der Regel um sogenannte REST Apis.
REST steht für Representational State Transfer.
Es handelt sich hierbei nicht um eine Implementation, sondern vielmehr um ein
Entwurfsmuster. Dem Entwurfsmuster liegen hierbei folgenden Regeln zu
Grunde:
• Der Kommunikation erfolgt über Endpoints (Resource) . Ein Endpoint ist
nichts weiter als eine Web –Resource / URL.
• Die Daten selbst werden im JSON Format beschrieben.
• Als Kommunikationsprotokoll bzw. für die Operationen kommt HTTP zum
Einsatz. Wobei die Verben GET, HEAD, PUT, POST und DELETE verwendet
werden.
20
Die Abbildung hier gibt Ihnen einen Überblick über die wichtigsten
Lösungsansätze, die innerhalb eines NoSQL Systems zum Einsatz kommen.
Das allgemeine Ziel ist ja eine hochskalierbare Datenbank zur Verfügung zu
stellen.
Die kleine Tabelle zeigt nun in der linken Spalte die Anforderungen, die es zu
erfüllen gibt. In der rechten Spalte sind die wichtigsten Stichworte zu den
jeweiligen Lösungsansätzen aufgeführt.
Eine detaillierte Erklärung zu den einzelnen Lösungsansätzen verlangt einen
tieferen Einblick in die theoretischen Grundlagen. Daher wird an dieser Stele nur
eine kurze Erklärung gegeben, um zu verstehen, was genau das zu lösende
Problem ist.
Multiversion Control ( genauer MVCC = Multiversion Concurrency
Control)
Hierbei geht es um die Möglichkeit, wie verteile Anwendung möglich effizient
auf Daten zugreifen können ohne sich gegenseitig zu blockieren.
In relationalen Datenbank wird meist ein pessimistisches Sperrverhalten zu
Grunde gelegt. Dies bedeutet, dass angenommen wird, dass die Daten zu sperren
sind , da sie verändert werden in Zukunft.
21
In NoSQL Datenbanken geht man von einem optimistischen Sperrverhalten aus. Dies
bedeutet, dass angenommen wird, dass die Daten nur gelesen werden und keine Sperren
notwendig sind. Wenn geändert wird, kann man immer noch eine Sperre setzen.
 Siehe auch : http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/MVCC
BASE
Bei relationalen Datenbanken lieg das ACID Model zu Grunde. (ACID = Atomic,
Consistency, Integrity, Durability)
Laut CAP –Theorem von Brewer widerspricht sich hohe Verfügbarkeit mit der
Consistency wie wie sie in dem ACID Modell gefordert wird.
Daher wird bei NOSQL Systeme das sogenannte BASE Model verwendet.
BASE steht dabei für Basically, Availability, Soft State Eventually Consistent.
Wie Sie dem Namen bereits entnehmen können, ordnet man der Anforderung nach
Verfügbarkeit höheren Stellenwert ein als die der Anforderung nach Konsistenz.
Quellen:
• CAP Theorem: http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
• CAP Theorem: http://wikis.gm.fh-koeln.de/wiki_db/Datenbanken/CAP)
• BASE: http://lwibs01.gm.fh-koeln.de/wikis/wiki_db/index.php?n=Datenbanken.BASE
Vector Clocks
Da es sich bei NOSQL um eine verteiltes System handelt, bei dem Daten parallel
verarbeitet werden, besitzt jede beteiligte Instanz eine Kopie der Daten. Somit benötigt
man ein Verfahren, mit dem man feststellen kann, welche Version der Daten nun die
Aktuelles ist.
Bei Vector Clocks handelt es sich genau um ein solches Verfahren, bei dem die einzelnen
Komponenten in dem verteilten System für jeden Datensatz, der verarbeitet wird, ein
Zeitstempel erzeugt wird. Dies ermöglicht dem System zu erkennen, welche Version eines
Datensatzes die Aktuellste ist.
PAXOS – Commitment Protokolle
Um eine Datenintegrität sicherzustellen, wird ähnlich wie bei den relationalen
Datenbanken ein „Commit“ (Bestätigung) Protokoll eingesetzt, um Daten zu quittieren.
Bei den NoSQL System kommen hier sogenannte PAXOS Protokolle zum Einsatz.
21
PAXOS ist also ein Familie von Protokollen.
Eine genaue Beschreibung der PXOS Familien würde den Rahmen des Kurses sprengen.
Für alle, die es genau wissen möchten, empfehle ich das nachfolgende Dokument:
• https://www4.informatik.uni-erlangen.de/DE/Lehre/SS02/HS_DOOS/pdf/handoutsimimeie.pdf
21
22