Partitioning Basics

Answer:

The partition key is the first part of the PRIMARY KEY that determines which node stores the data.

How it works:

• Cassandra hashes the partition key value using Murmur3
• Hash produces a token (-2^63 to 2^63-1)
• Token determines which node owns the data
• All rows with same partition key stored together on same node

Why it's important:

• Performance: Single-partition queries are fastest (one node lookup)
• Distribution: Determines how data spreads across cluster
• Scalability: Good design enables horizontal scaling
• Co-location: Related data stored together for efficiency

Example:

CREATE TABLE users (
    user_id uuid PRIMARY KEY,  -- partition key
    name text,
    email text
);

-- Query: SELECT * FROM users WHERE user_id = ?
-- Fast! Single node lookup

Answer:

Partition Key:

• Determines which node stores the data
• First part of PRIMARY KEY (in parentheses)
• All rows with same partition key on same node
• Used for data distribution

Clustering Key:

• Determines sort order within a partition
• Second part of PRIMARY KEY (after partition key)
• Allows multiple rows per partition
• Used for data ordering

Example:

CREATE TABLE user_events (
    user_id uuid,        -- partition key
    event_time timestamp, -- clustering key
    event_type text,
    data text,
    PRIMARY KEY ((user_id), event_time)
) WITH CLUSTERING ORDER BY (event_time DESC);

-- Partition key: user_id
--   → Determines node (all events for user on same node)
-- Clustering key: event_time DESC
--   → Sorts events newest first within partition

-- Query: SELECT * FROM user_events WHERE user_id = ? LIMIT 10
-- Returns: 10 most recent events for user (fast!)

Visual:

Partition: user_id = alice
├── event_time: 2024-12-26 10:30:00 (newest, returned first)
├── event_time: 2024-12-26 10:25:00
├── event_time: 2024-12-26 10:20:00
└── ... (sorted by clustering key)

Answer: Cassandra uses consistent hashing with Murmur3 hash function:

Process:

• Step 1: Hash partition key with Murmur3
  • Input: partition key value (e.g., user_id=12345)
  • Output: 64-bit token (e.g., -8234719023847192847)
• Step 2: Map token to node
  • Each node owns range of tokens
  • Token falls in one node's range
• Step 3: Store data on that node

Why it works:

• Uniform Distribution: Murmur3 spreads values evenly across token range
• Deterministic: Same key always produces same token
• Avalanche Effect: Small key change → completely different token
• Equal Ranges: Each node owns equal portion of token ring

Example (3-node cluster):

Token Range: -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807

Node 1 owns: -9,223,372,036,854,775,808 to -3,074,457,345,618,258,603
Node 2 owns: -3,074,457,345,618,258,603 to  3,074,457,345,618,258,602  
Node 3 owns:  3,074,457,345,618,258,602 to  9,223,372,036,854,775,807

Each node owns ~33.3% of token range
→ Each stores ~33.3% of data (even distribution!)

Answer:

Hot Partition = partition that's too large or too frequently accessed

Signs of hot partition:

• Partition size > 100MB (or > 100,000 rows)
• Slow queries (> 100ms)
• High read/write traffic to one node
• Node experiencing OOM errors or GC pauses
• Uneven load distribution across cluster

Common Causes:

• Poor Partition Key: Low cardinality (few unique values)
• Unbounded Growth: No time-based bucketing for time-series
• Celebrity Problem: One entity with millions of relationships

Solutions:

1. Add Bucketing:

-- Before (hot partition)
PRIMARY KEY ((celebrity_id), follower_id)
-- 130M followers in ONE partition!

-- After (distributed across buckets)
PRIMARY KEY ((celebrity_id, bucket), follower_id)
-- Split into 10 partitions of 13M each

2. Time-Based Bucketing:

-- Add date to partition key
PRIMARY KEY ((user_id, date), timestamp)
-- Each day = new partition (bounded growth)

3. Redesign Schema:

-- Query by follower instead of celebrity
PRIMARY KEY ((follower_id), celebrity_id)
-- Now each user has small partition

Answer: Follow these criteria for partition key selection:

1. High Cardinality:

• Many unique values (millions, not thousands)
• ✅ Good: user_id, order_id, session_id
• ❌ Bad: status (active/inactive), country (195 values)

