If lower consistency level is good then why we need to have a higher consistency(QUORUM,ALL) level in Cassandra?

Question

While going through Datastax tutorial I learned that 1)Lower consistency level is quicker for read and write whereas, it's much longer if we use higher consistency level 2) Lower consistency level also ensures high availability of data.

My question is if Lower CL is good then we can always set CL as ONE, why do we need QUORUM and ALL consistency levels?

Answer 1

It ultimately depends on the application using Cassandra. If the application is ok with serving up data that may be under-replicated or slightly stale, then LOCAL_ONE should be fine. If the application absolutely cannot provide a wrong answer, or if written rows are not being successfully read consistently, then perhaps LOCAL_QUORUM may be more applicable.

I tell my application teams the same thing. Start with LOCAL_ONE , and and work with it through testing. If you don't have any problems, then continue using it. If you do experience stale data, and your application is more read-sensitive, then try writing at LOCAL_QUORUM and continue reading at LOCAL_ONE . And if that doesn't help, then perhaps the application may need both at QUORUM.

Again, that's why application teams need to do thorough testing.

And just to address it, ALL is a useful consistency level because it invokes a read repair. Essentially, if you have a table which you know is missing data, and you don't want to run a costly nodetool repair on it, you can set your consistency to ALL and read from it. I find this trick to be most-useful when addressing issues with multi-DC clusters having issues with system_auth .

But you probably wouldn't want to use ALL from within an application. Or if you did, it'd be for a very specific edge case.

Answer 2

The real meat of database like Cassandra is " eventual consistency ": it won't enforce strong consistency when you first write data to the database. rather, it gives you option to choose a weaker consistency level like "one" to reach high writing performance, and then later when you query data, as long as this rule " Read_Consistency_level + Write_consistency_level >= the RF policy (Replication factor) " satisfies, you won't have stale data.

It's risky if you can't fulfill the above rule since you might get either stale or contradictory (sometimes new, sometimes old) data.