What is a partition key and how does it determine data distribution?
Understand what a Cassandra partition key is and how the partitioner hashes it into a token to distribute rows evenly across nodes and avoid hot spots.
Expected Interview Answer
A partition key is the first component of a Cassandra primary key that determines which partition a row belongs to; Cassandra hashes it with a partitioner to produce a token, and that token decides which node in the ring owns and stores the data.
Every table's primary key begins with one or more partition-key columns. When you write a row, the partitioner (Murmur3 by default) hashes the partition key into a token on a large ring, and the node responsible for that token range, plus its replicas, stores the row. All rows sharing a partition key land in the same partition on the same nodes, so reads that supply the full partition key are fast and single-node, while a good key choice spreads load evenly and avoids hot spots.
- Deterministic placement of rows across the cluster
- Even data and load distribution when chosen well
- Single-node reads when the full key is supplied
- Enables linear horizontal scaling
- Replicas derived from the same token for fault tolerance
AI Mentor Explanation
Imagine a huge tournament spread across many stadiums, and a rule decides which stadium hosts a match by hashing the home team's name into a number. Every game for that team always goes to the same stadium, so fans know exactly where to look. The partition key is that team name: Cassandra hashes it into a token, and the token sends every row with that key to the same node, keeping related data together and reads fast.
Step-by-Step Explanation
Step 1
Identify the partition-key columns
They are the first part of the PRIMARY KEY definition, optionally grouped in parentheses for a composite key.
Step 2
Hash the key
Cassandra passes the partition key through the partitioner, Murmur3 by default, to produce a token.
Step 3
Map token to node
The token falls into a range owned by a node on the ring, which becomes the primary owner of the row.
Step 4
Place replicas
Additional nodes store copies based on the replication factor and strategy for fault tolerance.
Step 5
Read by full key
Supplying the complete partition key lets Cassandra route straight to the owning node for a fast read.
What Interviewer Expects
- Definition of a partition key within the primary key
- Role of the partitioner and token ring
- How the token maps to nodes and replicas
- Why key choice affects even distribution and hot spots
- Why reads need the full partition key
Common Mistakes
- Confusing the partition key with the clustering key
- Assuming rows are distributed randomly rather than by hash
- Choosing a low-cardinality key that creates hot partitions
- Thinking you can query efficiently without the partition key
- Forgetting that a composite partition key hashes all its columns together
Best Answer (HR Friendly)
“A partition key tells Cassandra which server should hold a piece of data. Cassandra turns the key into a number and uses it to pick the server, so if you choose the key wisely the data spreads evenly and stays fast to find.”
Code Example
-- Single-column partition key
CREATE TABLE users_by_country (
country text,
user_id uuid,
name text,
PRIMARY KEY (country, user_id)
);
-- Composite partition key hashes (country, city) together
CREATE TABLE users_by_region (
country text,
city text,
user_id uuid,
PRIMARY KEY ((country, city), user_id)
);
-- Fast, single-partition read
SELECT * FROM users_by_region WHERE country = 'IN' AND city = 'Pune';Follow-up Questions
- What happens if you pick a low-cardinality partition key?
- How does a composite partition key differ from a single one?
- What is the token ring and how do vnodes fit in?
- Why can't you filter efficiently without the partition key?
MCQ Practice
1. What determines which node stores a Cassandra row?
The partitioner hashes the partition key into a token, and the node owning that token range stores the row.
2. Which is a symptom of a poorly chosen partition key?
A low-cardinality or skewed partition key sends too much data to one partition, creating a hot spot on one node.
Flash Cards
What is a partition key? — The first part of the primary key that Cassandra hashes to decide which node stores a row.
Which partitioner is default? — Murmur3Partitioner, which hashes the partition key into a token on the ring.
What causes a hot partition? — A low-cardinality or skewed partition key that concentrates rows and load on one node.
How is a composite partition key hashed? — All its columns are combined and hashed together into a single token.