1

I don't understand the load balancing algorithm in cassandra.

It seems that the TokenAwarePolicy can be used to route my request to the coordinator node holding the data. In particular, the documentation states (https://docs.datastax.com/en/developer/java-driver/3.6/manual/load_balancing/) that it works when the driver is able to automatically calculate a routing-key. If it can, I am routed to the coordinator node holding the data, if not, I am routed to another node. I can still specify the routing-key myself if I really want to reach the data without any extra hop.

What does not make sense to me:

If the driver cannot calculate the routing-key automatically, then why can the coordinator do this? Does it have more information than the client driver? Or does the coordinator node then ask every other node in the cluster on my behalf? This would then not scale, right?

I thought that the gossip protocol is used to share the topology of the ring among all nodes (AND the client driver). The client driver than has the complete 'ring' structure and should be equal to any 'hop' node.

Load balancing makes sense to me when the client driver determines the N replicas holding the data, and then prioritizes them (host-distance, etc), but it doesn't make sense to me when I reach a random node that is unlikey to have my data.

shaft
  • 2,147
  • 2
  • 22
  • 38
  • I was asking "If the driver cannot calculate the routing-key automatically, then why can the coordinator do this?". The answer you have linked does not explain this. It remains magic to me. Example: If I am looking for data with ID=42 but cannot calculate the routing-key, then why can the coordinator Node calculate that the data should be on node 123? The only thing I know is ID=42 and that's also the only information that the coordinator node has. – shaft May 30 '19 at 15:19

1 Answers1

1

Token aware load balancing happens only for that statements that are able to hold routing information. For example, for prepared queries, driver receives information from cluster about fields in query, and has information about partition key(s), so it's able to calculate token for data, and select the node. You can also specify the routing key youself, and driver will send request to corresponding node.

It's all explained in the documentation:

For simple statements, routing information can never be computed automatically

For built statements, the keyspace is available if it was provided while building the query; the routing key is available only if the statement was built using the table metadata, and all components of the partition key appear in the query

For bound statements, the keyspace is always available; the routing key is only available if all components of the partition key are bound as variables

For batch statements, the routing information of each child statement is inspected; the first non-null keyspace is used as the keyspace of the batch, and the first non-null routing key as its routing key

When statement doesn't have routing information, the request is sent to node selected by nested load balancing policy, and the node-coordinator, performs parsing of the statement, extract necessary information and calculates the token, and forwards request to correct node.

Community
  • 1
  • 1
Alex Ott
  • 80,552
  • 8
  • 87
  • 132
  • why can the node-coordinator calculate the token and the TokenAwarePolicy cannot? If the token is a function of my request, why can't it be calculated on the client? What confuses me is that the node-coordinator can do things that the Driver can't. They have the same information. – shaft May 30 '19 at 15:14
  • It may happen when you use "simple statement" for example - drivers don't have full CQL parser, and simply send text of statement to coordinator that has full CQL parser. In prepared statements - it's the same - driver send request to coordinator, but it returns back information about parsed statement - what field types, bindings, etc. – Alex Ott May 30 '19 at 15:38