Apache Cassandra: The Crash-Proof NoSQL Database

The last time I wrote on NoSQL databases in February 2011, the technology was already booming. Today, these databases have changed the way developers think about building their applications, making them look beyond RDBMS back-ends to even handle data on a massive scale. Some very unique data models that were earlier impossible with conventional databases are now possible with NoSQL databases and clustering. One such NoSQL database is Cassandra, which was donated to Apache by Facebook in 2008.

Cassandra's most enticing and central feature is that it is decentralised and has no single point of failure. It is a column-oriented database, which was initially inspired and based on Amazon's Dynamo for its distributed design. The decentralised design makes it immune to almost any type of outage that affects a part of the cluster, while the column family-based design allows for richer, more complex data models that resemble Google's BigTable. This has allowed it to develop a good amalgamation of features from both Dynamo and BigTable, while evolving into a top-notch choice for production environments in various organisations, including the place where it was created—Facebook.

Another concept that is important to Cassandra is eventual consistency, which is increasingly being looked at in the context of Brewer's CAP theorem, which I had discussed in the earlier article. Eventual consistency, as its name suJJHsWs, RIIHUs huJH SHUIRUPDQFH EHQHfiWs Ey DssuPLQJ WhDW consistency does not need to be guaranteed immediately at all points in the database, and that it can be relaxed to some extent. This is achieved by what is known as a tunable consistency model, which uses the consistency level setting to EH sSHFLfiHG wLWh HDFh RSHUDWLRQ, sR WhDW WhHy DUH GHHPHG WR be successful even if data has not been written to all replicas.