Database Reference
In-Depth Information
Chapter 2. Cassandra Architecture
This chapter aims to set you into a perspective where you will be able to see the evolution
of the NoSQL paradigm. It will start with a discussion of common problems that an aver-
age developer faces when the application starts to scale up and software components can-
not keep up with it. Then, we'll see what can be assumed as a thumb rule in the NoSQL
world: the CAP theorem that says to choose any two out of consistency, availability, and
partition-tolerance. As we discuss this further, we will realize how much more important it
is to serve the customers (availability), than to be correct (consistency) all the time.
However, we cannot afford to be wrong (inconsistent) for a long time. The customers
wouldn't like to see that the items are in stock, but that the checkout is failing. Cassandra
comes into picture with its tunable consistency.
We will take a quick peep into all the actions that go on when a read or mutate happens.
This leaves us with lots of fancy terms. Next, we will move on to see these terms in full
glory with explanation as we discuss various parts of the Cassandra design. You will be
amazed to see how close yet how far Cassandra is when compared with its precursors and
inspiration databases, such as Google's BigTable and Amazon's Dynamo. We will meet
with some of the modern and efficient data structures, such as bloom filters and Merkle
trees, and algorithms, such as gossip protocol, phi accrual error detectors, and log-struc-
tured merge trees. Some of these discussions will help you rationalize the performance and
constraints of Cassandra.
