[
https://issues.apache.org/jira/browse/CASSANDRA-13442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972697#comment-15972697
]
Sylvain Lebresne commented on CASSANDRA-13442:
----------------------------------------------
bq. Man, this makes me really nervous.
bq. Optimizing away redundant queries a la 7168? Sign me up. But I think
removing that "redundant" data and making RF not actually mean RF is going too
far.
I very much second those sentiments.
bq. It will be opt in at the keyspace level and won't affect anyone who dont
want to use it.
Maybe that's meant to be a response to Jonathan's concern I'm quoting (and
agreeing with) above. In which case I want to point out that, as also said
above, this will imo add quite a bit of complexity to existing code, so I very
strongly disagree with the argument that having it opt-in from the user point
of view equates it to affecting no-one that don't want to use it.
bq. I think it's worth characterizing as much as possible what it's going to
cost before dismissing it
Sure and I, for one, certainly won't claim having put tons of though into this
yet, and I'm happy to see a much more precise analysis of the costs.
But I'll admit that my "gut feeling" (my 6+-years-working-on-C*-gut feeling) is
that this will get pretty complex especially when you throw up node movements
and potential data loss into the mix, and that it's not worth that complexity.
> Support a means of strongly consistent highly available replication with
> storage requirements approximating RF=2
> ----------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-13442
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13442
> Project: Cassandra
> Issue Type: Improvement
> Components: Compaction, Coordination, Distributed Metadata, Local
> Write-Read Paths
> Reporter: Ariel Weisberg
>
> Replication factors like RF=2 can't provide strong consistency and
> availability because if a single node is lost it's impossible to reach a
> quorum of replicas. Stepping up to RF=3 will allow you to lose a node and
> still achieve quorum for reads and writes, but requires committing additional
> storage.
> The requirement of a quorum for writes/reads doesn't seem to be something
> that can be relaxed without additional constraints on queries, but it seems
> like it should be possible to relax the requirement that 3 full copies of the
> entire data set are kept. What is actually required is a covering data set
> for the range and we should be able to achieve a covering data set and high
> availability without having three full copies.
> After a repair we know that some subset of the data set is fully replicated.
> At that point we don't have to read from a quorum of nodes for the repaired
> data. It is sufficient to read from a single node for the repaired data and a
> quorum of nodes for the unrepaired data.
> One way to exploit this would be to have N replicas, say the last N replicas
> (where N varies with RF) in the preference list, delete all repaired data
> after a repair completes. Subsequent quorum reads will be able to retrieve
> the repaired data from any of the two full replicas and the unrepaired data
> from a quorum read of any replica including the "transient" replicas.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
