In this chapter, we examine several aspects of Cassandra’s internal design in order to understand how it does its job. We consider the peer-to-peer design and its corresponding gossip protocol, as well as what Cassandra does on read and write requests, and examine how these choices affect architectural considerations such as scalability, durability, availability, manageability, and more. We also discuss Cassandra’s adoption of a Staged Event-Driven Architecture, which acts as the platform for request delegation.
The Cassandra architecture is very sophisticated and relies on the use of several different theoretical constructs. It is hard to discuss any one new term without referencing other terms we probably also haven’t met yet. This can be frustrating, which is why I’ve included the Glossary in the back of the book for you to refer to.
Cassandra has an internal keyspace called
it uses to store metadata about the cluster to aid in operations. In
Microsoft SQL Server, two meta-databases are maintained:
used to keep information about disk space, usage, system settings, and
general server installation notes; the
tempdb is used as a
workspace to store intermediate results and perform general tasks. The
Oracle database always has a tablespace called
for similar purposes. The Cassandra system keyspace is used much like
Specifically, the system keyspace stores metadata for ...