when there is no Primary Key specified in the WHERE clause, how does the Coordinator know which nodes to send the requests to?
- 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?
- 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
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
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.