Chapter 5. The Cassandra Architecture
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.
System Keyspace
Cassandra has an internal keyspace called system that
it uses to store metadata about the cluster to aid in operations. In
Microsoft SQL Server, two meta-databases are maintained:
master and tempdb. The master is
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 SYSTEM, used
for similar purposes. The Cassandra system keyspace is used much like
these.
Specifically, the system keyspace stores metadata for ...
Get Cassandra: The Definitive Guide now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
