Cassandra's design was based on Google's Bigtable and Amazon's DynamoDB, and it was developed at Facebook. Later on, it was open sourced to Apache Foundation. It is a NoSQL nonrelational database. While working with Cassandra, we need not worry about normalization of our tables, as Cassandra promotes denormalization of your database tables. In Cassandra, the database schema is designed based on the data that you would be reading from or writing to Cassandra.

Cassandra focuses on availability and partition tolerance among consistency, availability, and partition tolerance of the CAP theorem by Brewer. The CAP theorem states that, among consistency, availability, and partition tolerance, you can pick only two at a time. Here, consistency means when you read from or write to any node of the cluster, you should get the same up-to-date data. Availability refers to the fact that we should be able to access the cluster even if some node in the cluster is down, and partition tolerance...

As mentioned earlier, Cassandra is a peer to peer cluster—no node is master or slave. Data is distributed among all nodes of the cluster using partitioners. This enables Cassandra to shard data transparently, and allows it to scale linearly. This means that Cassandra server performs the data sharding, and the application layer need not implement any additional logic for sharding. As the load grows, new nodes can be added to share the load as Cassandra will distribute the load among them automatically.

For example, let's imagine that we initially have three node cluster, which are capable of handling 3x transactions. Now, suppose that the load is increased to 4x, then we can add one additional node to the cluster without doing any change in our application layer. The following image shows the example where initially we have a three-node cluster with nodes A, B, and C capable of handling load 1x each; hence, the capacity of handling load of 1x + 1x + 1x = 3x. However...

One of the key features of Cassandra is auto-sharding. Data is distributed among nodes in a cluster based on partition keys automatically. A partition key is a column or multiple columns, which are part of a primary key of a column family. Data is distributed based on the tokenized value calculated over the partition key. A partitioner determines how distribution tokens are calculated. Each node of Cassandra cluster its owns a range of tokens. A row is stored on the node that owns the respective token of the row's partition key.

A partitioner can be set using the configuration option partitioner in cassandra.yaml. The new cluster should go with Murmur3Partitioner, as it is a faster partitioner than older ones and also distributes data more efficiently. Other partitioners for backward compatibility are RandomPartitioner, ByteOrderedPartitioner, and OrderPreservingPartitioner.

Here is a brief description of all the listed partitioners:

Cassandra is able to automatically keep multiple copies of data on multiple nodes, hence providing no single point of failure. The number of copies it will create is configurable and determined by a configuration option called a replication_factor. While defining a keyspace, we mention its replication_factor function. This configuration option is applied to all column families of that keyspace. Let's suppose that column family users, which we discussed in the section Data distribution, are part of the keyspace called cassandrademodb; and replication_factor of the keyspace is 3, then every row of the column family users will have three replicas copied to three different nodes. All replicas are the same and there is no primary or secondary replica. First, replica placement is decided by the partitioner and subsequent replicas are placed on consecutives nodes in clockwise order. Cassandra tries not to have two replicas on the same rack while doing so for rack-aware strategies, using...

The SimpleStrategy is a basic replication strategy. It's used when using a single datacenter. This method is rack unaware. It places replicas on subsequent nodes in a clockwise order.

Here is a sample CQL command to create a keyspace with SimpleStrategy and a replication factor of 3, which can be fired from the cqlsh prompt:

cqlsh>  CREATE KEYSPACE cassandrademodb WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };