Benutzer-Werkzeuge

Webseiten-Werkzeuge


nosql:oracle_nosql_database_einfuehrung

Die Oracle NoSQL Database - Ein Key Value Store

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:

  • Key-Value Store
    • Key besteht aus zwei Komponenten - den Major und Minor Keys
  • Large Object LOB Support
  • Basiert auf der Oracle Berkeley DB
  • Partitionskonzept - Mayor Keys in derselben Partition
  • CRUD Support - Create/Read/Update/Delete
    • Consistency und Durabilität kann durch Parameter gesteuert werden
  • Kann Transaktionen unterstützen
  • HA Funktionalität über Replikate
  • Seit Version 2 Schema Definition über Avro Schema möglich
    • JSON Format für die Schema Definition
  • Mit der Version 3 Unterstützung für ein Tabellen Konzept und sekundäre Indexe.
  • Hadoop Integration
  • Java und C API ( C API nur in der EE!)
  • Oracle Database Integration via External Tables (EE Only)
  • In der Version 2 kein Sicherheitsmodell für Authentifizierung, Identität des Clients und verschlüsselte Datenbank Übertragung

Architektur

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 Oracle NoSQL StoresAufbau 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 DatenbankHashing 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

Lizenzierung

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.

Installation

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.

Netzwerk

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.

Betrieb und Wartung

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.

Die Web Oberfläche

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/:

Admin Übersicht Oracle NoSQL

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 .

Oracle Enterprise Manager Integration

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

Sicherheit

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.

Update

Version 2

Version 3

Log Files in der V3 einsammeln

Neues Utiltiy „diagnostics“

java -jar kvstore.jar diagnostics
 
diagnostics-> help
Oracle NoSQL Database Diagnostic Utility Commands:
        setup
        collect
        exit
        help

Version 4

New Feature ⇒ http://docs.oracle.com/cd/NOSQL/html/changelog.html

Auszug aus den neuen Features:

  • Time To Live (TTL) on an individual table row
  • SQL-like declarative query language, called ONQL
  • Export/Import utility.

Entwicklung

Eine Testversion starten

Daten abfragen und einfügen

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:

Integration in die Oracle 11g Datenbank

Integration in Apache Hadopp

Last Test und Performance Tuning

Da hier Java im Spiel ist, können je nach eingesetzt JVM wohl so einiges an Unterschieden ergeben.

Alternative JVM Lösungen:

Weitere Key Values Stores

Quellen Oracle NoSQL

Oracle

Oracle Deutschland
Oracle NoSQL
Oracle Berkeley DB

Vorträge

Externe Tools/Schnittstellen etc.

Zorba
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
nosql/oracle_nosql_database_einfuehrung.txt · Zuletzt geändert: 2016/07/07 20:43 von gpipperr

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki