Topic 8.10
Wide-Column Databases
In one line
Cassandra/Bigtable: rows with dynamic columns, partition-key-clustered tables, tuned for planetary write scale.
Think of it like this
A spreadsheet built for one very specific report, where every row is designed around how it will be read later. It's blazing fast for that ONE report, but nearly useless if you ask a different question of the same data.
Key ideas
- 01
Partition key → node (hash), clustering columns → sort within partition; same shape as DynamoDB's PK+SK.
- 02
Optimized for write-heavy, append-heavy workloads (events, telemetry, chat history, IoT).
- 03
Query model: you design the table per query — denormalization is the norm, joins do not exist.
- 04
Consistency dial: quorum reads/writes; eventual by default; tunable per operation (ONE, QUORUM, ALL).
- 05
Cassandra's ring uses consistent hashing + vnodes (ties back to 8.6).
- 06
Interview line: 'time-series events, write-dominated, partition by device_id + time bucket'.
Java / Spring map
- →
Datastax Java driver for Cassandra; CQL = SQL-ish but no joins.
Explain without notes
Design the wide-column table for 'message history per chat' (partition key, clustering, TTL).
Practice
Build the CQL schema for a telemetry stream and a chat history, then justify the keys.
Trade-offs
- ↔
No joins + per-query tables = great writes, brutal for ad-hoc reads. Know the query set before you commit.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can say when wide-column beats document/key-value and sketch the partition key.