You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Ryan Svihla <rs...@foundev.pro> on 2017/03/09 16:51:42 UTC

Consistency improvement idea for cutting down on the new user ramp up time.

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