Cassandra - Getting Started With The Architecture

Understanding That Cassandra Is A Distributed Database
Cassandra is a distributed database, all nodes in cluster has same functionality when compared with each other. There is no master or slave nodes thus eliminating the single point of failure. Data is replicated across the nodes to high availability.

In Cassandra, cluster can easily be spread across more than one data center allowing for high availability even if one data center completely goes down.

Cassandra Documentation is available at - http://www.datastax.com/docs

Snitch: Snitch is how the nodes in a cluster know about the topology of the cluster
Ways to Define Snitch:
- Dynamic Snitching: Monitors the performance of reads from the various replicas and chooses the best replica based on this history
- SimpleSnitch: For single-data center deployments only.
- RackInferringSnitch: Determines the location of nodes by rack and data center corresponding to the IP addresses.
- PropertyFileSnitch: Determines the location of nodes by rack and data center.
- GossipingPropertyFileSnitch: Automatically updates all nodes using gossip when adding new nodes.
- EC2Snitch: Use with Amazon EC2 in a single region.
- EC2MultiRegionSnitch: Use with Amazon EC2 in multiple regions.
- GoogleCloudSnitch
- CloudstackSnitch

Gossip: Gossip is how the nodes in a cluster communicate to each other.
Every ONE second, each node communicates with up to three other nodes, exchanging information about itself and all the other nodes that it has information about.
Gossip is the internal communication method for nodes in a cluster to talk to each other.

For external communication, such as from an application to a Cassandra database, CQL(Cassandra Query Language) or Thrift are used.

How data distribution is done across the Nodes in Cassandra ?
Data Distribution is done through consistent hashing algorithm, to strive for even distribution of data across the nodes in a cluster.
Rather than all of the rows of a table existing on only on node, the rows are distributed across the nodes in the cluster, in an attempt to evenly spread out the load of the table’s data.
For example, notice the following rows of data, to be inserted in a table within a Cassandra database. (The data will be spread across the nodes based on the hash algorithm used which is illustrated below)



To distribute the rows across the nodes, a Partitioner is used.
The Partitioner uses an algorithm to determine which node a given row of data will go to
The default partitioner in Cassandra is Murmur3

Murmur3 takes the values in the first column* (Depending upon the table definition more than one column can also be used by Partitioner Murmur3) of the row to generate a unique number between  -2⁶³ and 2⁶³.

So based on the hashing algorithm the above table Home_ID column row data turn into as below
H01033638 –>  -7456322128261119046
H01545551 –>  -2487391024765843411
H00999943 –>  6394005945182357732

Similarly each node in a cluster has an end point value assigned to it manually which decides which row data will get distributed to which node. Each node is responsible for the token values between its endpoint and the endpoint of the previous node.


Therefore, the –7456322128261119046 data is owned by the –4611686018427387904 node



Node token ranges are calculated using the below formula or Murmur3 calculator - http://www.geroba.com/cassandra/cassandra-token-calculator/



Replication: A Replication Factor must be specified whenever a database is defined.
The Replication Factor specifies how many instances  of the data there will be within a given database.
Although 1 can be specified, it is common to specify 2, 3, or more, so that if a node goes down, there is at least one other replica of the data, so that the data is not lost with the down node. 

Virtual Nodes: Virtual nodes are an alternative way to assign token ranges to nodes, and are now the default in Cassandra.
With virtual nodes, instead of a node being responsible for just one token range, it is instead responsible for many small token ranges (by default, 256 of them)
Virtual nodes allow for assigning a high number of ranges to a powerful computer (e.g: 512) and a lower number of ranges (e.g: 128) to a less powerful computer.
Virtual nodes (aka vnodes) were created to make it easier to add new nodes to a cluster while keeping the cluster balanced.
When a new node is added, it receives many small token range slices from the existing nodes, to maintain a balanced cluster.
With the old way, of static token ranges, it was common to double the number of nodes, so that the end-point for the new nodes could be a value half of the value of the existing end-points.