You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "T Jake Luciani (JIRA)" <ji...@apache.org> on 2014/05/06 17:25:16 UTC
[jira] [Updated] (CASSANDRA-7168) Add repair aware consistency
levels
[ https://issues.apache.org/jira/browse/CASSANDRA-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
T Jake Luciani updated CASSANDRA-7168:
--------------------------------------
Description:
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.
was:
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.
> 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 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.2#6252)