Database Reference
In-Depth Information
Chapter5.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 the-
oretical 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 topic 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 the local node, as well as hinted handoff
information. The metadata includes:
▪ The node's token
▪ The cluster name
▪ Keyspace and schema definitions to support dynamic loading
▪ Migration data
▪ Whether or not the node is bootstrapped
The schema definitions are stored in two column families: the
Schema
column family holds user
keyspace and schema definitions, and the
Migrations
column family records the changes made
to a keyspace.
You cannot modify the system keyspace.
