I don't disagree with you there and have never liked TWO/THREE. This is somewhat relevant: https://issues.apache.org/jira/browse/CASSANDRA-2338
I don't think going to CL.FOUR, etc, is a good long-term solution, but I'm also not sure what is. On Thu, Jun 8, 2017 at 11:20 PM, Dikang Gu <dikan...@gmail.com> wrote: > To me, CL.TWO and CL.THREE are more like work around of the problem, for > example, they do not work if the number of replicas go to 8, which does > possible in our environment (2 replicas in each of 4 DCs). > > What people want from quorum is strong consistency guarantee, as long as > R+W > N, there are three options: a) R=W=(n/2+1); b) R=(n/2), W=(n/2+1); c) > R=(n/2+1), W=(n/2). What Cassandra doing right now, is the option a), which > is the most expensive option. > > I can not think of a reason, that people want the quorum read, not for > strong consistency reason, but just to read from (n/2+1) nodes. If they > want strong consistency, then the read just needs (n/2) nodes, we are > purely waste the one extra request, and hurts read latency as well. > > Thanks > Dikang. > > On Thu, Jun 8, 2017 at 8:20 PM, Nate McCall <n...@thelastpickle.com> > wrote: > >> >> We have CL.TWO. >>> >>> >>> >> This was actually the original motivation for CL.TWO and CL.THREE if >> memory serves: >> https://issues.apache.org/jira/browse/CASSANDRA-2013 >> > > > > -- > Dikang > >
