cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7168) Add repair aware consistency levels
Date Tue, 06 May 2014 01:27:14 GMT

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

T Jake Luciani commented on CASSANDRA-7168:
-------------------------------------------

1) only gives you part of the result.  It will only be correct as-of the last repair time.
 But 2) is all the latest data including what is in the memtable.

The idea is the coordinator takes the result of 1) and merges in 2) to get the complete consistent
view of the result.  So there could be the case where in repaired data a row existed but in
a subsequest write in the memtable it was tombstoned.  In this case the corrdinator would
see the tomstone and the result would not include the cell from the repaired result. The same
way we deal with merging multiple sstables together.

> 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.0
>
>
> With CASSANDRA-5351 and CASSANDRA-2424 I think there is an opportunity to avoid a lot
of extra work 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.2#6252)

Mime
View raw message