Seite 1Gunther Pippèrr © 2014 http://www.pipperr.de
ORACLE NOSQL - EINE ALTERNATIVE
FÜR DIE TRADITIONELLE DATENBANK?
Nur e...
Seite 2Gunther Pippèrr © 2014 http://www.pipperr.de
Grundlagen - Konzept
Was heißt hier ohne SQL?
Wieviel Struktur müssen ...
Seite 3Gunther Pippèrr © 2014 http://www.pipperr.de
Für jedes Problem das richtige Werkzeug
 NoSQL
– Mehr ein Denkansatz ...
Seite 4Gunther Pippèrr © 2014 http://www.pipperr.de
Brewer's CAP Theorem für verteilte Systeme
 Es ist nicht möglich alle...
Seite 5Gunther Pippèrr © 2014 http://www.pipperr.de
NOSQL – Definition
 Eine reine NoSQL Datenbank ist:
– Nicht relationa...
Seite 6Gunther Pippèrr © 2014 http://www.pipperr.de
Einordnung der Oracle NoSQL in die NoSQL Welt
 Key-Value
– Ein Schlüs...
Seite 7Gunther Pippèrr © 2014 http://www.pipperr.de
Idee Key-Value Store Database
– Oracle NoSQL – ein Key Value Store
• E...
Seite 8Gunther Pippèrr © 2014 http://www.pipperr.de
Das Mayor –Minor Key Konzept
 Key – Zusammengesetzt aus zwei Komponen...
Seite 9Gunther Pippèrr © 2014 http://www.pipperr.de
Implementierung
 Key = Hash Mayor Key => Partition Mapping
– Beim Anl...
Seite 10Gunther Pippèrr © 2014 http://www.pipperr.de
Evolution von Key-Value über Avro zur Tabelle
 Release 1 – Key Value...
Seite 11Gunther Pippèrr © 2014 http://www.pipperr.de
Abfrage auf den Store
 Die Abfragen erfolgen über die Java API
– Alt...
Seite 12Gunther Pippèrr © 2014 http://www.pipperr.de
Varianten / Versionen der Oracle NoSQL
 CC – Community Edition
– Sou...
Seite 13Gunther Pippèrr © 2014 http://www.pipperr.de
Einsatz Szenarien
Für was kann das jetzt alles nun
verwendet werden?
Seite 14Gunther Pippèrr © 2014 http://www.pipperr.de
Einsatz Möglichkeiten
 Einsatzgebiete
– Personalisierung von Webseit...
Seite 15Gunther Pippèrr © 2014 http://www.pipperr.de
Praxis Beispiel: Web Applikation
 In einer Web Applikation gibt es p...
Seite 16Gunther Pippèrr © 2014 http://www.pipperr.de
Welche Einsatz Strategie propagiert Oracle?
 Vorverarbeitung von Dat...
Seite 17Gunther Pippèrr © 2014 http://www.pipperr.de
Integration in das Hadoop Ökosystem
 Hadoop - Verteiltes Cluster Fil...
Seite 18Gunther Pippèrr © 2014 http://www.pipperr.de
Integration in das Hadoop Ökosystem
Hadoop MapAndReduce Daten aus dem...
Seite 19Gunther Pippèrr © 2014 http://www.pipperr.de
Die Architektur der Oracle
NoSQL Lösung im Detail
Ein verteilter Key-...
Seite 20Gunther Pippèrr © 2014 http://www.pipperr.de
Der Store – Die Datenbank
 Store – der gesamte Speicherverbund über ...
Seite 21Gunther Pippèrr © 2014 http://www.pipperr.de
Übersicht über den Aufbau eines Stores
 Je nach eingestellten Replik...
Seite 22Gunther Pippèrr © 2014 http://www.pipperr.de
Die Verteilung der Daten im Store
 Die Client API hashed jeden Schlü...
Seite 23Gunther Pippèrr © 2014 http://www.pipperr.de
Die Verteilung der Daten im Store
 Das Lesen kann von jeden Replikat...
Seite 24Gunther Pippèrr © 2014 http://www.pipperr.de
Konsistenz der Daten – Transaktionalität
 Innerhalb einer Session
Tr...
Seite 25Gunther Pippèrr © 2014 http://www.pipperr.de
Die Schreib Konsistenz im Store - Durability
 Der Entwickler ist ver...
Seite 26Gunther Pippèrr © 2014 http://www.pipperr.de
Durability Policies
 Commit-Policy für Master und Replikate
– SyncPo...
Seite 27Gunther Pippèrr © 2014 http://www.pipperr.de
Die Lese Konsistenz im Store - Consistency
 Der Entwickler ist veran...
Seite 28Gunther Pippèrr © 2014 http://www.pipperr.de
Consistency
 Consistency.ABSOLUTE
– Es darf nur vom Master gelesen w...
Seite 29Gunther Pippèrr © 2014 http://www.pipperr.de
Interne Verwaltung
 Admin Service für die interne Verwaltung
– Eigen...
Seite 30Gunther Pippèrr © 2014 http://www.pipperr.de
Verfügbarkeit
 Was passiert beim Ausfall eines Storage Nodes?
– Mast...
Seite 31Gunther Pippèrr © 2014 http://www.pipperr.de
Der Motor unter dem Ganzen (1)
 Die Java Version der Berkeley DB
– J...
Seite 32Gunther Pippèrr © 2014 http://www.pipperr.de
Der Motor unter dem Ganzen (2)
 Besonderheit der Berkeley DB:
• Redo...
Seite 33Gunther Pippèrr © 2014 http://www.pipperr.de
Beispiel für das Auslesen der Datendateien
 Mit dem Berkeley Klassen...
Seite 34Gunther Pippèrr © 2014 http://www.pipperr.de
Installation
Java entpacken, Verzeichnisse anlegen
fertig?
Seite 35Gunther Pippèrr © 2014 http://www.pipperr.de
Planung einer NoSQL Installation - Netzwerk
 Netzwerk Infrastruktur
...
Seite 36Gunther Pippèrr © 2014 http://www.pipperr.de
Planung einer NoSQL Installation - Ports
 Notwendige Ports - Netzwer...
Seite 37Gunther Pippèrr © 2014 http://www.pipperr.de
Oracle NoSQL Client Connect
 Zugriff vom Client auf den „registry po...
Seite 38Gunther Pippèrr © 2014 http://www.pipperr.de
Planung einer NoSQL Installation - Hardware
 CPU und Speicher
– Cach...
Seite 39Gunther Pippèrr © 2014 http://www.pipperr.de
Planung einer NoSQL Installation - Speicherplatz
 Speicherplatz
– Be...
Seite 40Gunther Pippèrr © 2014 http://www.pipperr.de
Installation
 Vorbereitung auf jeden Knoten
– Java JDK installieren ...
Seite 41Gunther Pippèrr © 2014 http://www.pipperr.de
Mit dem NoSQL Store arbeiten
Wartung und Betrieb
Seite 42Gunther Pippèrr © 2014 http://www.pipperr.de
Verwaltung (1) – Kommando Zeile
 Kv - Für die Store Administration
...
Seite 43Gunther Pippèrr © 2014 http://www.pipperr.de
Verwaltung (2) – Webinterface
– Weboberfläche wird durch einen mit ge...
Seite 44Gunther Pippèrr © 2014 http://www.pipperr.de
JMX Oberfläche
 JMC starten – Java Mission Control
– JAVA_HOME/bin/j...
Seite 46Gunther Pippèrr © 2014 http://www.pipperr.de
Ausfallsicherheit
Verfügbarkeit und Backup
Seite 47Gunther Pippèrr © 2014 http://www.pipperr.de
Backup per Snapshot möglich
 Backup:
– Ein kompletter Store kann per...
Seite 48Gunther Pippèrr © 2014 http://www.pipperr.de
Performance
I/O und Netzwerk
Seite 49Gunther Pippèrr © 2014 http://www.pipperr.de
Performance Überlegungen
 Lesen
– Netzwerk
• alle Datensätze müssen ...
Seite 50Gunther Pippèrr © 2014 http://www.pipperr.de
Sicherheit?
Oracle NoSQL und Daten Sicherheit?
Seite 51Gunther Pippèrr © 2014 http://www.pipperr.de
Sicherheit?
 In Version 2 ?
 Darum kümmert sich der Netzwerk Admin ...
Seite 52Gunther Pippèrr © 2014 http://www.pipperr.de
In Java den Store ansprechen
Abfragen werden mit Java erstellen
Seite 53Gunther Pippèrr © 2014 http://www.pipperr.de
Verbindung zum Store in Java aufbauen
 Connection zu Store herstelle...
Seite 54Gunther Pippèrr © 2014 http://www.pipperr.de
Mit Java Daten einfügen und auslesen
 Entwickler spricht die DB Obje...
Seite 55Gunther Pippèrr © 2014 http://www.pipperr.de
Fazit
Lohnt sich der Aufwand?
Seite 56Gunther Pippèrr © 2014 http://www.pipperr.de
Warum die Oracle NoSQL wählen? (1)
 Was ist für eine strategische En...
Seite 57Gunther Pippèrr © 2014 http://www.pipperr.de
Warum die Oracle NoSQL wählen? (2)
 Was ist für eine strategische En...
Seite 58Gunther Pippèrr © 2014 http://www.pipperr.de
Die Architektur im direkten Vergleich (1)
Seite 59Gunther Pippèrr © 2014 http://www.pipperr.de
Die Architektur im direkten Vergleich (2)
Client
Process
Store Node A...
Seite 60Gunther Pippèrr © 2014 http://www.pipperr.de
Der direkte Vergleich Oracle RDBMS NoSQL
 ~35 Jahre Entwicklung
 M...
Seite 61Gunther Pippèrr © 2014 http://www.pipperr.de
Fragen
Oracle NoSQL
NO:SQL
Seite 62Gunther Pippèrr © 2014 http://www.pipperr.de
Quellen
 Oracle - ORACLE DOJO NR 2
– Siehe
http://www.oracle.com/web...
Seite 63Gunther Pippèrr © 2014 http://www.pipperr.de
Gunther Pippèrr - IT-Architekt - Berater
• High-Tech
• Real Estate
• ...
Nächste SlideShare
Wird geladen in …5
×

Oracle no sql-doag-datenbank_konferenz_juni_2014

715 Aufrufe

Veröffentlicht am

Oracle NoSQL DOAG Datenbank Konferenz 2014 - Düsseldorf, Dienstag, 03.Juni 2014

Oracle NoSQL - Eine Alternative für die traditionelle Datenbank?

Ein neues Mitglied in der Oracle Datenbank Familien

Nur ein Hype oder die Zukunft? Wird es ein miteinander geben?

Die Oracle NoSQL Datenbank bietet als klassischer Key-Value Store über verteilte Knoten Ausfallsicherheit und Performance für die Verarbeitungen von Massendaten. Im Gegensatz zum Schweizer Taschenmesser für viele Problem, dem Oracle DB RDBMS, ist die Oracle NoSQL mehr ein Präzisionswerkzeug für genau eine gezielte Aufgabe. Um die NoSQL Datenbank im Vergleich zum großen Oracle RDBMS System besser einschätzen zu können, wird der prinzipielle Aufbau der Oracle NoSQL dargestellt um die Vorteile dieser Architektur gegen den traditionellen RDBMS Ansatz aufzuzeigen.

Das NoSQL Konzept und wo kann hier die Oracle NoSQL eingeordnet

Begriff NoSQL kann inzwischen mehr als ein Denkansatz zur Datenverwaltung und Verarbeitung als eine spezielle Technologie definiert werden. Gemeinsam ist den verschiedenen Implementierungen auf dem Markt aber meist der Versuch eine hohe Skalierbarkeit durch massive Parallelisierung über viele Rechnerknoten zu erreichen. Die Oracle NoSQL Datenbank ist dabei ein Vertreter der Key-Value Store Datenbanken. Auf Basis der soliden Berkeley DB Java Edition hat Oracle die bestehenden Replikations- Mechanismen der Berkeley DB optimiert und damit eine neue Datenbank, die Oracle NoSQL entwickelt. Die Oracle NoSQL Datenbank folgt dem aktuellen Trend, moderne Datenbank mehr mit dem CAP / Base Ansatz umzusetzen, als das traditionelle ACID einer Relationale Datenbanken erneut zu implementieren.

