Die Oracle NoSQL Datenbank ist ein Vertreter der Key-Value Store Datenbanken.
Auf Basis der soliden Berkeley DB Java Edition hat Oracle die bestehenden Replikationsmechanismen der Berkeley DB optimiert und damit eine neue Datenbank, die Oracle NoSQL entwickelt.
Eine zusammenfassende Einführung in die Oracle NoSQL Datenbank finden Sie hier:
Veröffentlichung zu diesem Thema in der DOAG News 05-2014 (Eine Anmeldung an der DOAG Website ist allerdings erforderlich):
⇒ 2014-05-News-Gunther-Pippèrr-Oracle-NoSQL---eine-Alternative-für-die-traditionelle-Datenbank.pdf
Bzw. über Slideshare
Deutsch - Übersicht: [slideshare id=51535551&doc=oraclenosql-doag-datenbankkonferenzjuni2014-150812085524-lva1-app6891]
Englisch - mehr für Entwickler [slideshare id=51535426&doc=oraclenosql-twjug-oktober2014taiwanprintv01-150812085112-lva1-app6892]
Die Merkmale der Oracle NoSQL Datenbank:
Die Oracle NoSQL DB hat in Replikationskonzept umgesetzt und der Store (entspricht im Denkansatz der RDBMS einer kompletten Datenbank) wird über möglichst viele Server, den Storage Nodes (SN) verteilt. Auf jedem der Storage Nodes ist ein zentraler Prozess gestartet, der Storage Node Agent SNA. Der SNA übernimmt eine zentrale Rolle, er überwacht den jeweiligen Storage Node und liefert wichtige Informationen an den Admin Service, der den Store verwaltet. Der Admin Service besteht wiederum aus einer kleinen Datenbank (entspricht im Prinzip dem System Tablespace mit dem Data Dictionary einer RDBMS) und dient zur Überwachung und Konfiguration des Stores. Damit bei einem Ausfall dieser zentrale Komponente redundant zur Verfügung steht, kann der Admin Service über mehrere SN gespiegelt werden.
Aufbau eines NoSQL Stores – Beispiel mit 3 Storage Nodes (SN) auf je einem Server und Replikation Faktor 3 = drei Replication Groups (Rg) in einer Zone mit dreifach gespiegelten Admin Service für die Verwaltung
In der Architektur des Oracle NoSQL Stores nimmt der Client Treiber die zentrale Rolle ein.
Die gesamte Logik der Datenverteilung über den Store und das Transaktionsverhalten wird auf der Client Seite umgesetzt.
Die Verteilung der Daten auf die Partitionen des Stores erfolgt durch die Keys (der Schlüssel auf die Daten).
Der Client Treiber kennt die Struktur des Stores und ermittelt über einen MD5 Hash auf den Key den passen Master für den Datensatz
und überträgt die Daten zum Schreiben auf den Storage Node, der den Master mit der entsprechenden Partition hält.
Hashing und Partitionierung der Daten der Oracle NoSQL Datenbank
Die Daten werden binär im Store abgelegt, der Zugriff erfolgt ausschließlich über den Schlüssel.
Beim Lesen kann aber der Client vom Master und allen Replikaten die Daten erhalten, dies optimiert entscheidend die Performance.
* Auf dem Key-Value Store die Durability und Consistency - das Transaktionelles Verhalten - einstellen
Unter der Oracle NoSQL ist die Java Version der Oracle Berkeley Datenbank im Einsatz. Ein sehr bedeutender Unterschied zum gewohnten Verhalten des RRDBMS System stellt dabei das Logverhalten der Berkeley DB dar. Die Oracle NoSQL unterscheidet nicht zwischen einen Online Redo Log und den eigentlichen Datendateien. Auch existiert kein Undo Tablespace für die „Before Images“ eines Datensatzes. Alles wird über die Datendateien abgewickelt. Jede Aktion auf den Daten führt zu einem Eintrag in die Datendateien, auch das Löschen! Das führt dazu, dass die Datenbank im ersten Schritt scheinbar immer größer wird. Erst wenn bestimmte Schwellwerte erreicht werden, wird im Hintergrund ein „Cleaner Thread“ gestartet, der die Datendateien optimiert.
* Daten Wachstum und Transaktionslog Verhalten Oracle NoSQL 11gR2
Erfreulicher Weise hat sich Oracle entschieden, den Hauptteil der Software als CC (Community Edition - Lizensiert nach der “GNU AFFERO GENERAL PUBLIC LICENSE“) zur relativ freien Verwendung zu lizensieren. Sollen erweitere Sicherheitsfeatures, wie Oracle Wallet oder eine Integration mit „External“ Table in die RDBMS umgesetzt werden, muss aber die Enterprise Edition gewählt werden.
Beim Anlegen des Stores definiert der Administrator mit dem Replikationsfaktor, wie viele Kopien von einem Master über alle verfügbaren Knoten bzw. Storage Nodes verteilt werden sollen.
Zum Beispiel bedeutet dies bei einem Replication Faktor von drei das ein Master und zwei Replica in einer Replication Group (Rg) verwaltet werden.
Auf den verfügbaren Storage Nodes werden drei Replikation Nodes für diese Gruppe angelegt, möglichst je auf einem separaten Server.
Jeder Storage Node besteht damit einem oder mehreren Replikation Nodes, die in einem sogenannten „Shared“ organsiert sind.
Ebenfalls beim Anlegen des Stores definiert der Administrator die Anzahl der Partitionen, in die der Store unterteilt wird.
Jeder Replication Group (Rg) wird die gleiche Anzahl an Partitionen zugeordnet und diese werden damit über mehrere Storage Nodes (SN) mit einem Master / Slave Konzept repliziert.
Ein wichtiger Punkt für die Performance einer Oracle NoSQL Umgebung ist das Netzwerk. Wird auf höchste Performance Wert gelegt, lohnt sich durchaus der Einsatz von InfiniBand für die Kommunikation der Knoten untereinander. Jeder Datensatz muss schnellstmöglich auf die Replikate übertragen werden um das Zeitfenster der „Eventual Consistency“ möglichst klein zu halten.
Eine exakte gleiche Systemzeit aller Knoten des Store ist sehr wichtig, der NTP Service auf jeden Knoten ist mit größter Sorgfalt einzurichten um Ausfälle im Store zu vermeiden, bzgl. Ntp siehe dazu auch Die Uhrzeit im Oracle Cluster überwachen/prüfen und kontrollieren
Die Oracle NoSQL DB benötigt für die Kommunikation der Storage Nodes untereinander und mit Client eine recht hohe Anzahl von Ports. Soll vor der NoSQL DB Umgebung ein FW für erweiterte Sicherheit sorgen, ist darauf zu achten eine Portrange auch für die Client Kommunikation zu reservieren (Parameter servicePortRange beim Anlegen des Stores) damit auch die für die RMI Kommunikation notwendigen Ports zwischen Client und DB Knoten in der FW freigeschaltet werden können. Ist mehr als ein Store in Verwendung, empfiehlt es sich diese Portranges zu standardisiert um die Wartung und den Betrieb erheblich zu erleichtern.
Neben der Definition einheitlicher Portranges für die Umgebungen sollte auch ein Namenskonzept für den Store nicht fehlen, um diese eindeutig zu unterscheiden.
Für die Administration und Überwachung des Stores steht eine Admin Konsole und eine Art erstes einfaches SQL*Plus zur Verfügung. Eine einfache, leider in der Version 2 nicht Passwort geschützte, Weboberfläche erlaubt es, den Status des Stores remote per Browser abzufragen. Im Detail lässt sich das Laufzeitverhalten der Store Node im Store mit JMX überwachen, zum Beispiel mit Java Mission Control. Schnell zeigt es sich aber, dass eigene Skripte zur Verwaltung notwendig werden, besonders wenn die Zahl der Store Nodes recht hoch wird.
Oft wird in der NoSQL Welt das Thema Backup sehr stiefmütterlich behandelt, mit der Begründung „bei genügend Server Knoten kann ja bei einem Ausfall nichts passieren“, das Problem mit logischen Fehlern wird kaum beachtet. Mit der Oracle NoSQL aber lassen sich Snapshots des gesamten Stores erzeugen. Auf Basis dieser über alle Knoten konsistenten Snapshots kann ein echtes Backup Konzept realisierbar wird. Die Daten in einem Snapshot können auch in einen anderen Store wieder importiert werden, zum Bespiel um eine Testumgebung aus den Produktionsdaten aufzusetzen.
Wird ein Admin Port definiert kann im Browser die Admin Console im Browser (Standard Port 5001) geöffnet werden.
Aufruf über den Browser mit http://localhost:5001/:
Leider nicht Passwort geschützt!
Die Jetty Version in der v3.2.5 ist zum Glück recht alt (Version 7.4.0), daher nicht vom dem Jetty Security Bug betroffen ⇒ siehe JetLeak Vulnerability: Remote Leakage of Shared Buffers in Jetty Web Server - CVE-2015-2080 .
Ab der EE Version 3 seht unter dem lib Verzeichnis ein Plugin für den Oracle EM Manager zur Verfügung (12.1.0.9.0_oracle.nosql.snab_2000_0.opar).
Für die CC kann auch ein eigenes Plugin entwicklet werden, siehe Plug-In Development mit dem Oracle Enterprise Manager 12c
Erst ab der Version 3 erfüllt auch die Oracle NoSQL DB grundlegende Sicherheitsanforderungen.
In den vorgehenden Versionen waren die Netzwerkadministration und der Entwickler in der vollen Verantwortung.
Ab der Version 3 kann das Datenprotokoll verschlüsselt werden und eine Benutzerverwaltung lässt sich in Grundzügen realisieren.
New Features: http://docs.oracle.com/cd/NOSQL/html/changelog.html
Besondere Merkmale:
Neues Utiltiy „diagnostics“
java -jar kvstore.jar diagnostics diagnostics-> help Oracle NoSQL Database Diagnostic Utility Commands: setup collect exit help
New Feature ⇒ http://docs.oracle.com/cd/NOSQL/html/changelog.html
Auszug aus den neuen Features:
Eine eigentliche SQL Syntax steht für das Arbeiten mit dem Store zurzeit nicht zur Verfügung.
Das Auslesen der Daten erfolgt mit PUT und GET Methoden des JAVA oder C APIs.
Eine Art SQL*Plus für die NoSQL DB:
Folgende Programmiersprachen werden ebenfalls neben Java für das Ansprechen der Datenbank unterstützt:
Da hier Java im Spiel ist, können je nach eingesetzt JVM wohl so einiges an Unterschieden ergeben.
Alternative JVM Lösungen: