X

Willkommen bei Themen rund um Oracle Technologien, die on-premises oder in der Oracle Public Cloud Verwendung finden.

Deployment eines Oracle NoSQL DB Clusters auf Oracle Cloud Infrastructure VM Shapes

Karin Patenge
Principal Solution Engineer

Einleitung

Horizontal und elastisch skalierende, verteilte Datenbanken, die flexible Datenmodelle unterstützen, sind immer dann im Fokus, wenn es gilt, beliebige und dynamische Datenströme effizient zu speichern, zu verarbeiten und einfach wieder auf diese zuzugreifen. NoSQL Datenbanken sind genau für solche Anwendungsfälle bestimmt. Die sehr kostengünstigen Oracle Cloud Infrastructure (kurz OCI) Ressourcen wie Compute, Storage und Network lassen sich hervorragend dafür nutzen, um ein Oracle NoSQL Datenbank Cluster aufzusetzen und zu betreiben. Dieser Artikel beschreibt, wie Sie einfach und schnell ein Oracle NoSQL DB Cluster mit 3 Knoten deployen und darauf zugreifen. Er beschreibt nicht, wie Sie dann eine Anwendung bauen mit der Oracle NoSQL DB als darunterliegendem Datastore. Dieses Wissen ist in anderen Blog Posts wie diesem beschrieben oder auch als Sample Code u.a. auf Github veröffentlicht.

Basis für das Deployment des Oracle NoSQL DB Clusters sind virtualisierte (VM) Compute Shapes. An diese werden jeweils Block Volumes als zusätzlicher Storage gehängt, welche die Daten aufnehmen sollen. Grundlage für die Kommunikation der Knoten untereinander ist ein virtuelles Cloud Netzwerk, VCN genannt.

Alle Schritte werden einzeln ausgeführt und kurz beschrieben. Der ganze Vorgang läßt sich natürlich auch mittels Terraform, Ansible oder generell Skript-basiert automatisieren.

Alternativ zu den Ausführungen hier gibt es auch ein White Paper (Version vom April 2018) in englischer Sprache, bei welcher für das Deployment die teureren, mit mehr CPUs und Hauptspeicher ausgestatteten OCI Baremetal Shapes verwendet werden. Deren Nutzung ist insbesondere dann zu empfehlen, wenn dedizierte Hard- und Netzwerkressourcen für sehr hohe und höchste Ansprüche sowohl an Performanz als auch Kontrolle zum Einsatz kommen sollen, egal ob Sie ein Oracle NoSQL DB Cluster oder eine andere geclusterte NoSQL Datenbank darauf installieren. Für den Einstieg ins Thema, für nicht geschäftskritische Anwendungen oder auch für die Evaluierung auf eigenen Ressourcen sind VM Shapes perfekt geeignet. Diese können Ihnen ausgestattet ab 1 CPU (genauer gesagt OCPU) und 8 GB Arbeitsspeicher bereitgestellt werden.

Bevor es zum Deployment geht, sei hier noch ein kurzen Überblick zur Datenbank selbst gegeben.