2. Even Distribution:

• Values spread evenly across all possible keys
• ✅ Good: UUID, user_id (millions of users)
• ❌ Bad: timestamp_hour (only 24 values)

3. Match Query Pattern:

• Partition key should be what you query by
• ✅ Good: Query by user? Use user_id
• ❌ Bad: Query by user but partition by date

4. Bounded Size:

• Partition won't grow indefinitely
• ✅ Good: (user_id, date) for time-series
• ❌ Bad: (user_id) for append-only data

Decision Tree:

1. What do I query by?
   → Use that as partition key

2. Will partitions grow too large?
   YES → Add time-bucketing (date, hour)
   NO  → Keep simple partition key

3. Do I have hot entities (celebrities)?
   YES → Add bucketing or redesign
   NO  → Current design OK

4. How many unique values?
   < 1,000   → Too low, rethink design
   1,000 - 1M → OK
   > 1M      → Excellent!

Answer:

Simple Partition Key:

• Single column determines node
• Syntax: PRIMARY KEY (user_id)
• Use when: One natural identifier exists

CREATE TABLE users (
    user_id uuid PRIMARY KEY,
    name text,
    email text
);
-- Partition key: user_id only

Composite Partition Key:

• Multiple columns together determine node
• Syntax: PRIMARY KEY ((col1, col2))
• Use when: Need to split large partitions

CREATE TABLE sensor_data (
    sensor_id uuid,
    date text,         -- '2024-12-26'
    hour int,
    temperature decimal,
    PRIMARY KEY ((sensor_id, date), hour)
);
-- Partition key: sensor_id + date (composite)
-- One partition per sensor per day

Key Differences:

Aspect	Simple	Composite
Columns	1	2+
Use Case	Natural key	Split partitions
Query	WHERE user_id=?	WHERE sensor_id=? AND date=?
Complexity	Simple	More complex

When to use composite:

• Time-series data (add date to avoid unbounded growth)
• Hot partitions (add bucketing column)
• Natural multi-column identifier

Answer: 4-step process using consistent hashing:

Step 1: Hash the Partition Key

Partition key: user_id = 12345
↓ Apply Murmur3 hash function
Token: -8234719023847192847 (64-bit integer)

Step 2: Locate Token in Ring

Token range: -2^63 to 2^63-1
Cluster has 3 nodes:

Node 1: -9223372036854775808 to -3074457345618258603
Node 2: -3074457345618258603 to  3074457345618258602
Node 3:  3074457345618258602 to  9223372036854775807

Token -8234719023847192847 falls in Node 1's range!

Step 3: Determine Replicas

With RF=3:
Primary replica: Node 1 (owns token range)
Replica 2: Node 2 (next node clockwise on ring)
Replica 3: Node 3 (next node clockwise on ring)

All 3 nodes store copy of this partition!

Step 4: Client Contacts Coordinator

Client driver:
1. Calculates token locally
2. Knows which nodes own that token
3. Sends request directly to one of the replica nodes
4. That node becomes coordinator for this request

Example Query Flow:

Client: SELECT * FROM users WHERE user_id = 12345

1. Driver hashes 12345 → token -8234719023847192847
2. Driver knows Node 1, 2, 3 own this token
3. Driver picks Node 1 (token-aware routing)
4. Node 1 reads data locally (same node!)
5. Returns result to client

Latency: <1ms (no network hops between nodes!)

Answer:

Recommended Limits:

• Size: < 100 MB per partition
• Rows: < 100,000 rows per partition
• Hard Limit: 2 GB (but should never reach this!)

Why these limits?

• Memory: Large partitions may not fit in memory
• Compaction: Large partitions slow down compaction
• Queries: Reading entire partition becomes slow
• Repair: Large partitions take longer to repair
• GC Pressure: Large objects cause GC pauses

Performance Impact:

Size	Query Time	Status
< 10 MB	< 1 ms	✅ Excellent
10-100 MB	1-10 ms	✅ Good
100-500 MB	10-100 ms	⚠️ Warning
> 500 MB	> 100 ms	❌ Bad

How to check partition sizes:

$ nodetool tablehistograms mykeyspace.users

