Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen

Transkript

1 Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 16OH21005 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt beim Autor/bei der Autorin.

2 1

3 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

4 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

5 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

6 gegebenenfalls Index-Verzeichnisse wieder neu aufgebaut werden. Um die ACID- Garantie 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

7 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 Petabyte- Bereich. 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

8 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

9 Vertikale Skalierbarkeit: Bei der vertikalen Skalierbarkeit (Scale-up) bei der die Leistungsfähigkeit einer einzelnen Maschine erhöht wird. 6

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 Dies sind nur einige wenige Beispiele von NoSQL Datenbanken und ihre Einordnung in die unterschiedlichen Kategorien. Mehr finden Sie unter: 17

23 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

24 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

25 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

26 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

27 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

28 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

29 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 : 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: CAP Theorem: 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

30 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: 21

31 22