Advanced Topics

CREATE TABLE user_activity (
  user_id UUID,
  activity_date DATE,
  action TEXT,
  PRIMARY KEY (user_id, activity_date, action)
);

-- Celebrity user: 1M actions per second
-- Regular user: 100 actions per second
-- Partition key = user_id
// Celebrity's partition is on Node1
// Node1 handles 10x more traffic than Node2, Node3

// Result: Node1 CPU/network saturated
// Celebrity actions slow, timeouts
// Other nodes idle

-- Distribute hot data across multiple partitions
CREATE TABLE celebrity_activity (
  user_id UUID,
  shard INT,  -- NEW: 0-9
  activity_date DATE,
  action TEXT,
  PRIMARY KEY ((user_id, shard), activity_date, action)
);

-- When inserting, randomly pick a shard (0-9)
INSERT INTO celebrity_activity (user_id, shard, activity_date, action)
VALUES (celebrity_uuid, random() % 10, today(), 'liked_video');

-- Traffic now spreads across 10 partitions instead of 1
// Single partition: 100K writes/sec
// Spread across 10: ~10K writes/sec per partition

-- Already using in time-series
CREATE TABLE metrics (
  sensor_id UUID,
  date_bucket DATE,
  timestamp TIMESTAMP,
  value DOUBLE,
  PRIMARY KEY ((sensor_id, date_bucket), timestamp)
);

// If sensor sends constant stream of data:
// Partition rotates daily (sensor_id, 2024-01-01) → (sensor_id, 2024-01-02)
// Load spreads over time buckets

-- BAD: Partition by low-cardinality field
CREATE TABLE status_tasks (
  status TEXT,  -- Only "pending", "done", "failed"
  task_id UUID,
  PRIMARY KEY (status)
);
// All "pending" tasks → one partition → hot spot

-- BETTER: Partition by high-cardinality field
CREATE TABLE tasks (
  task_id UUID,  -- Millions of unique values
  status TEXT,
  PRIMARY KEY (task_id)
);
// Each task is own partition → distributed evenly

CREATE KEYSPACE app_data WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'DC_US_EAST': 3,      -- 3 replicas in US East
  'DC_EU_WEST': 3,      -- 3 replicas in EU West
  'DC_ASIA': 2          -- 2 replicas in Asia
};

-- Data replicated automatically:
-- Write to DC_US_EAST → replicated to DC_EU_WEST → replicated to DC_ASIA
-- Takes time (milliseconds to seconds depending on network)

-- Write to nearest DC first (fast)
INSERT INTO users (user_id, name) 
VALUES (user123, 'Alice')
USING CONSISTENCY LOCAL_QUORUM;

// What happens:
// 1. Coordinator in nearest DC waits for quorum in that DC only
// 2. Returns success immediately (no remote DC latency)
// 3. Remote DCs get data asynchronously

SELECT * FROM users WHERE user_id = 'user123'
USING CONSISTENCY LOCAL_QUORUM;

// Reads from replicas in local DC only
// Fast because no remote DC latency
// Might be slightly stale (remote DC writes pending)

-- Ensure all DCs have data
INSERT INTO critical_data (id, value)
VALUES (data123, 'important')
USING CONSISTENCY QUORUM;  -- Global QUORUM across all DCs

// Much slower, but guarantees consistency across all regions
// Use only for critical data

DC_WEST (US): Coordinator at DC_WEST, replicate to:
  - DC_EAST (US): 20ms away
  - DC_EU: 100ms away
  - DC_ASIA: 200ms away

Write with QUORUM: Wait for 2 of 3 DCs = ~100-200ms latency
Write with LOCAL_QUORUM: Wait for local replicas = ~5-20ms latency

Scenario: Concurrent writes from different DCs

DC_WEST: Update user name to 'Alice' at T=1000
DC_EAST: Update user name to 'Bob' at T=1001

Cassandra uses timestamp tiebreak:
- T=1001 > T=1000
- 'Bob' wins
- Both DCs eventually converge to 'Bob'

But: Race conditions possible, last-write-wins may not be correct

Cassandra native authentication:
- Default: No auth (disabled)
- Enable: require username/password
- Connect: cqlsh -u cassandra -p cassandra

-- Create user
CREATE USER alice WITH PASSWORD 'secret123';

-- Grant permissions
GRANT SELECT ON app_data.users TO alice;
GRANT MODIFY ON app_data.users TO alice;
GRANT ALL ON app_data TO admin_user;

-- Alice can SELECT/INSERT on app_data.users
// Alice cannot DELETE
// Alice cannot access other keyspaces

Client → Cassandra: SSL/TLS encryption
  Prevents eavesdropping on network
  Default: Disabled (enable for security)
  Performance: ~5-10% overhead

Data stored on disk: encrypted
  Requires key management (external KMS)
  Protects against stolen disks
  Default: Disabled
  Performance: ~10-20% overhead

# Check node status
nodetool status

# Check data repair status
nodetool repair keyspace_name

# View table stats
nodetool cfstats keyspace_name.table_name

# Flush memtable to disk
nodetool flush

# Check compaction progress
nodetool compactionstats

# View GC info
nodetool gcstats

# Check ring/token distribution
nodetool ring

1. Merkle trees: Compare partition keys between replicas
2. Identify differences: Mismatches in data
3. Stream repairs: Send missing data to replicas
4. Verify: Confirm all replicas match

Use case: After node failure/recovery, sync all replicas
Triggers: Can be manual (nodetool repair) or auto-schedule
Frequency: Weekly or monthly (before/after maintenance)

# Default: 1/4 of system RAM
# Cassandra typically: 8GB - 16GB

# Set in cassandra-env.sh:
#MAX_HEAP_SIZE="8G"
#HEAP_NEWSIZE="2G"

# Rule of thumb:
// < 100GB data: 4-8GB heap
// 100GB - 1TB: 8-16GB heap
// > 1TB: 16-32GB heap
// (Monitor GC pressure)

# Controls in-memory write buffer
# Default: 1/4 of heap (if 8GB heap → 2GB memtable)

# Larger memtable:
// ✓ Fewer disk writes
// ✓ Better write throughput
// ✗ Longer GC pauses

# Smaller memtable:
// ✓ Frequent disk flushes
// ✓ Lower latency spikes
// ✗ More SSTable files to compact

# Speeds up read lookups ("does row exist?")
# Smaller = faster checks, more false positives (rescan)
# Larger = slower checks, fewer false positives

# Tune based on workload:
// Many random reads: larger bloom filter
// Sequential reads: smaller bloom filter

1. Shard hot partitions (add composite key)
2. Reduce gc_grace_seconds or compact more aggressively
3. Tune bloom filter, cache settings
4. Increase heap, reduce GC pauses

1. Increase heap size (8GB → 16GB)
2. Reduce cache sizes
3. Split compaction into smaller tasks
4. Monitor and profile memory usage

1. Run repair during low-traffic window
2. Use -pr (primary replica) flag: only repair local replicas
3. Increase timeout settings
4. Consider incremental repair (faster)