Token-aware request routing
Support token-aware host selection in load-balancing policies. The rough outline is as follows:
-
Since CQL protocol version 4, the response metadata for
Prepared
responses contains indicators for which positions in the parameters belong to the partition key of the table, which simplifies things. See CASSANDRA-7660 and the corresponding commit. -
When executing a prepared statement, knowing which values make up the partition key, that knowledge can be used to construct the token corresponding to the partition key values and hence which nodes in the ring are currently responsible for the row. The latter information can be obtained from the
system.peers
table and we may want to permanently attach it to theHost
data type. In that context, it may be a good idea to attach a timestamp to aHost
in order to occasionally trigger a refresh of its metadata, since the list of tokens of a host may change over time. Using stale information for a while is not a problem in this scenario. -
Token-aware routing should probably just be enabled / disabled via a new flag on a
Policy
, with an indicator that it is V4-only and requires the use of prepared statements. While other client drivers also support some form of explicitly identifying the partition keys for other kinds of queries, I think limiting it to prepared statements is the best thing to do for cql-io, as it seems to provide a good effort to gain ratio.
The overall motivation for token-aware request routing is to save some network traffic and indirection, as the coordinator of the query will then almost always already be one of the responsible replicas. See also the Java driver documentation.