Die Oracle NoSQL DB ist ein einfach aufzusetzender, hochverfügbarer und hochperformanter Key-Value-Store ( KVStore), der mit sehr wenig Administration auskommt. Dem KVStore zugrunde liegt die Berkeley DB Java Edition, eine weit-verbreiteter embedded KVStore, welcher um Funktionen wie Clustering, Sharding und Replikation erweitert wurde. Die Oracle NoSQL DB steht in 3 Editionen zur Verfügung. Die Unterschiede zwischen den einzelnen Editionen sind in diesem FAQ beschrieben. Wesentliche Punkte sollen hier kurz angeführt werden:

  1. Enterprise Edition (EE)
    Diese Edition enthält alle Features der Basic Edition und Community Edition plus weitere Features, die wesentlich sind für die Integration mit anderen Oracle sowie Third-Party-Software-Komponenten wie Oracle Enterprise Manager, Oracle Coherence, Oracle Big Data Spatial and Graph, Elasticsearch oder Kerberos. Sie können diese Edition 30 Tage kostenfrei evaluieren im Rahmen der Oracle Technology Network (OTN) Lizenzbestimmungen.
  2. Basic Edition (BE)
    Diese Edition kann ohne zusätzliche Lizenzkosten genutzt werden, wenn gültige Lizenzen für die Oracle Datenbank Enterprise Edition vorhanden sind. Die Basic Edition kann derzeit nur über edelivery.oracle.com heruntergeladen werden. Der Versionsstand ist nicht gleich dem der Enterprise Edition sondern "hängt" typischerweise um ca. 1 Jahr zurück.
  3. Community Edition (CE)
    Die Edition steht als freie Software unter der Apache 2.0 Lizenz zur Verfügung. Die Software kann über die Oracle Technology Seiten heruntergeladen werden. Auch bei dieser Edition gibt es einen zeitlichen Versatz zur Versionierung der Enterprise Edition, analog der Aussage für die Basic Edition.

Ausführliche Informationen zur Oracle NoSQL DB gibt es auf den entsprechenden Oracle Technology Network Seiten.

 

Überblick der auszuführenden Schritte

  1. Aufsetzen des OCI Ressourcen
  2. Anlegen von Nutzerberechtigungen auf Betriebssystem-Ebene
  3. Download und Installation/Update des Oracle Java Development Kit (JDK) auf allen DB Knoten
  4. Download und Installation der Oracle NoSQL DB Software auf allen DB Knoten
  5. Einrichten des Oracle NoSQL DB Clusters
  6. Überprüfen des Zugriffs mittels Admin REST API für die Oracle NoSQL DB

 

Architektur des Oracle NoSQL DB Clusters

Ein Oracle NoSQL DB Cluster besteht aus sogenannten Storage Nodes. Das ist nichts anderes als CPU, Hauptspeicher und Plattenspeicher. In der verwendeten OCI Umgebung werden dafür Compute Instances mit zusätzlich je 3 angehängten Block Volumes eingesetzt. Die 3 Clusterknoten, oder Storage Nodes, sind dafür da, Daten horizontal verteilt parallel schreiben und auch wieder auslesen zu können. Jeder Storage Node erhält beim Schreiben ein unterschiedliches Set an Daten. Die Verteilung erfolgt über eine Hash-Funktion. Je mehr Storage Nodes das Cluster enthält, umso mehr kann gleichzeitig parallel verteilt geschrieben werden. Um Ausfallsicherheit zu erzeugen, werden die Daten nach dem initialen Schreiben (auf den sogenannten Masterknoten) zusätzlich auf weitere Knoten repliziert. Der empfohlene minimale Replikationsfaktor liegt bei 3. Das bedeutet:

  • 1x Schreiben auf den Masterknoten
  • Von dort Replikation auf 2 weitere (Slave) Knoten

 

Schematische Darstellung eines Oracle NoSQL DB Clusters

Abb. 1: Schematische Darstellung eines Oracle NoSQL DB Clusters

 

Fällt jetzt ein Knoten aus, ist sichergestellt, daß sich jeder Datensatz auf noch mindestens 2 weiteren Knoten befindet. Diese wählen dann unter sich ggf. einen neuen Master, um die nachfolgenden Schreibprozesse sicherzustellen.

Die nebenstehende Abbildung verdeutlicht die Architektur. Sie stellt ein 3x3 Cluster dar. Das bedeutet, 3 Shards werden auf 3 Storage Nodes verteilt. Der Master und dessen 2 Replikas für jedes Shard (zusammengefaßt ergeben sie eine Replikationsgruppe) liegen jeweils auf unterschiedlichen Storage Nodes. Physikalisch werden in meiner Umgebung die Daten auf die den Compute Instanzen angehängten Block Volumes verteilt. Ein Block Volume erhält jeweils die Master-Daten. 2 weitere Block Volumes auf je einer anderen Compute Instanz nehmen die Replikate auf.

 

Deployment des Oracle NoSQL DB Clusters

Es gibt in der OCI Documentation ausführliche Beschreibungen, wie die jeweiligen Ressourcen eingerichtet werden. Daher ist die Konzentration hier auf die Punkte, die wesentlich sind in Bezug auf das Deployment der Oracle NoSQL DB.

Einrichten der OCI Ressourcen

Netzwerk

Ein VCN inklusive Subnetze, Internet Gateway und Route Tables, kann am einfachsten  in einem Schritt angelegt werden. Dazu wird im "Create Virtual Cloud Network" Dialog die Option "CREATE VIRTUAL CLOUD NETWORK PLUS RELATED RESOURCES" ausgewählt. Die verwendeten Eingabewerte für das VCN sind folgende:

  • NAME: Oracle_NoSQL_VCN
  • CIDR Block: 10.0.0.0/16

Im Ergebnis wird das VCN mit 3 Subnetzen angelegt, verteilt auf die 3 Oracle Cloud Rechenzentren (im OCI Kontext Availability Domains genannt) in Frankfurt a.M.

 

Subnetze in OCI

Abb. 2: In OCI angelegte Subnetze

 

Zusätzlich werden automatisch Zugriffsrechte über eine sogenannte Security List vergeben. Diese Security List muß noch angepaßt werden, um die Kommunikation der Storage Nodes untereinander und auch der Anwendung mit dem KVStore zu ermöglichen. Dafür werden zusätzliche Ports freigeschaltet. Für den aufzusetzenden KVStore ist das der Port-Bereich 5000 bis 5050. Die nachfolgende Abbildung zeigt die Zugriffsregeln. Darin sind die ersten 3 sogenannten Ingress Rules Standard-Einstellungen. Die vierte Ingress Rule wurde hinzugefügt:

  • Source CIDR: 10.0.0.0/16
  • IP Protocol: TCP
  • Source Port Range: All
  • Destination Port Range: 5000-5050

 

Security Lists

Abb. 3: Security Lists in OCI

 

Storage

Als nächstes werden insgesamt 9 Block Volumes angelegt, auf denen die Daten gespeichert werden sollen. Diese Volumes werden auf alle 3 Availability Domains verteilt, wie jeweils am Kürzel "AD" im Namen zu erkennen ist. Die Eingabewerte pro Volume sind

  • ein Name,
  • die Auswahl der Availability Domain,
  • die Größe in GB sowie
  • die Angabe einer Backup Policy.

Eine Backup Policy wurde in dieser Umgebung nicht spezifiziert. Es werden also keine automatischen Backups angelegt.

 

Block Volumes

Abb. 4: In OCI verwendete Block Volumes

 

Compute Instanzen

Nun werden noch 3 Compute Instances angelegt. Dabei sind folgende Eingabewerte anzugegeben bzw. auszuwählen:

  • Name
  • Availability Domain
  • Image Source
  • Instance Type: Virtual Machine
  • Instance Shape
  • Configure Boot Volume
  • Add SSH key
  • Virtual Cloud Network Compartment
  • Virtual Cloud Network
  • Subnet Compartment
  • Subnet

Für mehr Infos zu den einzelnen Parametern und insbesondere auch zum Zuweisen des Public SSH Key schauen Sie am besten in die Dokumentation oder in eines der vorhandenen Tutorials. Der passende Private SSH Key (beides zusammen, Public und Private SSH Key, können Sie z.B. mit Hilfe von PuTTYgen anlegen) wird dann lokal für die SSH Client Software benötigt.

 

Compute Instanzen

Abb. 5: In OCI verwendete Compute Instanzen

 

Jeder der Compute Instanzen werden über "Attach Block Volumes" 3 Volumes zugeordnet.

 

Compute Instanz und zugeordnete Block Volumes

Abb. 6: Compute Instanz und zugeordnete Block Volumes

 

