Auf dem Key-Value Store der Orace NoSQL Datenbank die Durability und Consistency - das Transaktionelle Verhalten - einstellen

Die Oracle NoSQL Datenbank ist eine Key-Value Store.

Auf die Daten wird immer über den Schlüssel zugegriffen, dazu ist der Key in zwei Komponenten unterteilt, den Mayor und den Minor Key. Im Prinzip sind die Daten zu einem Key immer ein Binärer Datencontainer (zum Beispiel ein serialisiertes Java Objekt) und damit nicht selbst beschreibend.

Der Mayor Key definiert (über das Ergebnis des MD5 Hash % Anzahl der Partitionen) in welcher Partition die Daten laden. der Minor Key dient der Datenmodellierung, um Daten logisch zu gruppieren bzw. der Minor Teil kann auch als eine Art „Index“ bzw. Gruppen Kriterium, um die Daten zu organisieren, verstanden werden.

Mit dem Mayor Part des Keys wird die Partitionierung über den Store durchgeführt.

Die Daten werden als ByteArray gespeichert, die Datenbank führt selber keinerlei interne Verarbeitung auf diesen „Daten Container“ durch.

Vorteil:

• Schneller, Index artiger Zugriff

Nachteil:

• Für eine Gruppen und Summenbildung muss immer der komplette Store ausgelesen und auf Client Seite verarbeitet werden.

Das Verhalten der Applikation stellt der Entwickler über den Treiber ein, ob er nach dem CAP Theorem mehr eine CA, „Consistency und Availabitlity“ oder AP, „Availabitlity und Partition Tolerance“ anstrebt.

Der Entwickler entschiedet, wie beim Schreiben und Lesen vorgegangen werden soll:

• Ob zum Beispiel schnell das Schreiben in den Cache eines Master Nodes ausreicht, oder
• ob sicherheitshalber der Datensatz doch auch auf allen Replikaten erfolgreich geschrieben werden muss.

Das gleiche gilt auch für das Lesen:

• ist der erste einigermaßen aktuelle Datensatz ausreichend (Eventually Consistent)
• oder muss sichergestellt werden, dass hier auch der aktuellste Datensatz bzw. die letzte Version gelesen wurde.

Innerhalb einer Gruppe von Aktionen auf demselben „Mayor Key Path“ kann diese Gruppe von Aktionen zu einer Transaktion zusammengefasst werden. Mit dieser „atomaren“ Transaktion kann sichergestellt werden, das entweder alles erfolgreich abgearbeitet oder gar nicht abgearbeitet wird.

Unterstützt wird dieses Verhalten über die Methode execute der Klasse KVStore.

Der Entwickler ist verantwortlich für die Konsistenz beim Schreiben und stellt diese beim Connect zum Store ein. Über die Durability Eigenschaften kann der Client damit definieren wie schnell eine Änderung an den Daten auch im Store persistiert werden soll. Die Eigenschaft wird über eine Instance der Klasse oracle.kv.Durability auf globaler oder Session / Transaktionsebene gesetzt.

Klasse oracle.kv.Durability:

• Commit-Policy für den Master
• Commit-Policy für die Replikate
• Replica Acknowledgement-Policy

 kvconfig.setDurability(
        new Durability(
           // master sync
           Durability.SyncPolicy.WRITE_NO_SYNC
           // replicat sync
          ,Durability.SyncPolicy.NO_SYNC
           // replica acknowledge
           ,Durability.ReplicaAckPolicy.NONE
        )
 );

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

siehe auch http://docs.oracle.com/cd/NOSQL/html/GettingStartedGuide/durability.html

Die Datenbank bietet verschiedene Consistency Level an.

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 Klasse oracle.kv.Consistency

// Consistency definieren
kvconfig.setConsistency(Consistency.NONE_REQUIRED);

Je nach Einstellung kann garantiert werden ob keine Dirty Reads erfolgen dürfen oder ob aus Performance Gründen diese komplett ignoriert wird.

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 erlaubt, 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

V3 Neu
Consistency.NONE_REQUIRED_NO_MASTER

• Erzwingt das Lesen immer nur von einem Slave um den Master nicht zu überlasten

siehe auch die Die Consistency Klasse

• http://www.oracle.com/technetwork/products/nosqldb/overview/nosql-transactions-497227.html