Veröffentlicht in: Daten & Analysen
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
715
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
130
Aktionen
Geteilt
0
Downloads
5
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Oracle no sql-doag-datenbank_konferenz_juni_2014

  1. 1. Seite 1Gunther Pippèrr © 2014 http://www.pipperr.de ORACLE NOSQL - EINE ALTERNATIVE FÜR DIE TRADITIONELLE DATENBANK? Nur ein Hype oder die Zukunft? Wird es ein miteinander geben? DOAG 2014 Datenbank
  2. 2. Seite 2Gunther Pippèrr © 2014 http://www.pipperr.de Grundlagen - Konzept Was heißt hier ohne SQL? Wieviel Struktur müssen meine Daten haben?
  3. 3. Seite 3Gunther Pippèrr © 2014 http://www.pipperr.de Für jedes Problem das richtige Werkzeug  NoSQL – Mehr ein Denkansatz zur Datenverwaltung und Verarbeitung als eine spezielle Technologie – Grundkonzept • Verteilte ,skalierbare Lösungen (Scale-out Konzept) • CAP Theorem – Consistency – Availability - Partition Tolerance • BASE - Basically Availible, Soft-state, Eventually versus ACID – Atomicity, Consistency, Isolation, Durability – Hochspezialisierte Lösungen für meist exakt ein großes Problem beim Handling von sehr großen, sehr gut verfügbaren oder sehr schnell benötigten Daten • Dutzende von Lösungsansätzen im Markt verfügbar
  4. 4. Seite 4Gunther Pippèrr © 2014 http://www.pipperr.de Brewer's CAP Theorem für verteilte Systeme  Es ist nicht möglich alle Anforderungen zugleich zu erfüllen! Consistency AvailabilityPartition Tolerance Every operation must terminate in an intended response. The client perceives that a set of operations has occurred all at once. (Atomic) Operations will complete, even if individual components are unavailable. See: http://www.julianbrowne.com/article/viewer/brewers-cap-theorem Nur je zwei Eigenschaften können garantiert werden Die Oracle RDBMS Architektur erfüllt: Consistency und Availabitlity - Konsistenz und Verfügbarkeit sind garantiert Die Oracle NoSQL DB Architektur kann : Consistency und Availabitlity Oder Availabitlity und Partition Tolerance - Ziel ist es ein verteiltes Systeme zu realisieren
  5. 5. Seite 5Gunther Pippèrr © 2014 http://www.pipperr.de NOSQL – Definition  Eine reine NoSQL Datenbank ist: – Nicht relational – Schema frei – Meist eine distributed multi-node Architektur • Ziel: eine Shared Nothing Cluster Lösung – Einfacher Replikations Mechanismus – Eine einfache API ( Not only SQL = NoSQL) – Nicht unbedingt ein ACID Consistency Model – Open Source Aber – der große Nachteil zur Zeit => Meist keine einfache Abfragesprache => Komplexe Joins nicht so einfach implementiert
  6. 6. Seite 6Gunther Pippèrr © 2014 http://www.pipperr.de Einordnung der Oracle NoSQL in die NoSQL Welt  Key-Value – Ein Schlüssel zeigt einen auf einen Satz von Daten • Oracle  Document oriented – Alle Daten liegen in einem Dokument vor • Lotus Notes  Graph – Vernetzte Strukturen • Neo4J http://de.wikipedia.org/wiki/NoSQL
  7. 7. Seite 7Gunther Pippèrr © 2014 http://www.pipperr.de Idee Key-Value Store Database – Oracle NoSQL – ein Key Value Store • Eine verteilte und skalierbare hoch verfügbare Datenbank • Consistent Hashing Ansatz Key Value Key Value Key Value Key Value Datastore über verschiedene Nodes Intelligenter Treiber • Implementiert den Hash Mechanismus • Kennt den Status des Stores • Bei Ersten Connect wird die Partition Map gelesen Client Software Key Value Key Value Key Value Key Value Key Value Key Value Key Value Key Value Eine ACID Transaktion ist für alle Rekords unter einem Mayor Key als ein Single API Aufruf möglich.
  8. 8. Seite 8Gunther Pippèrr © 2014 http://www.pipperr.de Das Mayor –Minor Key Konzept  Key – Zusammengesetzt aus zwei Komponenten Daten Schlüssel Mayor Minor String Byte Array Partitionierung über den Mayor Key Beispiel: Maschinen Identifier Hersteller Konfiguration Typ | Baujahr | Modell Standort| Einstellung A| Einstellung B Die Struktur der Daten ist NICHT selbstbeschreibend!
  9. 9. Seite 9Gunther Pippèrr © 2014 http://www.pipperr.de Implementierung  Key = Hash Mayor Key => Partition Mapping – Beim Anlegen wird eine feste Anzahl von Partitionen über den Store angelegt • Jede Partition entspricht im Prinzip einer eigenen Berkeley DB „Datenbank“ • Der Hash vom Key bestimmt die Partition • Die Partitionen werden über den Store redundant gehalten Client Driver : Hashing der ID Store über n Storage Nodes Partition 1 Partition 2 Partition 3 Partition … Partition N Replication Group Replication Group Replication Group MD5(major key) % n Partitions →Partition ID Replication Group = Master + Replikate
  10. 10. Seite 10Gunther Pippèrr © 2014 http://www.pipperr.de Evolution von Key-Value über Avro zur Tabelle  Release 1 – Key Value – Reines Key-Value Konzept – Kein „Data Dictionary“ – Gesamte Logik in der Applikation  Release 2 – Avro – Schema Definition mit dem Apache Avro Standard – Eine Struktur Definition der Key-Value Daten wird der Applikation "bekannt" gegeben und in der DB hinterlegt  Release 3 – Tabellen – Struktur Definitionen als Tabellen • Sekundärer Index auf Spalten der Tabelle möglich Value
  11. 11. Seite 11Gunther Pippèrr © 2014 http://www.pipperr.de Abfrage auf den Store  Die Abfragen erfolgen über die Java API – Alternativ auch ein C API Verfügbar – Für Wartungsarbeiten steht eine Art SQL*plus zur Verfügung  Der Key und NUR der Key kann abgefragt werden – Für die Suche in den Values muss der gesamte Datenbestand gelesen werden – Für einen Count wird über alle Keys einfach einer nach den anderen gezählt
  12. 12. Seite 12Gunther Pippèrr © 2014 http://www.pipperr.de Varianten / Versionen der Oracle NoSQL  CC – Community Edition – Source Code liegt offen • Open Source mit einer GNU Affero General Public License – Support auf jährlicher Basis möglich  EE – Enterprise Edition – Vollständiger Support – Oracle External Tables Unterstützung - Austausch von Daten mit „normaler“ Datenbank – Oracle Event Processing – RDF Adapter – SNMP Monitoring – Jena Adapter (Graph/SPARQL) – Ab Version 3 Security Optionen mit Oracle Wallet
  13. 13. Seite 13Gunther Pippèrr © 2014 http://www.pipperr.de Einsatz Szenarien Für was kann das jetzt alles nun verwendet werden?
  14. 14. Seite 14Gunther Pippèrr © 2014 http://www.pipperr.de Einsatz Möglichkeiten  Einsatzgebiete – Personalisierung von Webseiten – Authentifizierung – Stream Processing • Maschinendaten Ziel: Für EINEN Schlüssel Wert SCHNELL die Ergebnisse erhalten Anforderung: Große Datenmengen mit geringer Latenz bereitstellen - Persistenter Cache
  15. 15. Seite 15Gunther Pippèrr © 2014 http://www.pipperr.de Praxis Beispiel: Web Applikation  In einer Web Applikation gibt es pro Anwender eine sehr hohe Anzahl unterschiedlicher „Bonus Angebote, Gutscheine“, die individuell je nach Profile eines Anwender wöchentliche ermittelt werden – NoSQL Store hält über die UserID als Schlüssel eine Liste mit allen Metainformationen • Komplexe Joins über das DWH werden damit vermieden • Sofortige Anzeige auf dem SmartPhone oder im Web ohne Zeitverzögerung durch sehr niedrige Latenzen Anforderung: Große Datenmengen mit geringer Latenz bereitstellen - Persistenter Cache
  16. 16. Seite 16Gunther Pippèrr © 2014 http://www.pipperr.de Welche Einsatz Strategie propagiert Oracle?  Vorverarbeitung von Daten mit Oracle NoSQL und Hadoop - Klassische Auswertung mit der Oracle RDBMS Datenbank sammeln veredlen auswerten Ein Key-Value Store zum Sammeln unstrukturiert Daten?
  17. 17. Seite 17Gunther Pippèrr © 2014 http://www.pipperr.de Integration in das Hadoop Ökosystem  Hadoop - Verteiltes Cluster File System – Container für verschiedene Datenbank Lösungen • Andere Datenbanken wie RainStore oder HIVE nützen Hadoop als Dateisystem  Hadoop - MapAndReduce Framework – Framework für Abfragen
  18. 18. Seite 18Gunther Pippèrr © 2014 http://www.pipperr.de Integration in das Hadoop Ökosystem Hadoop MapAndReduce Daten aus dem NoSQL Store lesen Hadoop Filesystem Ergebnisse ablegen 11g 12c Als External Table lesen Pur Java Hive Als External Table lesen Nur EE Edition der Oracle NoSQL!
  19. 19. Seite 19Gunther Pippèrr © 2014 http://www.pipperr.de Die Architektur der Oracle NoSQL Lösung im Detail Ein verteilter Key-Value Store
  20. 20. Seite 20Gunther Pippèrr © 2014 http://www.pipperr.de Der Store – Die Datenbank  Store – der gesamte Speicherverbund über n Storage Nodes Server 1 Storage Node 1 Server 2 Storage Node 2 Server 4 Storage Node 4 Server 3 Storage Node 3 Beispiel für einen Store mit Replikation Faktor 3 1 1 13332 2 24 44 Master 1 Replikat sn1 Replikat sn1 Der Replikationsfaktor ist definiert als „Master + Anzahl der Replikate“. In unsere Beispiel ein Master und zwei Replikate = Replikationsfaktor 3 Zone = Eine Store node Umgebung – Kann auch repliziert werden Master Master Master Replication Group = Master + Replikate Shared A Shared D Zone
  21. 21. Seite 21Gunther Pippèrr © 2014 http://www.pipperr.de Übersicht über den Aufbau eines Stores  Je nach eingestellten Replikationsfaktor werden die Daten über den Store mehrfach gespeichert  Die Anzahl der eingestellten Partition wird über die Master Knoten verteilt  Eine Topologie beschreibt den kompletten Store  Beispiel – 4 Knoten - Replikationsfaktor 3 – 800 Partitionen – Ein Master pro Knoten + zwei Replikate pro Storage Node – Die 800 Partitionen werden über die 4 Master verteilt • 200 je Master – Die Daten werden über den Master Node eingefügt • Der Master Node verteilt die Daten an die Replikate – Die Daten können von jedem Knoten gelesen werden Die Anzahl der Partition können nachträglich nicht mehr geändert werden!
  22. 22. Seite 22Gunther Pippèrr © 2014 http://www.pipperr.de Die Verteilung der Daten im Store  Die Client API hashed jeden Schlüssel und verteilt die Schlüssel über die Anzahl der Partitionen Java Code Java API Schlüssel Aus dem Hash ergibt sich die Partition und damit der Master Knoten, der die entsprechende Partition hält. 7 B1A1 1 2 8 1 1 D1C1 9 1 0 1 2 88 B2B3 Einfügen
  23. 23. Seite 23Gunther Pippèrr © 2014 http://www.pipperr.de Die Verteilung der Daten im Store  Das Lesen kann von jeden Replikat erfolgen Java Code Java API Schlüssel Lesen 7 B1A1 1 2 8 1 1 D1C1 9 1 0 1 2 88 B2B3 Aus dem Hash ergibt sich die Partition und damit der Master Knoten, der die entsprechende Partition hält.
  24. 24. Seite 24Gunther Pippèrr © 2014 http://www.pipperr.de Konsistenz der Daten – Transaktionalität  Innerhalb einer Session Transaktionalität beim Schreiben möglich  Entwickler entscheidet wann ein Datensatz als geschrieben gilt Lesen  Entwickler entscheidet ob die gelesen Daten auch aktuell sein sollen Schreiben SchnellSicher Durability Consistency Performance Performance Aktuellste Version Erstbeste AntwortAuf allen Knoten auf Disk Auf einem Konten im Cache SchnellSicher
  25. 25. Seite 25Gunther Pippèrr © 2014 http://www.pipperr.de Die Schreib Konsistenz im Store - Durability  Der Entwickler ist verantwortlich für die Konsistenz beim Schreiben!  Wird beim Connect zum Store gesetzt – Klasse oracle.kv.Durability • Commit-Policy für den Master • Commit-Policy für die Replikate • Replica Acknowledgement-Policy SchnellSicher Performance Auf allen Knoten auf Disk Auf einem Konten im Cache
  26. 26. Seite 26Gunther Pippèrr © 2014 http://www.pipperr.de Durability Policies  Commit-Policy für Master und Replikate – SyncPolicy.SYNC • warten bis der Storage Node die Transaktion in die Logdatei geschrieben und diese auf Platte synchronisiert hat – SyncPolicy.WRITE_NO_SYNC • warten bis der Storage Node die Transaktion in die Logdatei im Cache geschrieben hat ( Nicht auf Platte geschrieben!) – SyncPolicy.NO_SYNC • Überhaupt nicht warten  Replica Acknowledgement – ReplicaAckPolicy.ALL • Warten bis alle Replikate bestätigt haben, dass die Transaktion geschrieben wurde – ReplicaAckPolicy.SIMPLE_MAJORITY • warten bis die einfache Mehrheit der Replikate die Transaktion bestätigt hat – ReplicaAckPolicy.NONE • Nicht auf die Replikate warten
  27. 27. Seite 27Gunther Pippèrr © 2014 http://www.pipperr.de Die Lese Konsistenz im Store - Consistency  Der Entwickler ist verantwortlich für die Lese Konsistenz!  Jedem Key Objekt besitzt auch eine Versionsinformation – Eine Art Transaktion ID  Verhalten wird beim Connect zum Store definiert – Lesen – Klasse oracle.kv.Consistency Performance Aktuellste Version Erstbeste Antwort SchnellSicher
  28. 28. Seite 28Gunther Pippèrr © 2014 http://www.pipperr.de Consistency  Consistency.ABSOLUTE – Es darf nur vom Master gelesen werden, damit ist sichergestellt, dass stets der aktuelle Inhalt gelesen wird  Consistency.Time – Das Lesen von einer Replika ist erlaubt – Parameter legen fest, wie „veraltet der zurückgelieferte Inhalt des Keys sein kann  Consistency.Version – Das Lesen von einer Replika ist erlaube – Versionsinformationen wird statt der Zeit verwendet, um zu erkennen ob der Datensatz veraltet ist  Consistency.NONE_REQUIRED – jedes Ergebnis wird gelesen und darf beliebig veraltet sein
  29. 29. Seite 29Gunther Pippèrr © 2014 http://www.pipperr.de Interne Verwaltung  Admin Service für die interne Verwaltung – Eigene Admin Datenbank – Eigener Port  Der Admin Service sorgt für die Umsetzung des Master – Slave Konzepts – Bei einem Ausfall eines Knoten neuen Master bestimmen
  30. 30. Seite 30Gunther Pippèrr © 2014 http://www.pipperr.de Verfügbarkeit  Was passiert beim Ausfall eines Storage Nodes? – Master evtl. nicht mehr verfügbar – es kann nichts mehr geschrieben werden? – Admin Prozess überwacht den gesamten Store • Besitzt eine eigene Admin Datenbank • Erkennt Fehler • Wählt aus den verbleibenden Replikaten den mit der höchsten LSN (log sequence number) zu einem neuen Master aus Hat der Entwickler sich für ReplicaAckPolicy.ALL entschieden, kommt es aber zu einer Fehlermeldung falls nicht alle Node verfügbar sind! Der Entwickler wählt aus: • Consistency und Availabitlity ODER • Availabitlity und Partition Tolerance
  31. 31. Seite 31Gunther Pippèrr © 2014 http://www.pipperr.de Der Motor unter dem Ganzen (1)  Die Java Version der Berkeley DB – JE Version 5.0.83 für die NoSQL 2.2.18 – JE Version 6.0.8 für die NoSQL 3.0.5 – Jede Partition ist eine Datenbank – Berkeley DB Replikation für das Master Slave Konzept – Die DB Dateien lassen sich sogar mit dem Berkeley DB Klassen analysieren Tipp: Die original Berkeley DB Mechanismen können pro Storage Node konfiguriert werden Siehe http://www.pipperr.de/dokuwiki/doku.php?id=nosql:log_file_verhalten_oracle_nosql_db_11gr2 Version anzeigen lassen mit java -classpath ".libkvclient.jar;.libkvstore.jar;.libje.jar" com.sleepycat.je.util.DbVerify -V
  32. 32. Seite 32Gunther Pippèrr © 2014 http://www.pipperr.de Der Motor unter dem Ganzen (2)  Besonderheit der Berkeley DB: • Redo Log Einträge und Daten werden in den selben „Daten“ Dateien verwaltet • Hintergrund Jobs sorgen für das Cleaning der unnötigen Einträge
  33. 33. Seite 33Gunther Pippèrr © 2014 http://www.pipperr.de Beispiel für das Auslesen der Datendateien  Mit dem Berkeley Klassen die DB Größe auslesen – Auf das richtige Einbinden der jar Files achten • export KVLIB=/opt/oracle/produkt/11.2.0/kv-2.1.8/lib • export KVCLASS=$KVLIB/kvclient.jar:$KVLIB/kvstore.jar:$KVLIB/je.jar – Pfad zu den Datendateien angeben • export JEENV=/opt/oracle/kvdata/GPIDB/sn1/rg1-rn1/env/ – Auswerten mit: java -classpath $KVCLASS com.sleepycat.je.util.DbSpace -h $JEENV File Size (KB) % Used -------- --------- ------ 00000000 110808 21 TOTALS 110808 21 (LN size correction factor: NaN)
  34. 34. Seite 34Gunther Pippèrr © 2014 http://www.pipperr.de Installation Java entpacken, Verzeichnisse anlegen fertig?
  35. 35. Seite 35Gunther Pippèrr © 2014 http://www.pipperr.de Planung einer NoSQL Installation - Netzwerk  Netzwerk Infrastruktur – Physik • Hoch performante interne Kommunikation zwischen den Knoten notwendig – Auf geringe Latenzen achten » Stichwort Infiband » Eigenes 10Gbit Netz einplanen? – TCP Ports definieren • Für die Kommunikation unter den Storage Nodes intern • Für Kommunikation des Clients mit dem Master Nodes – Ein Port von Außen notwendig + Ein Port für die Admin Console + ServicePortRange für die RMI Verbindung – Wartbarkeit • SSH zwischen den Storage Nodes ermöglichen – Skript gesteuerte Wartung über mehrere Knoten ermöglichen Durch die doch mit der Zeit hohe Anzahl von Server für Produktion / Staging / Test / Dev ist es ratsam vorab Standard zu definieren!
  36. 36. Seite 36Gunther Pippèrr © 2014 http://www.pipperr.de Planung einer NoSQL Installation - Ports  Notwendige Ports - Netzwerk Infrastruktur Ports für einen Storage Node 5000 Applikation Admin Client -port 5001 HTTP Admin Client -admin 5010-5020 Replikation -harange … -servicerange RMI Port für die Client Kommunikation 5021-5040 … Parameter beim Anlegen mit "makebootconfig" haPortRange servicePortRange Parameter für das Ändern mit "change-policy -params " registry portApplikation
  37. 37. Seite 37Gunther Pippèrr © 2014 http://www.pipperr.de Oracle NoSQL Client Connect  Zugriff vom Client auf den „registry port“ – Zum Beispiel Port 5000 auf Knoten A  Abfragen werden über das Java RMI Protokoll auf den jeweiligen Node durchgeführt – Ausreichend Remote Ports notwendig -servicerange -port Node A Node B Node C Client Port 5000 ServiceRange Port 5021 ServiceRange Port 5021 ServiceRange Port 5021 Firewall beachten!
  38. 38. Seite 38Gunther Pippèrr © 2014 http://www.pipperr.de Planung einer NoSQL Installation - Hardware  CPU und Speicher – Cache Größe kann von 2 bis n GB eingestellt werden • GC Effekte von Java im Auge behalten – Oracle NoSQL ist explicit auf sauber, kleine Objekte Größen optimiert um den Java Garbage Collecter nicht zu überfordern  Storage Infrastruktur – Auf einem Store Node können auch mehrere Master und Replikate betrieben werden • Auf je eigene und performante Physik der einzelnen Datenbereiche (KVROOT) achten – Neben dem reinen Einfügen und Lesen von Nutzdaten werden die DB Dateien von „Cleaner“ Prozessen bei Bedarf bereinigt
  39. 39. Seite 39Gunther Pippèrr © 2014 http://www.pipperr.de Planung einer NoSQL Installation - Speicherplatz  Speicherplatz – Berechnung nicht ganz trivial • Die Berkeley DB speichert ALLE Aktionen, Daten wie Redo Information in der selben Datei • Werden bestimmte Thresholds erreicht, werden diese Datendateien optimiert • Löschen von Daten vergrößert den Store im ersten Schritt! Faustregel: Pro Master/ Replikat => Anzahl Transaktionen (Insert/Update/Delete) * (Netto Daten Größe + Overhead) => Füllgrad der Datendateien wird per Default auf 40% optimiert
  40. 40. Seite 40Gunther Pippèrr © 2014 http://www.pipperr.de Installation  Vorbereitung auf jeden Knoten – Java JDK installieren und Store User anlegen – SSH Verbindung einrichten – KVROOT anlegen / einbinden ( Die Datenablage!)  Oracle NoSQL installieren – Code auspacken – KVHOME anlegen – Store Node Basis Verzeichnis (KVROOT) Boot Konfiguration anlegen – Admin Node starten – Plan für den neuen Store definieren • Die Datenbank Topologie definieren – Plan ausrollen – Testen Per Script: Aufwand : 5min
  41. 41. Seite 41Gunther Pippèrr © 2014 http://www.pipperr.de Mit dem NoSQL Store arbeiten Wartung und Betrieb
  42. 42. Seite 42Gunther Pippèrr © 2014 http://www.pipperr.de Verwaltung (1) – Kommando Zeile  Kv - Für die Store Administration  kvshell - Abfragen/Einfügen von Daten kvshell-> put -key "/Gunther/name" -value "Pipperr" Operation successful, record inserted. kvshell-> get -key "/Gunther/name" Pipperr
  43. 43. Seite 43Gunther Pippèrr © 2014 http://www.pipperr.de Verwaltung (2) – Webinterface – Weboberfläche wird durch einen mit gelieferten jetty Server zur Verfügung gestellt: http://nosqldb03:5005/
  44. 44. Seite 44Gunther Pippèrr © 2014 http://www.pipperr.de JMX Oberfläche  JMC starten – Java Mission Control – JAVA_HOME/bin/jmc.exe – Über den „registry port“ anmelden
  45. 45. Seite 46Gunther Pippèrr © 2014 http://www.pipperr.de Ausfallsicherheit Verfügbarkeit und Backup
  46. 46. Seite 47Gunther Pippèrr © 2014 http://www.pipperr.de Backup per Snapshot möglich  Backup: – Ein kompletter Store kann per Snapshot konsistent gesichert werden • Ausreichend Speicherplatz einplanen  Restore – Ein Store kann komplett zurück gesetzt werden • Store Snapshot erzeugen • Store stoppen • Snapshot zur Verfügung stellen (Links im Filesystem z.B.) • Store starten, Storage Nodes lesen die Daten, legen den die Daten wieder an und LÖSCHEN den Snapshot! – Eine Art Import • Die erzeugten Daten können in einen andern Store wieder eingelesen werden
  47. 47. Seite 48Gunther Pippèrr © 2014 http://www.pipperr.de Performance I/O und Netzwerk
  48. 48. Seite 49Gunther Pippèrr © 2014 http://www.pipperr.de Performance Überlegungen  Lesen – Netzwerk • alle Datensätze müssen über das Netz gelesen werden!  Schreiben – I/O • Hintergrund Prozesse für die Datendatei Optimierung benötigen genügende Reserven ALLE Daten werden auf dem Client verarbeitet! Ein Einfaches Count(*) MUSS alle Daten lesen!
  49. 49. Seite 50Gunther Pippèrr © 2014 http://www.pipperr.de Sicherheit? Oracle NoSQL und Daten Sicherheit?
  50. 50. Seite 51Gunther Pippèrr © 2014 http://www.pipperr.de Sicherheit?  In Version 2 ?  Darum kümmert sich der Netzwerk Admin und der Entwickler  Ab Version 3 – SSL Verschlüsselung – Password Schutz • Wallet Verwendung EE Feature
  51. 51. Seite 52Gunther Pippèrr © 2014 http://www.pipperr.de In Java den Store ansprechen Abfragen werden mit Java erstellen
  52. 52. Seite 53Gunther Pippèrr © 2014 http://www.pipperr.de Verbindung zum Store in Java aufbauen  Connection zu Store herstellen • Store Eigenschaften setzen Node Port Store Name Regeln beim Lesen Regel beim Schreiben
  53. 53. Seite 54Gunther Pippèrr © 2014 http://www.pipperr.de Mit Java Daten einfügen und auslesen  Entwickler spricht die DB Objekte direkt über den Key an  Daten anlegen  Daten abfragen Es steht keine SQL Syntax zur Verfügung Schreiben Lesen
  54. 54. Seite 55Gunther Pippèrr © 2014 http://www.pipperr.de Fazit Lohnt sich der Aufwand?
  55. 55. Seite 56Gunther Pippèrr © 2014 http://www.pipperr.de Warum die Oracle NoSQL wählen? (1)  Was ist für eine strategische Entwicklung wirklich wichtig? – Wartbarkeit • Ist das Produkt bedienbar / administrierbar? – Langfristige Strategie des Herstellers • Kann ein Produktzyklus von 4-5 Jahren eingehalten werden? – Release und Update Problematik • Läuft die Software auch Java 8 und höher? Was ist mit Linux 7?
  56. 56. Seite 57Gunther Pippèrr © 2014 http://www.pipperr.de Warum die Oracle NoSQL wählen? (2)  Was ist für eine strategische Entwicklung wirklich wichtig? – Passt das Grundkonzept zu meiner technischen Anforderung? • Ändern sich meine Anforderungen mit der Zeit? – Kosten Oracle verspricht dies einzuhalten – Version 3 in Planung – Basis Software Berkeley DB seit Jahren stabil im Einsatz
  57. 57. Seite 58Gunther Pippèrr © 2014 http://www.pipperr.de Die Architektur im direkten Vergleich (1)
  58. 58. Seite 59Gunther Pippèrr © 2014 http://www.pipperr.de Die Architektur im direkten Vergleich (2) Client Process Store Node A Cache Cleaner Thread Redo-log und Daten in einer Datei(en) Admin Master Replikat(e) System Store Node B Cache Cleaner Thread Redo-log und Daten in einer Datei(en) Admin Master Replikat(e) System Store Node C Cache Cleaner Thread Redo-log und Daten in einer Datei(en) Admin Master Replikat(e) System Client API
  59. 59. Seite 60Gunther Pippèrr © 2014 http://www.pipperr.de Der direkte Vergleich Oracle RDBMS NoSQL  ~35 Jahre Entwicklung  Mächtige SQL API  Joins  Constraints  Viele Features  OLTP Einsatz  Shared Anything Ansatz  Generalisierte All zweck Waffe Oracle NoSQL  ~2-3 Jahre  Einfache Java API  Join nur über die Applikation  ?  Reine Datenhaltung  Lese Operationen überwiegen  Shared Nothing Cluster  Spezialisierte Nischen Lösung Oracle RDBMS
  60. 60. Seite 61Gunther Pippèrr © 2014 http://www.pipperr.de Fragen Oracle NoSQL NO:SQL
  61. 61. Seite 62Gunther Pippèrr © 2014 http://www.pipperr.de Quellen  Oracle - ORACLE DOJO NR 2 – Siehe http://www.oracle.com/webfolder/technetwork/de/community/dojo/index.ht ml  Mehr über das Thema siehe auch: – http://www.pipperr.de/dokuwiki/doku.php?id=nosql_datenbank
  62. 62. Seite 63Gunther Pippèrr © 2014 http://www.pipperr.de Gunther Pippèrr - IT-Architekt - Berater • High-Tech • Real Estate • Utility • Communications • IT System Architekt • Technische Projektleitung • Design und Implementierung von Datenbank Anwendungen • Entwurf und Umsetzung von IT Infrastrukturen zum Datenmanagement Gunther Pippèrr arbeitet seit mehr als 15 Jahre intensiv mit den Produkten der Firma Oracle im Bereich Datenbanken/Applikationsserver und Dokumenten-Management. Herr Pippèrr hat sich tiefes Wissen über den Aufbau komplexer IT Architektur aneignen können und hat dieses in der Praxis erfolgreich umgesetzt. Herr Pippèrr hat eine Abschluss als Dipl. Ing. Technische Informatik (FH) an der FH Weingarten. Industry Expertise Background Functional Expertise  Datenbank Architekt für ein Projekt zur Massendatenverarbeitung in der Telekommunikation  Architekt und technische Projektverantwortung für ein Smart Metering Portal für das Erfassen von Energiezählerdaten und Asset Management  Architekt und Projektleitung , Datenbank Design und Umsetzung für die Auftragsverwaltung mit Steuerung von externen Mitarbeitern für den Sprachdienstleister von deutschen Technologiekonzern  Architekt und technische Projektverantwortung für IT Infrastrukturprojekte, z.B.:  Zentrale Datenhaltung für Münchner Hotelgruppe mit über 25 Hotels weltweit,  Redundante Cluster Datenbank Infrastrukturen für diverse größere Web Anwendungen wie Fondplattform und Versicherungsportale  CRM- und Ausschreibungsportal für großen Münchner Bauträger Selected Experience

×