Would love to see real pluggable consistency levels. Sorta sad it got wont-fixed - may be time to revisit that, perhaps it's more feasible now.
https://issues.apache.org/jira/browse/CASSANDRA-8119 is also semi-related, but a different approach (CL-as-UDF) On Thu, Jun 8, 2017 at 9:26 PM, Brandon Williams <dri...@gmail.com> wrote: > 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 > > > > >