Partition Size:
50%: 4096 bytes      (4 KB - excellent!)
75%: 16384 bytes     (16 KB - excellent!)
95%: 65536 bytes     (64 KB - good)
99%: 524288 bytes    (512 KB - acceptable)
Max: 104857600 bytes (100 MB - at limit!)
                     ↑ Watch this!

Answer: Technically yes, but NOT RECOMMENDED in production!

Option 1: ALLOW FILTERING (Slow!)

-- Query by non-partition-key column
SELECT * FROM users WHERE email = 'alice@example.com' 
ALLOW FILTERING;

❌ Problem:
- Scans ALL partitions on ALL nodes
- Reads entire table (could be billions of rows!)
- Can timeout or crash cluster
- Use ONLY for small tables or development

Option 2: Secondary Index (Limited Use)

CREATE INDEX ON users(email);

SELECT * FROM users WHERE email = 'alice@example.com';

⚠️ Caveats:
- Still queries ALL nodes
- Only efficient for low-cardinality columns
- Not recommended for high-cardinality (like email)
- Performance degrades with cluster size

Option 3: Materialized View (Better!)

-- Create view with different partition key
CREATE MATERIALIZED VIEW users_by_email AS
    SELECT * FROM users
    WHERE email IS NOT NULL AND user_id IS NOT NULL
    PRIMARY KEY (email, user_id);

-- Now can query efficiently by email!
SELECT * FROM users_by_email 
WHERE email = 'alice@example.com';

✅ Benefits:
- Automatically maintained by Cassandra
- Fast queries (single partition)
- Proper data distribution

Best Practice:

• Design schema for your queries - partition key should match query pattern
• Use materialized views for alternative query patterns
• Never use ALLOW FILTERING in production on large tables
• Denormalize data if you need multiple query patterns

Answer: Use time-bucketing to prevent unbounded partition growth!

Problem with Naive Design:

-- BAD: Unbounded growth
CREATE TABLE sensor_readings (
    sensor_id uuid,
    timestamp timestamp,
    temperature decimal,
    humidity decimal,
    PRIMARY KEY ((sensor_id), timestamp)
);

❌ Problems:
- Partition grows forever (1 reading/second = 31M rows/year!)
- Eventually exceeds 100MB limit
- Queries slow down over time
- Compaction becomes difficult

Solution: Add Time Bucket to Partition Key

Option 1: Daily Buckets (Most Common)

CREATE TABLE sensor_readings (
    sensor_id uuid,
    date text,            -- '2024-12-26'
    timestamp timestamp,
    temperature decimal,
    humidity decimal,
    PRIMARY KEY ((sensor_id, date), timestamp)
) WITH CLUSTERING ORDER BY (timestamp DESC);

✅ Benefits:
- One partition per sensor per day
- Max 86,400 rows (1/second for 24 hours)
- Partition size: < 10 MB typically
- Old data can be TTL'd or archived

-- Query last 24 hours:
SELECT * FROM sensor_readings
WHERE sensor_id = ? AND date = '2024-12-26';

Option 2: Hourly Buckets (High Frequency)

CREATE TABLE sensor_readings (
    sensor_id uuid,
    date text,
    hour int,             -- 0-23
    timestamp timestamp,
    temperature decimal,
    PRIMARY KEY ((sensor_id, date, hour), timestamp)
);

✅ Use when:
- Very high frequency (>1/second)
- Need very small partitions
- Real-time queries on recent data

Max rows per partition: 3,600 (1/second for 1 hour)

Option 3: Weekly Buckets (Low Frequency)

CREATE TABLE sensor_readings (
    sensor_id uuid,
    week text,            -- '2024-W52'
    timestamp timestamp,
    temperature decimal,
    PRIMARY KEY ((sensor_id, week), timestamp)
);

✅ Use when:
- Low frequency data
- Long-term storage
- Historical analysis

Max rows per partition: 604,800 (1/second for 1 week)

Choosing Bucket Size:

Frequency	Bucket	Max Rows
> 10/sec	Hourly	36,000
1-10/sec	Daily	864,000
< 1/sec	Weekly	604,800

Best Practices:

• Target < 100,000 rows per partition
• Add TTL for automatic cleanup
• Use CLUSTERING ORDER BY timestamp DESC for recent data first
• Query with date range for efficiency