Understanding how Apache Cassandra works under the hood can greatly improve your chances of running a successful cluster or application. We will reach that understanding by asking some simple, fundamental questions. What types of problems was Cassandra designed to solve? Why does a relational database management system (RDBMS) have difficulty handling those problems? If Cassandra works this way, how should I design my data model to achieve the best performance?

As the internet grew in popularity around the turn of the century, the systems behind internet architecture began to change. When good ideas were built into popular websites, user traffic increased exponentially...

An aspect of Cassandra's architecture that demonstrates its AP CAP designation is in how each instance works together. A single-instance running in Cassandra is known as a node. A group of nodes serving the same dataset is known as a cluster or ring. Data written is distributed around the nodes in the cluster. The partition key of the data is hashed to determine it's token. The data is sent to the nodes responsible for the token ranges that contain the hashed token value.

The partition key (formerly known as a row key) is the first part of PRIMARY KEY, and the key that determines the row’s token...

Understanding how Cassandra handles writes is key to knowing how to build applications on top of it. The following is a high-level diagram of how the Cassandra write path works:

When a write operation reaches a node, it is persisted in two places. There is an in-memory structure known as a memtable, which gets the write. Additionally, the new data is written to the commit log, which is on-disk.

Once a flush of the memtable is triggered, the data stored in memory is written to the sorted string table files ...

The Cassandra read path is somewhat more complex. Similar to the write path, structures in-memory and on-disk structures are examined, and then reconciled:

As shown in the preceding figure, a node handling a read operation will send that request on two different paths. One path checks the memtables (in RAM) for the requested data.

If row-caching is enabled (it is disabled by default), it is checked for the requested row, followed by the bloom filter. The bloom filter (Ploetz, et-al 2018) is a probability-based structure in RAM, which speeds up reads from disk by determining which SSTables are likely to contain the requested data.

If the response from the bloom filter is negative, the partition...

When rows are written to disk, they are stored in different types of file. Let's take a quick look at these files, which should be present after what we did in Chapter 1, Quick Start.

First of all, let's cd over to where our table data is stored. By default, keyspace and table data is stored in the data/ directory, off of the $CASSANDRA_HOME directory. Listing out the files reveals the following:

cd data/data/packt/hi_scores-d74bfc40634311e8a387e3d147c7be0f
ls -al
total 72
drwxr-xr-x  11 aploetz aploetz  374 May 29 08:28 .
drwxr-xr-x   6 aploetz aploetz...

Now that we have discussed the read and write paths of an individual Apache Cassandra node, let's move up a level and consider how all of the nodes work together. Keeping data consistent and serving requests in a way that treats multiple machines as a single data source requires some extra engineering. Here we'll explore the additional components which make that possible.

Gossiper is a peer-to-peer communication protocol that a node uses to communicate with the other nodes in the cluster. When the nodes gossip with each other, they share information about themselves and retrieve information on a subset of other nodes in the cluster. Eventually, this allows a node to store...

In this chapter, we discussed many aspects of Apache Cassandra. Some concepts may not have been directly about the Cassandra database, but concepts that influenced its design and use. These topics included Brewer's CAP theorem data-distribution and- partitioning; Cassandra's read and write paths; how data is stored on-disk; inner workings of components such as the snitch, tombstones, and failure-detection; and an overview of the delivered security features.

This chapter was designed to give you the necessary background to understand the remaining chapters. Apache Cassandra was architected to work the way it does for certain reasons. Understanding why will help you to provide effective configuration, build high-performing data models, and design applications that run without bottlenecks. In the next chapter, we will discuss and explore CQL, and explain why it...