Zusätzlich sind für das Attachment noch ein paar wenige Kommandos (iSCSI Commands) auf Betriebssystem-Ebene auszuführen. Diese können per Copy & Paste aus den Compute Instance Details der OCI Konsole geholt werden.

 

iSCSI Kommandos zum Anhängen der Block Volumes

Abb. 7: Zusätzliche Kommandos und Informationen für das Anhängen der Block Volumes

 

Dafür gehen Sie zunächst mit einem SSH Client (z.B. PuTTY, MobaXTerm) und dem Cloud Nutzer "opc" auf die jeweilige Compute Instanz. Vergessen Sie dabei nicht, in den Verbindungsdetails den Private SSH Key anzugeben und ggf. auch einen Proxy einzutragen. Bei PuTTY sieht ersteres wie in der nachfolgenden Abbildung aus:

 

PuTTY

Abb. 8: PuTTY: Mit lokalem SSH Client auf die Compute Instanzen zugreifen

 

Anlegen von Nutzerberechtigungen und Mounten der Volumes

Auf Betriebssystem-Ebene sind nun noch ein paar administrative Arbeiten zu erledigen. Im wesentlichen geht es darum, einen spezifischen Nutzer anzulegen, die Volumes zu mounten und die Compute Instanzen in die jeweilige /etc/hosts aufzunehmen. Passen Sie die Skriptbeispiele entsprechend Ihrer Cloud Instanzen an.

Gruppe und Nutzer anlegen

sudo groupadd nosql
sudo useradd -m nosql -p <pwd> -g nosql
sudo usermod -aG wheel nosql

Hinweis: Wenn Sie sich das 1. Mal über den Nutzer "nosql" mit der Compute Instanz verbinden, werden Sie mit der Meldung "Server refused our key" konfrontiert. Dieses Problem kann leicht behoben werden. Das Vorgehen ist in der MyOracleSupport Note mit der Doc ID 2409609.1 beschrieben. 

Volumes mounten

# Show block storage devices
lsblk
 
# Show all mounted disks
mount
 
# Create directories
sudo mkdir -p /disk1
sudo mkdir -p /disk2
sudo mkdir -p /disk3
 
# Create filesystems
sudo mkfs.ext4 -F /dev/sdb
sudo mkfs.ext4 -F /dev/sdc
sudo mkfs.ext4 -F /dev/sdd
 
# Mount filesystems
sudo mount /dev/sdb /disk1 -o _netdev
sudo mount /dev/sdc /disk2 -o _netdev
sudo mount /dev/sdd /disk3 -o _netdev
 
# Add to fstab
/dev/sdb                /disk1                  ext4    defaults,_netdev,nofail  0 0
/dev/sdc                /disk2                  ext4    defaults,_netdev,nofail  0 0
/dev/sdd                /disk3                  ext4    defaults,_netdev,nofail  0 0
 
# Add hosts to /etc/hosts
10.0.0.2 oracle-nosql-db-ad1-0.sub01234567890.oraclenosqlvcn.oraclevcn.com oracle-nosql-db-ad1-0
10.0.1.2 oracle-nosql-db-ad2-0.sub02345678901.oraclenosqlvcn.oraclevcn.com oracle-nosql-db-ad2-0
10.0.2.2 oracle-nosql-db-ad3-0.sub03456789012.oraclenosqlvcn.oraclevcn.com oracle-nosql-db-ad3-0
 
# Add additional required directories
sudo mkdir -p /disk1/ondb/data
sudo mkdir -p /disk2/ondb/data
sudo mkdir -p /disk3/ondb/data
sudo mkdir -p /disk1/ondb/rnlog
sudo mkdir -p /disk2/ondb/rnlog
sudo mkdir -p /disk3/ondb/rnlog
sudo mkdir -p ~/ondb/admin

Download und Installation des Oracle Java Development Kit (JDK)

