I posted this Jira here already https://issues.apache.org/jira/browse/CASSANDRA-13315 but I wanted to toss it out there on the mailing list at the same time to get some broader feedback.
I've been supporting users a few years and during that time I've had 2-5 conversations a week about what is the correct Consistency Level for a given user depending on their needs and use case. This usually takes quite awhile and pays my bills so I'm happy for the work, but it's occurred to me I see three very common patterns: 1. People want maximum availability and throughput and don't care if things are inconsistent for awhile 2. People want maximum consistency and even want to be able to 'read my writes' 3. People want a mix of both and can tolerate not being able to "read my writes" There are of course a long tail of weird combinations of CLs after that with advanced users, admittedly I often dig and find issues with the consistency in their thought process as well and so they're cutting across their own goals often, but I grant there are valid tradeoffs to be had outside of the 3 above. Toss in the idea of global versions of these three and you arguably come to 6. So the above Jira is may attempt to address this in a larger fashion. To summarize the Jira some: 1. remove the 'serial consistency' bucket it confuses everyone. likewise require a condition for inserts if SERIAL/LOCAL_SERIAL is used 2. have 3 new CLs that you set for both reads and writes EVENTUALLY_CONSISTENT (LOCAL_ONE), HIGHLY_CONSISTENT (LOCAL_QUORUM), TRANSACTIONALLY_CONSISTENT (LOCAL_SERIAL) this minimize the amount that people need to think about CL and what is the correct starting point for their first application, and would have prevented some awful escalations I've seen. (I'm open for other names and including global levels). 3. set CQLSH to HIGHLY_CONSISTENT by default, new sysadmins for Cassandra are often using CQLSH to spelunk for complaints or missing data and while those in the know set it higher when doing that, it's a frequent problem that the CL ONE default is a surprise to the new user. CLQSH is not a performance sensitive use often either and when it use the other CLs are there. The end goal whatever shape this takes is it should match up with people's expectations that are new to Cassandra more consistently and not require advanced learnings in distributed theory, when put this way, the correct CL choice takes seconds and is often self evident. -- Thanks, Ryan Svihla