[
https://issues.apache.org/jira/browse/CASSANDRA-13315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905491#comment-15905491
]
Jon Haddad commented on CASSANDRA-13315:
----------------------------------------
Seems like picking an event number of replicas should warn the user, regardless
of this JIRA.
> Semantically meaningful Consistency Levels
> ------------------------------------------
>
> Key: CASSANDRA-13315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13315
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Ryan Svihla
>
> New users really struggle with consistency level and fall into a large number
> of tarpits trying to decide on the right one.
> o
> 1. There are a LOT of consistency levels and it's up to the end user to
> reason about what combinations are valid and what is really what they intend
> it to be. Is there any reason why write at ALL and read at CL TWO is better
> than read at CL ONE?
> 2. They require a good understanding of failure modes to do well. It's not
> uncommon for people to use CL one and wonder why their data is missing.
> 3. The serial consistency level "bucket" is confusing to even write about and
> easy to get wrong even for experienced users.
> So I propose the following steps (EDIT based on Jonathan's comment):
> 1. Remove the "serial consistency" level of consistency levels and just have
> all consistency levels in one bucket to set, conditions still need to be
> required for SERIAL/LOCAL_SERIAL
> 2. add 3 new consistency levels pointing to existing ones but that infer
> intent much more cleanly:
> EDIT better names bases on comments.
> * EVENTUALLY = LOCAL_ONE reads and writes
> * STRONG = LOCAL_QUORUM reads and writes
> * SERIAL = LOCAL_SERIAL reads and writes (though a ton of folks dont know
> what SERIAL means so this is why I suggested TRANSACTIONAL even if its not as
> correct as Id like)
> for global levels of this I propose keeping the old ones around, they're
> rarely used in the field except by accident or particularly opinionated and
> advanced users.
> Drivers should put the new consistency levels in a new package and docs
> should be updated to suggest their use. Likewise setting default CL should
> only provide those three settings and applying it for reads and writes at the
> same time.
> CQLSH I'm gonna suggest should default to HIGHLY_CONSISTENT. New sysadmins
> get surprised by this frequently and I can think of a couple very major
> escalations because people were confused what the default behavior was.
> The benefit to all this change is we shrink the surface area that one has to
> understand when learning Cassandra greatly, and we have far less bad initial
> experiences and surprises. New users will more likely be able to wrap their
> brains around those 3 ideas more readily then they can "what happens when I
> have RF2, QUROUM writes and ONE reads". Advanced users get access to all the
> way still, while new users don't have to learn all the ins and outs of
> distributed theory just to write data and be able to read it back.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
