Is the driver doing the right thing by directing all reads for a given
token to the same node? If that node fails, then all of those reads
will be directed at other nodes, all oh whom will be cache-cold for the
the failed node's primary token range. Seems like the driver should
distribute reads among the all the replicas for a token, at least as an
option, to keep the caches warm for latency-sensitive loads.
On 03/26/2017 07:46 PM, Eric Stevens wrote:
Yes, throughput for a given partition key cannot be improved with
horizontal scaling. You can increase RF to theoretically improve
throughput on that key, but actually in this case smart clients might
hold you back, because they're probably token aware, and will try to
serve that read off the key's primary replica, so all reads would be
directed at a single node for that key.
If you're reading at CL=QUORUM, there's a chance that increasing RF
will actually reduce performance rather than improve it, because
you've increased the total amount of work to serve the read (as well
as the write). If you're reading at CL=ONE, increasing RF will
increase the chances of falling afoul of eventual consistency.
However that's not really a real-world scenario. Or if it is,
Cassandra is probably the wrong tool to satisfy that kind of workload.
On Thu, Mar 23, 2017 at 11:43 PM Alain Rastoul <alf.mmm....@gmail.com
<mailto:alf.mmm....@gmail.com>> wrote:
On 24/03/2017 01:00, Eric Stevens wrote:
> Assuming an even distribution of data in your cluster, and an even
> distribution across those keys by your readers, you would not
need to
> increase RF with cluster size to increase read performance. If
you have
> 3 nodes with RF=3, and do 3 million reads, with good
distribution, each
> node has served 1 million read requests. If you increase to 6
nodes and
> keep RF=3, then each node now owns half as much data and serves only
> 500,000 reads. Or more meaningfully in the same time it takes
to do 3
> million reads under the 3 node cluster you ought to be able to do 6
> million reads under the 6 node cluster since each node is just
> responsible for 1 million total reads.
>
Hi Eric,
I think I got your point.
In case of really evenly distributed reads it may (or should?)
not make
any difference,
But when you do not distribute well the reads (and in that case only),
my understanding about RF was that it could help spreading the load :
In that case, with RF= 4 instead of 3, with several clients
accessing keys
same key ranges, a coordinator could pick up one node to handle
the request
in 4 replicas instead of picking up one node in 3 , thus having
more "workers" to handle a request ?
Am I wrong here ?
Thank you for the clarification
--
best,
Alain
