cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4858) Coverage analysis for low-CL queries
Date Mon, 14 Jan 2013 11:22:12 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552588#comment-13552588
] 

Sylvain Lebresne commented on CASSANDRA-4858:
---------------------------------------------

bq. but scores are really helped in the past returning the queries within SLA's

I agree, and the goal of the patch is certainly not to deny that. The question is, if you
can merge 2 queries into 1, at which point do you decide it's not worth it based on the endpoints
scores. I think it is safe to say that in most case, picking 1 query over 2 will be the best
option. That being said, if you do happen to have a very very slow node that the intersection
would pick while doing 2 query would only pick very fast nodes, then you might be worth off
doing the 1 query. So along with a rebase of the previous patch I'm attaching a 2nd patch
that adds an heuristic to the dynamic snitch that tries to avoid that. The heuristic being
that if the average score of the intersection of 2 replica set is twice as bad (I'll admit
that the 'twice' here is a bit random and might not be appropriate) as the average score of
one of the replica set, then we ignore the intersection. It's probably not the best heuristic
though, but it has the advantage of being simple.
                
> Coverage analysis for low-CL queries
> ------------------------------------
>
>                 Key: CASSANDRA-4858
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4858
>             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-v3-1.txt,
4858-v3-2.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: http://www.atlassian.com/software/jira

Mime
View raw message