Inhaltsverzeichnis
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 Aufbau des Keys
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 Transaktions Verhalten der Datenbank
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.
Die Schreib Konsistenz im Store - Durability
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 Lese Konsistenz im Store - Consistency
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