web-dev-qa-db-fra.com

Interrogation Cassandra sans clé de partition

J'ai lu la documentation de Cassandra sur les étapes internes qu'elle effectue lors de la requête de données. Il semble que Cassandra s'appuie sur le partitionneur et la stratégie de réplication pour traiter les requêtes. Je suis toujours confus que le partitionneur doit connaître la clé de partition. Si la requête a la clé de partition, le processus de requête interne Cependant, si la requête attend un jeu de résultats au lieu d'une ligne déterministe comme ci-dessous.

SELECT * FROM <table>

  1. Dans ce cas, lorsqu'aucune clé primaire n'est spécifiée dans la clause WHERE, comment le coordinateur sait-il à quels nœuds envoyer les demandes?

  2. Si plusieurs lignes sont renvoyées, qui peuvent être distribuées dans différents nœuds, comment ces lignes sont-elles agrégées et renvoyées au client?

cassandra
7
Jet

quand aucune clé primaire n'est spécifiée dans la clause WHERE, comment le coordinateur sait-il à quels nœuds envoyer les demandes?

  1. Ce n'est pas le cas. Le (nœud choisi comme) coordinateur doit analyser toutes les lignes de cette table sur chaque nœud. C'est pourquoi les requêtes non liées sont considérées comme un anti-modèle dans Cassandra, car elles impliquent beaucoup de temps réseau. Surtout dans les grands groupes. De plus, le coordinateur devra faire un travail supplémentaire car il doit assembler et renvoyer l'ensemble de résultats.

Si plusieurs lignes sont renvoyées, qui peuvent être distribuées dans différents nœuds, comment ces lignes sont-elles agrégées et renvoyées au client?

  1. Ils ne sont pas vraiment tellement agrégés, car ils sont retournés dans l'ordre par la valeur du jeton haché de leur clé de partition.

Considérez une requête non exécutée exécutée sur une table nommée crew, avec une clé de partition de crewname. Lorsque j'exécute la fonction CQL token() sur cette clé, vous pouvez voir que les lignes retournées sont en effet ordonnées par leur jeton.

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)

Cela fonctionne de cette façon, car Cassandra rend certains nœuds principalement responsables de certaines plages de jetons. Il devient alors une tâche simple pour le coordinateur de renvoyer le jeu de résultats dans cet ordre. S'il y a plusieurs lignes avec le même clé de partition, les résultats seront en outre triés par les clés de cluster dans chaque clé de partition.

6
Aaron