Apache Cassandra

The problem it was built for

Cassandra exists to answer a specific question: how does a database keep working when individual machines do not?

Most databases have a primary node that accepts writes. It is a sensible design and it has one structural consequence. When that node is lost, writing stops until something else takes over, and the taking over is itself a process that can go wrong.

Cassandra removes the primary. Every node in the cluster has the same role. Any node can accept a read or a write. There is nothing whose loss halts the system.

That single decision explains almost everything else about the database, including the things that make it harder to work with.

How data is spread

Each row has a partition key. The database applies a function to that key to decide which nodes hold the row.

Rows sharing a partition key form a partition, and a partition lives together on the same nodes. Data is replicated, so a partition exists on several nodes rather than one, and the replication factor sets how many.

Adding nodes causes the cluster to redistribute partitions so that the new machines take a share. Growth is a matter of adding machines rather than replacing one with something larger.

Choosing how certain to be

Because copies live on several nodes and writes can arrive at any of them, there is a question about how many copies must agree before an operation is finished.

Cassandra makes this a setting on each query rather than a property of the database.

Requiring a single replica to respond is fast, and it may return data that another replica has already updated. Requiring a majority of replicas is slower, and a read that requires a majority after a write that required a majority will see that write.

The important part is that this is explicit. In many systems the trade between speed and certainty is buried in the design. Here it is stated per query, which means the developer has to understand it. That is a real cost in learning and a real benefit in clarity.

A query language that leaves things out

CQL looks like SQL. Tables, columns, insert and select statements are all recognisable.

The differences are the omissions. Arbitrary joins are not available. Aggregations across the whole dataset are constrained. Queries that do not include the partition key are discouraged and in some cases refused.

This is deliberate rather than incomplete. Such operations would require gathering data from every node in the cluster. On a large cluster that is slow, and it gets slower as the cluster grows, which defeats the purpose of the design.

The language prevents queries whose cost would rise with cluster size. It is restrictive in exactly the way the architecture requires.

Designing tables backwards

This produces the largest difference in day to day work.

Relational modelling starts with the entities and their relationships. Tables are normalised so each fact is stored once, and queries join across them as needed.

Cassandra modelling starts with the queries. For each query the application will run, a table is designed so that the query reads a single partition. The partition key is whatever makes that true.

The direct consequence is that the same information is stored several times, in several tables shaped for different questions. Storing messages by conversation and also by sender means two tables holding the same messages.

To relational thinking this looks like a mistake. Here it is the intended approach. Storage is comparatively cheap and the alternative, gathering data from across the cluster at read time, is what the design is avoiding.

It also means new query patterns can require new tables and backfilling existing data. The model accommodates the queries known in advance, and it is inflexible about the ones that were not.

More than one location

Replication is configured per data centre. A keyspace can specify how many replicas to keep in each named location.

This makes geographic distribution a configuration setting rather than something built on top of the database. Clients can be directed to read from replicas in their own data centre.

Who uses it

Cassandra is used by engineering teams operating systems with high write volumes, strict availability requirements or data spread across regions. It appears in event recording, time series storage, messaging and similar workloads where writes are constant and query patterns are known in advance.

Points to consider

It is an Apache project under an open source licence. Commercial distributions and managed services exist from various vendors, and the official project documentation is the reference for the database itself.

The operational demands are real. Repair processes, compaction strategies and monitoring are part of running a cluster, and a cluster left unattended develops problems that are harder to fix later than to prevent.

It is not a general purpose database. Workloads needing flexible queries, joins across entities or strong consistency by default are better served elsewhere. Choosing Cassandra because it scales, without the access patterns that suit it, produces a system that is harder to use than a relational database and no faster for the queries actually being run.

Getting started

The official documentation covers the architecture, CQL, data modelling and cluster operations. The data modelling sections repay reading before anything is built, because table design here follows from the queries and is difficult to change afterwards.