Cassandra – Querying Without a Partition Key

cassandra

I read Cassandra's documentation on the internal steps it performs when querying data. It looks like Cassandra relies on the Partitioner and Replication Strategy to process queries. I am still confused that the Partitioner needs to know the Partition Key. If the query has the Paritition Key, the internal query process looks straightforward. However, if the query expects a result set instead of a deterministic row like below.

SELECT * FROM <table>

  1. In this case, when there is no Primary Key specified in the WHERE clause, how does the Coordinator know which nodes to send the requests to?

  2. If multiple rows are returned, which may be distributed in different nodes, how are these rows aggregated and returned to client?

Best Answer

when there is no Primary Key specified in the WHERE clause, how does the Coordinator know which nodes to send the requests to?

  1. It doesn't. The (node chosen as the) coordinator has to scan all rows for that table on each and every node. That's why unbound queries are considered to be an anti-pattern in Cassandra, as they incur a lot of network time. Especially in larger clusters. Also, the coordinator will have to do extra work as it has to assemble and return the result set.

If multiple rows are returned, which may be distributed in different nodes, how are these rows aggregated and returned to client?

  1. They are not really so much aggregated, as they are returned in order by the hashed token value of their partition key.

Consider an unbound query run against a table named crew, with a partition key of crewname. When I run the CQL token() function on that key, you can see that the rows returned are indeed ordered by their token.

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)

It works this way, because Cassandra makes certain nodes primarily responsible for certain token ranges. It then becomes a simple task for the coordinator to return the result set in that order. If there multiple rows with the same partition key, the results will additionally be sorted by the clustering keys within each partition key.

Related Question