Cassandra ohne Partitionsschlüssel abfragen

Ich habe die Dokumentation von Cassandra über die internen Schritte gelesen, die beim Abfragen von Daten ausgeführt werden. Es sieht so aus, als ob Cassandra sich bei der Verarbeitung von Abfragen auf die Partitionierer- und Replikationsstrategie verlässt. Ich bin immer noch verwirrt, dass der Partitionierer den Partitionsschlüssel kennen muss. Wenn die Abfrage über den Paritition Key verfügt, sieht der interne Abfrageprozess unkompliziert aus. Wenn die Abfrage jedoch eine Ergebnismenge anstelle einer deterministischen Zeile wie unten erwartet.

SELECT * FROM <table>

1. WHEREWoher weiß der Koordinator in diesem Fall, an welche Knoten die Anforderungen gesendet werden sollen, wenn in der Klausel kein Primärschlüssel angegeben ist ?

2. Wenn mehrere Zeilen zurückgegeben werden, die auf verschiedene Knoten verteilt sein können, wie werden diese Zeilen aggregiert und an den Client zurückgegeben?

Woher weiß der Koordinator, an welche Knoten die Anforderungen gesendet werden sollen, wenn in der WHERE-Klausel kein Primärschlüssel angegeben ist?

1. Das tut es nicht. Der (als) Knoten ausgewählte Knoten muss alle Zeilen auf jedem Knoten nach dieser Tabelle durchsuchen. Aus diesem Grund werden ungebundene Abfragen in Cassandra als Anti-Pattern angesehen, da sie viel Netzwerkzeit erfordern. Besonders in größeren Clustern. Außerdem muss der Koordinator zusätzliche Arbeit leisten, da er die Ergebnismenge zusammenstellen und zurückgeben muss.

Wenn mehrere Zeilen zurückgegeben werden, die auf verschiedene Knoten verteilt sein können, wie werden diese Zeilen aggregiert und an den Client zurückgegeben?

2. Sie sind nicht wirklich so stark aggregiert, da sie in der Reihenfolge des Hash-Token-Werts ihres Partitionsschlüssels zurückgegeben werden.

Stellen Sie sich eine ungebundene Abfrage vor, die für eine Tabelle crewmit dem Partitionsschlüssel "ausgeführt" wird crewname. Wenn ich die CQL- token()Funktion für diesen Schlüssel ausführe , können Sie sehen, dass die zurückgegebenen Zeilen tatsächlich nach ihrem Token sortiert sind.

aploetz@cqlsh:presentation> SELECT crewname,token(crewname),firstname,lastname 
FROM crew;

 crewname | token(crewname)      | firstname | lastname
----------+----------------------+-----------+-----------
    Simon | -8694467316808994943 |     Simon |       Tam
    Jayne | -3415298744707363779 |     Jayne |      Cobb
     Wash |   596395343680995623 |     Hoban | Washburne
      Mal |  4016264465811926804 |   Malcolm |  Reynolds
     Zoey |  7853923060445977899 |      Zoey | Washburne
 Sheppard |  8386579365973272775 |    Derial |      Book

(6 rows)

Dies funktioniert auf diese Weise, da Cassandra bestimmte Knoten in erster Linie für bestimmte Tokenbereiche verantwortlich macht. Es wird dann zu einer einfachen Aufgabe für den Koordinator, die Ergebnismenge in dieser Reihenfolge zurückzugeben. Wenn mehrere Zeilen mit demselben Partitionsschlüssel vorhanden sind, werden die Ergebnisse zusätzlich nach den Clusterschlüsseln in jedem Partitionsschlüssel sortiert .