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:
Nachteil:
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:
Das gleiche gilt auch für das Lesen:
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:
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
SyncPolicy.WRITE_NO_SYNC
SyncPolicy.NO_SYNC
Replica Acknowledgement
ReplicaAckPolicy.ALL
ReplicaAckPolicy.SIMPLE_MAJORITY
ReplicaAckPolicy.NONE
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!
// 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
Consistency.Time
Consistency.Version
Consistency.NONE_REQUIRED
V3 Neu
Consistency.NONE_REQUIRED_NO_MASTER
siehe auch die Die Consistency Klasse