Die aktuelle Version der Oracle NoSQL DB (18.3.11) erfordert Java SE 8 oder höher. Laden Sie sich das entsprechende JDK herunter und kopieren Sie dieses auf alle 3 Compute Instanzen. Legen Sie sich ggf. für alle Download Dateien ein entsprechendes Verzeichnis an, z.B. /home/nosql/Downloads. Anschließend installieren Sie das JDK auf allen 3 Compute Instanzen. Falls noch nicht gesetzt, definieren Sie dauerhaft die Umgebungsvariable JAVA_HOME.

# Check Java version
java -version
cd ~/Downloads
 
# Install JDK
sudo rpm -ivh jdk-8u201_linux_x64.rpm
 
# Set environment variable
echo "export JAVA_HOME=/usr/java/latest" >> ~/.bashrc
echo "export PATH=$JAVA_HOME/bin:$PATH" >> ~/.bashrc

Download, Installation und Deployment der Oracle NoSQL DB

Analog können Sie jetzt für die Installation der Oracle NoSQL DB vorgehen. Wählen Sie eine der Download Dateien aus, entweder die Community Edition oder die Enterprise Edition.
Sie erinnern sich: Die Community Edition ist eine freie Software. Aber auch die Enterprise Edition können Sie im Rahmen der Oracle Technology Network (OTN) Lizenzbestimmungen für 30 Tage kostenfrei evaluieren. Ein großer Vorteil der Enterprise Edition ist, daß sie immer den neuesten Releasestand wiedergibt.
Zusätzlich sollten Sie auch gleich die Oracle NoSQL DB Examples herunterladen und ebenfalls installieren. Diese enthalten u.a. Beispielcode. Ausführliche Anleitungen finden Sie in der Oracle NoSQL DB Dokumentation.

su - nosql
 
# Unzip install files to nosql user home
cd ~
gunzip ~/Downloads/kv-ee-18.3.11.tar.gz
gunzip ~/Downloads/kv-examples-18.3.11.tar.gz
tar -xvzf kv-ee-18.3.11.tar
tar -xvzf kv-examples-18.3.11.tar
ls -l kv-18.3.11
 
# Create KV root directory
mkdir kvroot
 
# Set environment variables
echo "export KVHOME=~/kv-18.3.11" >> ~/.bashrc
echo "export KVROOT=~/kvroot" >> ~/.bashrc
echo "export CLASSPATH=$KVHOME/lib/*:$CLASSPATH" >> ~/.bashrc
source ~/.bashrc
echo $KVHOME
echo $KVROOT
ls -l
 
# Check installation
java -Xmx64m -Xms64m -jar $KVHOME/lib/kvclient.jar
java -jar $KVHOME/lib/kvstore.jar ping -host localhost -port 5000

Für das Deployment der Oracle NoSQL DB, also das Aufsetzen des Clusters, braucht es 3 Schritte:

  1. Bootstrapping
  2. Start des Storage Node Agent
  3. Deployen der Topologie

Auch diese 3 Schritte werden wieder auf allen Storage Nodes ausgeführt.

Für das Bootstrapping müssen zunächst die wichtigsten Parameter konfiguriert werden. Ausführliche Infos über die Parameter und deren Anwendung finden sich in der Dokumentation. Die Bootstrapping Datei makebootconfig.sh für die Umgebung sieht folgendermaßen aus:

#!/bin/bash
 
# Login as user nosql
# Use the makebootconfig utility to generate the configuration. We do this for each storage node
# -root the KVROOT directory
# -host node hostname or IP address
# -port specifies the registry port used by the Storage Node Agent
# -admin specifies the port used by Administration Service to listen for HTTP connections
# -harange specifies the range port used by the replication nodes and Administration services
# -capacity specifies number of a Replication Nodes supported by Storage Node
# -num_cpus used when multiple Replication Nodes are configured on a Storage Node. If the value is 0, the system will attempt to query the Storage Node to determine the number of processors on the machine.
# -memory_mb total memory available for the cache and heap sizes. If the value is 0, the store will attempt to determine the amount of memory on the machine, but that value is only available when the JVM used is the Oracle Hotspot JVM.
# -store-security specifies if security will be used or not. In this example no security is used.
 
