Data Consistency in Apache Cassandra — Part 2

Rajendra Uppal
Aug 24, 2017 · 3 min read

In part 1, I introduced the basics of consistency in general, write consistency, read consistency, consistency levels (CL), immediate, eventual and tunable consistency.

In this part 2, I will talk about how to achieve immediate and eventual consistency using different write and read consistency levels.

Source: http://guide.couchdb.org/draft/consistency.html

Cassandra has tunable consistency which means that not only on the database level, you can tune the immediate and eventual consistency of your data per query/operation by setting the read CL (consistency level) and write CL.

Immediate Consistency

Immediate Consistency is the ability of the database to always return the most recent data as we recall from part 1.

Immediate Consistency Formula

R + W > RF => immediate consistency

where R= number of nodes your data is read from.

W= number of nodes your data is written to.

RF= replication factor, how many nodes have exact same copy of your data.

Example: if you have replication factor as 3, i.e. 3 nodes are going to have exact same copy of your data, write CL as QUORUM, i.e. you are going to write to majority or 2 nodes and read CL as QUORUM, i.e. you are going to read from majority or 2 nodes, then you can see from the formula that you are going to have immediate consistency.

Eventual Consistency

Eventual Consistency is not having your data completely out of sync. EC is a situation where:

In practice, data is consistent on all nodes within a few milliseconds, you will get exact same data from your queries very often. But, you are NOT getting a guarantee. So, if you have an SLA that you need to meet for your application that requires that data is always fully consistent, then tune those queries for immediate consistency whereas for other queries where performance is more important, tune those queries for eventual consistency.

Achieving Immediate Consistency across Entire Cluster

There are 3 ways you can achieve IC across entire cluster:

1. Read optimized, set Write CL = ALL, Read CL = ONE

As you are setting write CL as ALL, you are going to write data to all nodes in your cluster which means you can read from any one of them, hence read CL = ONE and hence this configuration is read optimized.

2. Write optimized, set Write CL = ONE, Read CL = ALL

As you are writing to 1 node, this configuration is write optimized and as you are reading from all nodes, one is them is guaranteed to have the most recent data which will be found out by the coordinator and sent back to you.

3. Balanced, set Write CL = QUORUM, Read CL = QUORUM

QUORUM means you are writing/reading to/from simple majority number of the nodes in your cluster. This configuration is a great balance in this configuration. You get high performance reads and writes.

You’d never want to set write CL = ALL, read CL = ALL. Because it is redundant, you get no benefit of this configuration and you’re only going to reduce throughput, and performance as well as lower availability.

Achieving Immediate Consistency across local Data Center

  1. Read optimized, set Write CL = ALL, Read CL = LOCAL_ONE
  2. Write optimized, set Write CL = LOCAL_ONE, Read CL = ALL
  3. Balanced, set Write CL = LOCAL_QUORUM, Read CL = LOCAL_QUORUM

If your cluster has multiple data centers in say A, B and C cities. Using this configuration, you can optimize for your users in a particular data center and their requests won’t go to other data centers.

Achieving Eventual Consistency

  1. Entire Cluster, set Write CL = ONE, Read CL = ONE
  2. Local Data Center, set Write CL = LOCAL_ONE, Read CL = LOCAL_ONE

This is configuration is performance optimized. As we know, data sync across all nodes is few milliseconds away, so you get great performance using this configuration. So, you give up few milliseconds of consistency here and get highest throughput, highest performance and highest availability.

In next part 3, we will go a bit deeper into each of the above configurations and will understand different consistency levels.

Comments and thoughts welcome. Cheers!

Software Architecture

All things software design and architecture

)

Rajendra Uppal

Written by

AVP Engineering @ inFeedo | www.linkedin.com/in/rajendrauppal

Software Architecture

All things software design and architecture

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade