Konsistenz und Timeout-Probleme mit Cassandra 2.2

Question

Ich benutze Cassandra 2.2 und ich habe eine Anwendung, die ein hohes Maß an Konsistenz erfordert.

Ich habe einen Datencenter-Cluster mit 3 Knoten konfiguriert. Mein Schlüsselbereich wird mit replication_factor von 2 erstellt. In jeder configuration.yaml Dateien habe ich 2 seed_providers (zum Beispiel NODE_1 und NODE_3) gesetzt.

Wichtig ist, dass meine App auch bei Ausfall eines Knotens voll funktionsfähig sein sollte.

Derzeit habe ich Probleme mit der Konsistenz und dem Timeout, wenn meine App den Cluster kontaktiert.

Ich habe die ganze Cassandra 2.2 Dokumentation zu lesen und ich festgestellt, dass die besten CONSISTENCY LEVEL für meine Schreiboperationen QUORUM sein sollte und für meine Leseoperationen ONE, aber ich habe noch einige Konsistenzprobleme hat.

Vor allem ist es die richtige Wahl, ein hohes Maß an Konsistenz zu haben? Und auch, sind UPDATE und DELETE Operationen als Schreib-oder Leseoperationen, da zum Beispiel eine Update-Operation mit einer WHERE Klausel noch Daten 'lesen' muss? Ich bin mir nicht sicher, räumlich im Zusammenhang mit dem Cassandra-Schreib-Workflow.

Mein zweites Problem ist die Zeitüberschreitung während der Schreibvorgänge. Eine einfache und leichte INSERT manchmal "Cassandra timeout during write query at consistency QUORUM (2 replicas were required but only 1 acknowledged the write)" oder etwas sogar "... 0 acknoledged", obwohl alle meine 3 Knoten UP sind.

Gibt es einige andere Parameter, die ich überprüfen sollte, wie zum Beispiel write_request_timeout_in_ms, mit einem Standardwert von 2000 ms (was ist schon ein hoher Wert)?

Answer 1

Sie haben eine starke Konsistenz mit Replication Factor = 2 und Consistency Level = QUORUM für Schreibvorgänge und ONE für Lesevorgänge. Schreiboperationen schlagen jedoch fehl, wenn ein Knoten ausgefallen ist. Consistency Level = QUORUM ist das gleiche wie ALL in Fall Replication Factor = 2.

Sie sollten Replication Factor = 3 und Consistency Level = QUORUM für Schreib- und Lesevorgänge verwenden, um eine starke Konsistenz und eine voll funktionsfähige App auch dann zu haben, wenn ein Knoten ausgefallen ist.

DELETE und UPDATE Operationen sind Schreibvorgänge.

Für das Zeitlimit Problem bitte Tabellenmodell und Abfragen, die fehlschlagen.

Aktualisiert

Konsistenz Ebene gilt für Repliken, nicht Knoten.

Replikationsfaktor = 2 bedeutet, dass 2 von 3 Knoten Daten enthalten. Diese Knoten sind Replikate.

QUORUM bedeutet, dass eine Schreiboperation durch 2 Replikate (wenn Replikationsfaktor = 2), nicht Knoten bestätigt werden muss.

Cassandra platziert die Daten auf jedem Knoten entsprechend dem Partitionsschlüssel. Jeder Knoten ist für einen Bereich von von Partitionsschlüsseln verantwortlich. Kein Knoten kann Daten speichern. Daher müssen Sie über aktive Replikate (keine Knoten) verfügen, um Operationen ausführen zu können. Hier Artikel about data replication and distribution.

Wenn Sie die QUORUM-Schreibanforderung zum Cluster mit 2 von 3 aktiven Knoten ausführen, besteht die Möglichkeit, dass der Cluster nur 1 aktives Replikat für den Partitionsschlüssel aufweist. In diesem Fall schlägt die Schreibanforderung fehl.

In weiteren: hier ist ein simple calculator for Cassandra parameters