########### Bootstrap Storage Node 1 ##########
java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar makebootconfig \
    -root $KVROOT \
    -host 10.0.0.4 \
    -port 5000 \
    -admin-web-port 5010 \
    -servicerange 5015,5025 \
    -harange 5030,5050 \
    -capacity 3 \
    -admindir /home/nosql/ondb/admin \
    -admindirsize 50_GB \
    -store-security none \
    -memory_mb 6000 \
    -storagedir /disk1/ondb/data \
    -storagedirsize 250_GB \
    -storagedir /disk2/ondb/data \
    -storagedirsize 250_GB \
    -storagedir /disk3/ondb/data \
    -storagedirsize 250_GB \
    -rnlogdir /disk1/ondb/rnlog \
    -rnlogdir /disk2/ondb/rnlog \
    -rnlogdir /disk3/ondb/rnlog
echo " Done bootstrapping storage-node 1"
################################################
 
########### Bootstrap Storage Node 2 ###########
java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar makebootconfig \
    -root $KVROOT \
    -host 10.0.1.3 \
    -port 5000 \
    -admin-web-port 5010 \
    -servicerange 5015,5025 \
    -harange 5030,5050 \
    -capacity 3 \
    -admindir /home/nosql/ondb/rnlog \
    -admindirsize 50_GB \
    -store-security none \
    -memory_mb 6000 \
    -storagedir /disk1/ondb/data \
    -storagedirsize 250_GB \
    -storagedir /disk2/ondb/data \
    -storagedirsize 250_GB \
    -storagedir /disk3/ondb/data \
    -storagedirsize 250_GB \
    -rnlogdir /disk1/ondb/rnlog \
    -rnlogdir /disk2/ondb/rnlog \
    -rnlogdir /disk3/ondb/rnlog
echo " Done bootstrapping storage-node 2"
################################################
 
############ Bootstrap Storage Node 3 ##########
java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar makebootconfig \
    -root $KVROOT \
    -host 10.0.2.3 \
    -port 5000 \
    -admin-web-port 5010 \
    -servicerange 5015,5025 \
    -harange 5030,5050 \
    -capacity 3 \
    -admindir /home/nosql/ondb/admin \
    -admindirsize 50_GB \
    -store-security none \
    -memory_mb 6000 \
    -storagedir /disk1/ondb/data \
    -storagedirsize 250_GB \
    -storagedir /disk2/ondb/data \
    -storagedirsize 250_GB \
    -storagedir /disk3/ondb/data \
    -storagedirsize 250_GB \
    -rnlogdir /disk1/ondb/rnlog \
    -rnlogdir /disk2/ondb/rnlog \
    -rnlogdir /disk3/ondb/rnlog
echo " Done bootstrapping storage-node 3"
################################################

Nun wird das Bootstrapping ausgeführt.

./makebootonfig.sh

Für den 2. Schritt, das Starten des Storage Node Agent (SNA), wird das Skript startSNA.sh ausgeführt. Dessen Inhalt sieht folgendermaßen aus:

#!/bin/bash
 
export MALLOC_ARENA_MAX=1
 
##### Start SNA on each Storage Node ##########
java -Xmx64m -Xms64m -jar $KVHOME/lib/kvstore.jar start -root $KVROOT &
echo " Done starting SNA"

Starten des SNA

./startSNA.sh

Der 3. und letzte Schritt ist das Deployment der Clustertopologie, also in dieser Umgebung ein 3x3 Cluster. Zuerst sehen Sie wieder das zugehörige Skript (3x3.kvs), jetzt mit den spezifischen Admin Befehlen für die Oracle NoSQL DB:

### Begin Script ###########################################
configure -name kvstore
plan deploy-zone -name "Frankfurt" -rf 3 -wait
 
####### Deploy First Storage Node  #########################
plan deploy-sn -znname "Frankfurt" -port 5000 -wait -host 10.0.0.4
plan deploy-admin -sn sn1 -wait
 
