The data dictionary in Cassandra 1.2

Cassandra 1.2 exposes almost everything that each server knows about the cluster in tables in the system keyspace. We started this process with the introduction of CQL3 in Cassandra 1.1, but introducing the native protocol motivated us to finish it, so native protocol drivers can introspect everything they need without falling back to the old Thrift calls.

Here's what the system keyspace contains.

Schema

 

CREATE TABLE schema_keyspaces (
  keyspace_name text PRIMARY KEY,
  durable_writes boolean,
  strategy_class text,
  strategy_options text
);

CREATE TABLE schema_columnfamilies (
  keyspace_name text,
  columnfamily_name text,
  bloom_filter_fp_chance double,
  caching text,
  column_aliases text,
  comment text,
  compaction_strategy_class text,
  compaction_strategy_options text,
  comparator text,
  compression_parameters text,
  default_read_consistency text,
  default_validator text,
  default_write_consistency text,
  gc_grace_seconds int,
  id int,
  key_alias text,
  key_aliases text,
  key_validator text,
  local_read_repair_chance double,
  max_compaction_threshold int,
  min_compaction_threshold int,
  read_repair_chance double,
  replicate_on_write boolean,
  subcomparator text,
  type text,
  value_alias text,
  PRIMARY KEY (keyspace_name, columnfamily_name)
);

CREATE TABLE schema_columns (
  keyspace_name text,
  columnfamily_name text,
  column_name text,
  component_index int,
  index_name text,
  index_options text,
  index_type text,
  validator text,
  PRIMARY KEY (keyspace_name, columnfamily_name, column_name)
);

 

This all corresponds exactly with what you see in CREATE TABLE, so this is pretty straightforward. A couple things that might bear additional explanation:

• durable_writes: allows disabling the commitlog for tables in this keyspace. Generally not recommended, but occasionally useful for temporary data or when you're confident that replication will be adequate to keep your data safe.
• subcomparator: used by obsolete SuperColumns.
• component_index: use by Cassandra internally with compound primary keys

Cluster information

Each node records what other nodes tell it about themselves over gossip:

 

CREATE TABLE peers (
  peer inet PRIMARY KEY,
  data_center text,
  host_id uuid,
  rack text,
  release_version text,
  rpc_address inet,
  schema_version uuid,
  tokens set
);

 

And what it knows about itself, which is a superset of what it gossips:

 

CREATE TABLE local (
  key text PRIMARY KEY,
  bootstrapped text,
  cluster_name text,
  cql_version text,
  data_center text,
  gossip_generation int,
  host_id uuid,
  partitioner text,
  rack text,
  release_version text,
  schema_version uuid,
  thrift_version text,
  tokens set,
  truncated_at map
);

 

Remember that starting with 1.2 each node can be assigned multiple tokens through virtual nodes.

There is only a single row in the local table (key also "local").

Other

The batchlog table contains data for atomic batches.

Hinted handoff records mutations to replay in the hints table.

IndexInfo stores information about index creation status and will probably be moved into schema_columnfamilies in the future.

NodeIdInfo stores counter "node ids".

range_xfers is used to store range transfer status when upgrading a non-vnode cluster to use vnodes.

Request traces are stored not in the system keyspace, which is unreplicated, but in system_traces.

Drive responsibly

Cassandra does allow you to update data in the system keyspace, but it goes without saying that you should only do so if you know what you are doing.

Schema changes to system are not allowed.