Cassandra - client side load balancing

6
votes

Consider following Cassandra setup:

  • ring of 6 nodes: A, B, D, E, F, G
  • replication factor: 3
  • partitioner: RandomPartitioner
  • placement strategy: SimpleStrategy

My Test-Column is stored on node B and replicated to nodes D and E.

Now I have multiple java processes reading my Test-Column trough Hector API (Thrift) with read CL.ONE

There are two possibilities:

  1. Hector will forward all calls to node B, because B is the data master
  2. Hector will load balance read calls trough node B, D and E (master and replicates). In this case my test column would be loaded into cache on each Cassandra instance.

Which one is it 1) or 2) ?

Thanks and regards, Maciej

2
cassandra

2 Answers

4
votes

I believe it is: 3) Cassandra forwards all calls to the closest node that is alive, where "closeness" is determined by the Snitch currently being used (set in cassandra.yaml).

  • SimpleSnitch chooses the closest node on the token ring.
  • AbstractNetworkTopologySnitch and derived snitches first try to choose nodes in the same rack, then nodes in the same datacenter.

If DynamicSnitch is enabled, it dynamically adjusts the node closeness returned by the underlying snitch, according to the nodes' recent performance.

See Cassandra ArchitectureInternals under "Read Path" for more information.

2
votes

(Upvoted Theodore's answer because it is corect). Some additional details:

We do nothing on the hector side to route traffic to a given node based on the key (yet). This was referred to as "client mediated selects" in section 6.2 of the Amazon Dynamo paper. The research seems to indicate that it really only is useful for very large clusters by cutting out a network hop.

The downside would be the duplication of hashing computation and partitioner lookup on the client.