Cassandra ReadTimeOuts

Question

Ich habe ein Problem mit Cassandra ReadTimeOuts. Szenario:

• 3 Daten GB zu Cassandra geladen,
• 9 Knoten Cassandras innerhalb von 1 DataCenter-,
• Replikation gleich 3,
• Konsistenzgrad gleich 1 ist,
• Cassandra Version 2.2.9

Link cassandra.yaml https://pastebin.com/x0bF7nLf

Tests: Zum Testen verwende ich jmeter plug-in für Cassandra. Anforderung ist eine Auswahl mit Bedingung für die Zeilen-ID innerhalb der bereitgestellten ID-Liste. Die Liste enthält immer 100 IDs. Jede Anfrage sollte immer 100 Zeilen zurückgeben (alle IDs sind in der Datenbank). IDs sind zufällig, daher wird die Cache-Rolle reduziert.

Sample auswählen:

 
select * from price.item_vat_posting_group where no in ('B7B7A6','B2DD05','A34751','B4BC7D','C0BB53','D07DCB','C03716','BB99DF','A975C2','C2AE27','AF621C','242448','B30CDA','508336','B44D6B','D07422','AC44EA','C6F34D','9B25AC','C4CF12','AC25BD','C3D9C7','AE7DB2','C5E03E','BF7AC1','B499B5','A7787E','645180','A9BEFE','AFFEA4','A88955','D95B50','B0F9FC','C09174','253953','9ED9CA','CAF896','536951','214502','427776','DA14CB','422282','A4B10A','C56BF5','B373E0','D171EF','C70607','B350AB','9D809B','586563','BF6308','A4BF5A','C42716','C3261C','C45B79','C6FE55','D1F0D4','C483B5','A67D59','DC5898','9BACAD','D9C6B0','D17DAE','D8D4F3','A05946','BBEBA8','A87B37','A13E97','BB7099','A3FC26','C461DF','309810','BF6306','D07603','C59F70','C5906C','A515ED','B50056','A8390E','A0CCC7','BF2713','C6EC7D','D7EB9D','A5D5EB','984076','D88F44','257058','D61635','D40CDE','B0A347','B7617F','D6277E','B4286F','C41F99','D84232','DC1636','BFF15D','DD0972','9B3138'); 

Szenario 1. Während Anfragen von 100 Fäden in 10 Minuten Zeit Cassandra hat 5% ReadTimeOuts zur Gesamtzahl der Anfragen behandelt sendet. Die durchschnittliche Anfragezeit beträgt 100 ms. Die Prozessorauslastung für jeden Cassandra-Knoten liegt zwischen 40% - 50%.

Szenario 2. Beim Senden von Anfragen von 4 Threads in 24 Stunden Zeit treten ca. 10 ReadTimeOuts pro 100 000 Anfragen auf. Die Prozessorauslastung für jeden Cassandra-Knoten beträgt 5%.

In beiden Szenarien arbeitet Garbage Collector weniger als 300 ms.

Fehlermeldung:

 
Cassandra time-out during read query at consistency LOCAL_ONE (1 responses were required but only 0 replica responded) 
com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout during read query at consistency LOCAL_ONE (1 responses were required but only 0 replica responded) 
at com.datastax.driver.core.exceptions.ReadTimeoutException.copy(ReadTimeoutException.java:69) 
at com.datastax.driver.core.DefaultResultSetFuture.extractCauseFromExecutionException(DefaultResultSetFuture.java:258) 

Einige Statistiken:

FRAGE:

Ist das typisch für Cassandra oder mache ich etwas falsch?

Answer 1

Ihre Anfrage ist nicht effizient, weil Sie viel Partition scannen. Jede Partition in einem anderen Knoten gespeichert. Sie sollten eine oder weniger 10 Partitionen mit Bereichsbedingung scannen. Ihr Datenmodell ändern, Links Thesen überprüfen:

https://www.datastax.com/dev/blog/the-most-important-thing-to-know-in-cassandra-data-modeling-the-primary-key

https://www.datastax.com/dev/blog/a-deep-look-to-the-cql-where-clause

Answer 2

Sie verwenden in Abfrage, in Abfrage legen Sie eine große Presser in den Koordinator Knoten. Wenn Sie in einer Abfrage ausführen, bedeutet dies, dass Sie auf diesen einzelnen Koordinatorknoten warten, um Ihnen eine Antwort zu geben. Er behält alle diese Abfragen und ihre Antworten im Heap und wenn eine dieser Abfragen fehlschlägt oder der Koordinator fehlschlägt, werden Sie muss die ganze Sache wiederholen.

Anstatt in Abfrage verwenden Sie executeAsync mit separater Abfrage für jede no. Wenn eine Abfrage fehlgeschlagen ist, wird nur eine kleine schnelle Abfrage benötigt.

Oder

Ihr Datenmodell ändern, so dass Sie Partition Schlüssel bei der Verwendung in Abfrage angeben.

Hinweis: Zu viel executeAsync gleichzeitig kann auch Presser auf Ihrem Cluster setzen.Prüfen Sie diesen Link https://stackoverflow.com/a/30526719/2320144

Mehr: https://lostechies.com/ryansvihla/2014/09/22/cassandra-query-patterns-not-using-the-in-query-for-multiple-partitions/