incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Doubleday <daniel.double...@gmx.net>
Subject Re: Dynamic Snitch / Read Path Questions
Date Tue, 14 Dec 2010 00:43:31 GMT
On 13.12.10 21:15, Brandon Williams wrote:
> On Sun, Dec 12, 2010 at 10:49 AM, Daniel Doubleday 
> <daniel.doubleday@gmx.net <mailto:daniel.doubleday@gmx.net>> wrote:
>
>     Hi again.
>
>     It would be great if someone could comment whether the following
>     is true or not.
>     I tried to understand the consequences of using
>     |-Dcassandra.dynamic_snitch=true for the read path |and that's
>     what I came up with:
>
>     1) If using CL > 1 than using the dynamic snitch will result in a
>     data read from node with the lowest latency (little simplified)
>     even if the proxy node contains the data but has a higher latency
>     that other possible nodes which means that it is not necessary to
>     do load-based balancing on the client side.
>
>
> No.  If the coordinator node is part of the replica set, the dynamic 
> snitch will fall back to the wrapped snitch for ordering, since it 
> does not track latencies of itself.  This likely means it will return 
> the data.
Oh - well but I see that the coordinator is actually using its own score 
for ordering. I was only concerned that dropped messages are ignored 
when calculating latencies but that seems to be the case for local or 
remote responses. And even than I guess you can assume that enough slow 
messages arrive to destroy the score.
>
>     The next one goes a little further:
>
>     We read / write with quorum / rf = 3.
>
>     It seems to me that it wouldn't be hard to patch the StorageProxy
>     to send only one read request and one digest request. Only if one
>     of the requests fail we would have to query the remaining node. We
>     don't need read repair because we have to repair once a week
>     anyways and quorum guarantees consistency. This way we could
>     reduce read load significantly which should compensate for latency
>     increase by failing reads. Am I missing something?
>
>
> Just turn off read repair in that case.
Maybe I misunderstand but that would not really lead to less load right. 
I don't think that inconsistency / read repairs are the problem which 
leads to high io load but the digest requests. Turning off read repair 
would also lead to inconsistent reads which invalidates the whole point 
of quorum reads (at least in 0.6. I think rr probability has no effect 
in strong reads in 0.7) . Again assuming I am not misinterpreting the code.
>
> -Brandon


Mime
View raw message