Gunther Oracle APEX und Datenbank Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== 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. 

{{ :nosql:oracle_nosql_key_value_overview.png?500 | Oracle NoSQL Key Value Overview}}

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. 

{{ :nosql:oraclenosql-transaction-v01.png?500 |Transaktions Verhalten der Oracle NoSQL Datenbank}}


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 [[http://docs.oracle.com/cd/NOSQL/html/javadoc/oracle/kv/KVStore.html#execute%28java.util.List%29|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

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

{{ :nosql:oraclenosql-durability-v01.png?300 |Oracle NoSQL Durability }}


**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 [[http://docs.oracle.com/cd/NOSQL/html/GettingStartedGuide/consistency.html| 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

<code java>
// Consistency definieren
kvconfig.setConsistency(Consistency.NONE_REQUIRED);
</code>

{{ :nosql:oraclenosql-consistency-v01.png?300 | Oracle NoSQL Consistency }}

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 [[http://docs.oracle.com/cd/NOSQL/html/javadoc/oracle/kv/Consistency.html| Die Consistency Klasse]]



====Quellen====

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