###### Deploy Second Storage Node ##########################
plan deploy-sn -znname "Frankfurt" -port 5000 -wait -host 10.0.1.3
plan deploy-admin -sn sn2 -wait
 
###### Deploy Third Storage Node ###########################
plan deploy-sn -znname "Frankfurt" -port 5000 -wait -host 10.0.2.3
plan deploy-admin -sn sn3 -wait
 
####### Create Storage Pool ################################
pool create -name AllStorageNodes
pool join -name AllStorageNodes -sn sn1
pool join -name AllStorageNodes -sn sn2
pool join -name AllStorageNodes -sn sn3
 
######## Create topology, preview it and then deploy it #####
topology create -name 3x3 -pool AllStorageNodes -partitions 120
topology preview -name 3x3
plan deploy-topology -name 3x3 -wait
### End Script #############################################

Schließlich fehlt noch das Ausführen dieses Skripts. Hierbei ist zu beachten, daß die (interne) IP Adresse, welche auf den Parameter host folgt, pro Storage Node angepaßt werden muß:

java -jar $KVHOME/lib/kvstore.jar runadmin -port 5000 -host 10.0.0.4 load -file 3x3.kvs

Ob das Deployment erfolgreich war, sehen Sie direkt beim Ausführen der 3 Schritte. Zusätzlich kann aber gern noch mal ein ping auf das Cluster ausgeführt werden.

java -jar $KVHOME/lib/kvstore.jar ping -host localhost -port 5000

 

Ping auf den Oracle NoSQL DB Cluster

Abb. 9: Ping auf den Oracle NoSQL DB Cluster

 

Detaillierter reinschauen können Sie auch mit einem Admin Interface. Es gibt sowohl ein Kommandozeilen-basiertes als auch ein RESTful Web Service. Das REST Interface wurde automatisch nach dem Deployment gestart, weil in der makebootconfig Datei der Parameter admin-web-port konfiguriert wurde. Ein REST Call zum Anzeigen der Clustertopologie und der entsprechende Response sehen dann so aus:

curl -i -X POST "http://10.0.0.4:5010/V0/nosql/admin/topology" -d '{"command":"show"}'

 

REST Call zum Anzeigen der Cluster Topologie

Abb. 10: REST Call auf das Oracle NoSQL DB Admin Interface

 

Fazit

Horizontal skalierende, verteilte Datenbanken sind immer dann im Fokus, wenn es gilt, beliebige Datenströme in Echtzeit oder Echtzeit-nah aufnehmen zu können und mit einfachen Zugriffen, die Daten auch wieder auszulesen. Die Oracle NoSQL DB ist eine solche Datenbank. Für deren Nutzung können Sie sich entscheiden, einen Cluster mit eigenen Hardware Ressourcen aufzubauen. Als sehr kostengünstige und flexible Alternative bietet sich das Deployment auf der Oracle Cloud Instrastructure an. Alle notwendigen Ressourcen werden hierüber innerhalb weniger Minuten und mit wenig Aufwand bereitgestellt. Sie haben die Kontrolle, wofür Sie welche Ressourcen einsetzen. Allerdings obliegt Ihnen auch die Administration, inklusive Upgrades und Patching. Möchten Sie sich nur noch auf das Entwickeln von Anwendungen mit der Oracle NoSQL DB als darunterliegendem Datenmanagementsystem konzentrieren, dann haben Sie zusätzlich die Möglichkeit der Nutzung des Oracle NoSQL DB Cloud Service. Dieser Service wird nicht in Form von Shapes provisioniert sondern kommt als Anwendung daher. Auf diese Anwendung können Sie mittels spezifischer Rechte zugreifen und somit eigene Anwendungen erstellen. Der Service ist also konzipiert für AnwendungsentwicklerInnen. Er wird Gegenstand eines zukünftigen Artikels sein. Also schauen Sie gern bei Gelegenheit wieder rein.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.