Skip to content
Navigation

Type at least two characters. Search covers page titles, headings, tags and database names.

↑ ↓ to navigateEnter to openEsc to close0 pages
Wide Columnintermediate

Apache Cassandra

Masterless wide-column store with tunable consistency and linear write scaling across datacenters.

2 min readIntermediateUpdated Edit this page

What it is

An Apache-2.0 licensed distributed wide-column database. Every node is equal, data is partitioned by a hash of the partition key, and consistency is chosen per query.

Architecture

Nodes form a token ring; each owns ranges of the token space, and replicas are placed on subsequent nodes with rack and datacenter awareness. Writes go to a commit log and a memtable, then flush to immutable SSTables that background compaction merges. Membership is maintained by gossip, with no coordinator or configuration server.

Cassandra ring with six nodesSix Cassandra nodes arranged in a token ring. Each node owns a contiguous token range and gossips with its neighbours; a write for a partition key is routed to the node owning that token and replicated to the next nodes clockwise.Node 10–1/6Node 21/6–2/6Node 32/6–3/6Node 43/6–4/6Node 54/6–5/6Node 65/6–1
Cassandra ring with six nodes

Best use cases

  • Very high write throughput that exceeds a single node — telemetry, events, messaging.
  • Workloads keyed by an entity: all events for a device, all messages in a conversation.
  • Multi-datacenter deployments serving each region locally.
  • Systems that must keep accepting writes while nodes are down.

When not to use it

  • When queries are not known in advance: no planner, no joins, and a query without the partition key either scans the cluster or is rejected.
  • For read-modify-write workloads — lightweight transactions use Paxos and cost several times a normal write.
  • For small datasets, where a three-node cluster is overhead without benefit.
  • As a queue: deletes create tombstones that accumulate until reads time out.

Data model

Tables with a compound primary key: a partition key deciding placement, and clustering columns deciding order within the partition. Tables are designed per query, and duplicating data across several tables is the intended approach.

Consistency and transactions

No multi-partition transactions. Writes to one partition are atomic. Consistency is per query (ONE, LOCAL_QUORUM, QUORUM, ALL), with the R + W > RF overlap rule providing the guarantee. Lightweight transactions give compare-and-set within one partition.

Scaling model

Adding nodes adds capacity nearly linearly. The scaling story is genuinely simple; the data modelling is where the difficulty lives.

Replication

Per keyspace, per datacenter, with NetworkTopologyStrategy. Replicas converge through hinted handoff, read repair and — critically — scheduled anti-entropy repair.

Backup and recovery

Per-node snapshots (hard links) plus incremental backups, with sstableloader for restoring into a changed topology. A cluster restore is not point-in-time consistent across nodes.

Monitoring

nodetool status, tablestats, tablehistograms, compactionstats, tpstats, and JMX metrics for coordinator latency and thread pools. See Cassandra Monitoring.

Common mistakes

Production checklist

See Cassandra Production Checklist.