nosql:db_architektur_oracle_nosql_db_11gr2
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende Überarbeitung | |||
nosql:db_architektur_oracle_nosql_db_11gr2 [2014/06/22 17:17] – [Die Lese Konsistenz im Store - Consistency] gpipperr | nosql:db_architektur_oracle_nosql_db_11gr2 [2014/06/22 17:17] (aktuell) – [Die Lese Konsistenz im Store - Consistency] gpipperr | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ====== 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, | ||
+ | |||
+ | ==== 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, | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | Mit dem Mayor Part des Keys wird die Partitionierung über den Store durchgeführt. | ||
+ | |||
+ | |||
+ | Die Daten werden als ByteArray gespeichert, | ||
+ | |||
+ | |||
+ | 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, | ||
+ | * 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 " | ||
+ | |||
+ | Unterstützt wird dieses Verhalten über die Methode [[http:// | ||
+ | |||
+ | |||
+ | |||
+ | ==== 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> | ||
+ | | ||
+ | new Durability( | ||
+ | // master sync | ||
+ | | ||
+ | // replicat sync | ||
+ | , | ||
+ | // replica acknowledge | ||
+ | , | ||
+ | ) | ||
+ | ); | ||
+ | </ | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | |||
+ | **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:// | ||
+ | |||
+ | |||
+ | ==== Die Lese Konsistenz im Store - Consistency ==== | ||
+ | |||
+ | Die Datenbank bietet verschiedene [[http:// | ||
+ | |||
+ | Der Entwickler ist verantwortlich für die Lese Konsistenz! | ||
+ | |||
+ | * Jedem Key Objekt besitzt auch eine Versionsinformation, | ||
+ | * Verhalten wird beim Connect zum Store definiert Klasse oracle.kv.Consistency | ||
+ | |||
+ | <code java> | ||
+ | // 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, | ||
+ | |||
+ | **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:// | ||
+ | |||
+ | |||
+ | |||
+ | ====Quellen==== | ||
+ | |||
+ | * http:// | ||
nosql/db_architektur_oracle_nosql_db_11gr2.txt · Zuletzt geändert: 2014/06/22 17:17 von gpipperr