cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-4858) Coverage analysis for low-CL queries
Date Wed, 16 Jan 2013 16:36:13 GMT


Sylvain Lebresne updated CASSANDRA-4858:

    Attachment: 4858-v4.txt

bq. On the snitch heuristics, can we just say "if latency(b) > latency(a) + latency(c),
then don't merge?"

That's kind of what we want, though we want to do that on the final list of replica that is
going to be queried (for the first range, the 2nd one and their union). And because it is
currently ReadCallback (created after we've made the decision of merging or not the ranges)
that compute that final list of endpoints, I've been too lazy to do that properly. But that
was a mistake, so attaching a v4 that refactor things a little more (pulling the filtering
of the final endpoints out of ReadCallback basically) to do this ticket properly.

With that, we end up having the dynamic snitch heuristic being something like:
if (maxScore(endpointsFor(A and B)) > maxScore(endpointsFor(A)) + maxScore(endpointsFor(B)))
    // don't merge
It's maxScore since we're dealing with lists of endpoints and it's the max latency that will
define the total latency of the read.

I note that this v4 includes Jonathan's cleanup. As commented in that cleanup patch, there
is probably simplification to be gained by moving the Table inside ConsistencyLevel, but let's
maybe do that in a follow-up ticket?

> Coverage analysis for low-CL queries
> ------------------------------------
>                 Key: CASSANDRA-4858
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>             Fix For: 1.2.1
>         Attachments: 0001-CASSANDRA-4858.patch, 0001-CASSANDRA-4858-v2.patch, 4858-cleanup.txt,
4858-v3-1.txt, 4858-v3-2.txt, 4858-v4.txt
> There are many cases where getRangeSlice creates more
> RangeSliceCommand than it should, because it always creates one for each range
> returned by getRestrictedRange.  Especially for CL.ONE this does not take
> the replication factor into account and is potentially pretty wasteful.
> A range slice at CL.ONE on a 3 node cluster with RF=3 should only
> ever create one RangeSliceCommand.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message