[ https://issues.apache.org/jira/browse/CASSANDRA-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14502981#comment-14502981 ]
Sylvain Lebresne commented on CASSANDRA-7168: --------------------------------------------- bq. I'd rather just apply this as an optimization to all CL > ONE, replacing the data/digest split that is almost certainly less useful. I'll admit that I find this a bit scary. This means relying on the repaired time in a way that I personally don't feel yet very comfortable with. At the very least, I think we should preserve the option to do full data queries. And as much as I understand the willingness to simplify the code, I would personally be a lot more comfortable if this was living aside the existing mechanism at first. I can agree however than having a specific CL is weird since that really apply to pretty much all CL. I'd be fine with adding a flag in the native protocol to allow or disallow that feature for instance. > Add repair aware consistency levels > ----------------------------------- > > Key: CASSANDRA-7168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7168 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: T Jake Luciani > Labels: performance > Fix For: 3.1 > > > With CASSANDRA-5351 and CASSANDRA-2424 I think there is an opportunity to > avoid a lot of extra disk I/O when running queries with higher consistency > levels. > Since repaired data is by definition consistent and we know which sstables > are repaired, we can optimize the read path by having a REPAIRED_QUORUM which > breaks reads into two phases: > > 1) Read from one replica the result from the repaired sstables. > 2) Read from a quorum only the un-repaired data. > For the node performing 1) we can pipeline the call so it's a single hop. > In the long run (assuming data is repaired regularly) we will end up with > much closer to CL.ONE performance while maintaining consistency. > Some things to figure out: > - If repairs fail on some nodes we can have a situation where we don't have > a consistent repaired state across the replicas. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)