Cassandra Architecture & Replication Factor

Cassandra is designed to handle Big Data. Cassandra’s main feature is to store data on multiple nodes with no single point of failure.

The reason for this kind of Cassandra’s architecture was that the hardware failure can occur at any time. Any node can be down. In case of failure data stored in another node can be used. Hence, Cassandra is designed with its distributed architecture.

Cassandra stores data on different nodes with a peer to peer distributed fashion architecture.

All the nodes exchange information with each other using Gossip protocol. Gossip is a protocol in Cassandra by which nodes can communicate with each other.

Components of Cassandra Architecture

There are following components in the Cassandra Architecture:

The diagram above nests the components: nodes sit inside a data center, data centers sit inside a cluster, and the commit log, memtable, and SSTable live inside every individual node.

Node

Node is the place where data is stored. It is the basic component of Cassandra.

Data Center

A collection of nodes are called data center. Many nodes are categorized as a data center.

Cluster

The cluster is the collection of many data centers.

Commit Log

Every write operation is written to Commit Log. Commit log is used for crash recovery.

Mem-table

After data written in Commit log, data is written in Mem-table. Data is written in Mem-table temporarily.

SSTable

When Mem-table reaches a certain threshold, data is flushed to an SSTable disk file. SSTables are immutable, so an update writes a new version rather than editing the old one, and a background process called compaction later merges those versions and discards the superseded rows.

Data Replication in Cassandra

As hardware problem can occur or link can be down at any time during data process, a solution is required to provide a backup when the problem has occurred. So data is replicated for assuring no single point of failure.

Cassandra places replicas of data on different nodes based on these two factors.

• Where to place next replica is determined by the Replication Strategy.
• While the total number of replicas placed on different nodes is determined by the Replication Factor.

One Replication factor means that there is only a single copy of data while three replication factor means that there are three copies of the data on three different nodes.

For ensuring there is no single point of failure, replication factor must be three.

There are two kinds of replication strategies in Cassandra.

SimpleStrategy in Cassandra

SimpleStrategy is used when you have just one data center. SimpleStrategy places the first replica on the node selected by the partitioner. After that, remaining replicas are placed in clockwise direction in the Node ring.

Here is the pictorial representation of the SimpleStrategy:

NetworkTopologyStrategy in Cassandra

NetworkTopologyStrategy is used when you have more than two data centers. In NetworkTopologyStrategy, replicas are set for each data center separately. NetworkTopologyStrategy places replicas in the clockwise direction in the ring until reaches the first node in another rack. This strategy tries to place replicas on different racks in the same data center.

This is due to the reason that sometimes failure or problem can occur in the rack. Then replicas on other nodes can provide data.

Here is the pictorial representation of the Network topology strategy:

The replication factor decides how many copies exist. How many of those copies must answer a given request is a separate setting, described next.

Consistency Levels in Cassandra

Consistency level is set per query rather than per cluster, which is what makes Cassandra tunable. It states how many replicas must acknowledge a write, or respond to a read, before the coordinator answers the client. A low level returns faster; a high level returns data that is more certainly current.

Level	Behaviour	Typical use
ONE	One replica must respond.	High-throughput logging where an occasional stale read is acceptable.
QUORUM	A majority of all replicas must respond, calculated as (RF / 2) + 1.	The general-purpose choice for balanced consistency and availability.
LOCAL_QUORUM	A majority of replicas within the local data centre must respond.	Multi-data-centre clusters, because it avoids cross-region latency.
ALL	Every replica must respond.	Rare. One node down makes the request fail entirely.
ANY (writes only)	A hinted handoff counts as success even if no replica is reachable.	Maximum write availability where durability can be relaxed.

Strong consistency is guaranteed when the read level plus the write level exceeds the replication factor. With a replication factor of three, writing at QUORUM and reading at QUORUM satisfies that rule, because two plus two is greater than three. Writing at ONE and reading at ONE does not, and a read may therefore return an older value.

When a replica is unreachable, the coordinator stores a hint and replays it once the node returns, which is how the ANY level and much of Cassandra’s self-healing behaviour work.

Write Operation in Cassandra

The coordinator sends a write request to replicas. If all the replicas are up, they will receive write request regardless of their consistency level.

Consistency level determines how many nodes will respond back with the success acknowledgment.

The node will respond back with the success acknowledgment if data is written successfully to the commit log and memTable.

For example, in a single data center with replication factor equals to three, three replicas will receive write request. If consistency level is one, only one replica will respond back with the success acknowledgment, and the remaining two will remain dormant.

Suppose if remaining two replicas lose data due to node downs or some other problem, Cassandra will make the row consistent by the built-in repair mechanism in Cassandra.

Here it is explained, how write process occurs in Cassandra,

1. When write request comes to the node, first of all, it logs in the commit log.
2. Then Cassandra writes the data in the mem-table. Data written in the mem-table on each write request also writes in commit log separately. Mem-table is a temporarily stored data in the memory while Commit log logs the transaction records for back up purposes.
3. When mem-table is full, data is flushed to the SSTable data file.

Because SSTables are never edited in place, a delete does not remove the row immediately. Instead a marker called a tombstone is written, and the row disappears only when compaction runs after the grace period. This is why heavy delete workloads slow reads until compaction catches up.

Read Operation in Cassandra

There are three types of read requests that a coordinator sends to replicas.

1. Direct request
2. Digest request
3. Read repair request

The coordinator sends direct request to one of the replicas. After that, the coordinator sends the digest request to the number of replicas specified by the consistency level and checks whether the returned data is an updated data.

After that, the coordinator sends digest request to all the remaining replicas. If any node gives out of date value, a background read repair request will update that data. This process is called read repair mechanism.

Inside the replica that receives the direct request, the lookup order is designed to avoid touching disk wherever possible.

1. The memtable is checked first, since the newest writes have not yet been flushed.
2. The row cache, if enabled, can answer the whole request without further work.
3. A bloom filter is consulted for each SSTable. It answers definitely not present or possibly present, which lets most SSTables be skipped without reading them.
4. The partition index and its summary locate the exact byte offset within any SSTable that survives the bloom filter check.
5. Matching fragments from several SSTables are merged, with the most recent timestamp winning for each column.

The bloom filter is the step that keeps reads fast as data grows, because it removes almost every SSTable from consideration before any disk seek occurs. Applying these mechanics across several machines is covered in the Cassandra cluster tutorial.

FAQs