What are Cassandra performance tuning and best practices?
Master Cassandra performance tuning: query-first modeling, bounded partitions, compaction strategies, consistency levels and tombstone control for fast reads.
Expected Interview Answer
Cassandra performance tuning centers on query-first data modeling with well-sized bounded partitions, choosing the right compaction strategy for the workload, tuning consistency levels, controlling tombstones, and sizing JVM heap, caches, and hardware appropriately.
The biggest wins come from the data model: even partition distribution, partitions kept under a few hundred MB, and tables shaped per query. Operationally you match compaction strategy to access patterns (LeveledCompactionStrategy for read-heavy, SizeTieredCompactionStrategy for write-heavy, TimeWindowCompactionStrategy for time-series), pick consistency levels like LOCAL_QUORUM for a latency-availability balance, keep tombstones low, and tune the JVM heap, key/row caches, compaction throughput, and use SSDs. Continuous monitoring with nodetool and metrics closes the loop.
- Lower and more predictable read/write latency
- Even load distribution across the cluster
- Reduced tombstone and read amplification
- Efficient disk and memory usage
- Stable performance as data and traffic grow
AI Mentor Explanation
Tuning Cassandra is like preparing a pitch and rotating bowlers for the conditions: a green seaming track needs different tactics than a dry spinner's wicket. Matching compaction strategy to your read or write workload is that same adaptation — the wrong strategy is like bowling pace on a raging turner, wasting effort and leaking runs while the right one keeps the game under control.
Step-by-Step Explanation
Step 1
Get the data model right
Design one table per query, keep partitions evenly distributed and under a few hundred MB, and avoid unbounded growth.
Step 2
Match the compaction strategy
Use LCS for read-heavy, STCS for write-heavy, and TWCS for time-series/TTL data to minimize read amplification.
Step 3
Tune consistency levels
Prefer LOCAL_QUORUM for a latency-availability balance; reserve stronger levels for the few queries that need them.
Step 4
Control tombstones
Avoid frequent deletes and null inserts, set appropriate gc_grace_seconds, and monitor tombstone warnings in logs.
Step 5
Size hardware and JVM
Use SSDs, set heap appropriately (often 8-16 GB), tune key/row caches and compaction throughput to hardware.
Step 6
Monitor continuously
Track latency, pending compactions, GC pauses, and hotspots with nodetool and metrics to catch regressions early.
What Interviewer Expects
- Recognition that data modeling is the primary performance lever
- Knowledge of compaction strategies and when to use each
- Understanding of consistency-level trade-offs like LOCAL_QUORUM
- Awareness of tombstone impact and mitigation
- Familiarity with JVM, cache, and hardware tuning plus monitoring tools
Common Mistakes
- Trying to tune the JVM before fixing a bad data model
- Using the wrong compaction strategy for the workload
- Setting consistency to ALL and blaming Cassandra for latency
- Ignoring tombstone warnings until reads time out
- Oversizing the JVM heap and causing long GC pauses
Best Answer (HR Friendly)
“Getting the best performance from Cassandra starts with designing tables around the exact questions you'll ask and keeping data evenly spread. After that, you fine-tune background maintenance settings, choose how strict the reads and writes need to be, and keep an eye on the system with monitoring tools to catch slowdowns early.”
Code Example
CREATE TABLE metrics (
device_id text,
day date,
ts timestamp,
value double,
PRIMARY KEY ((device_id, day), ts)
) WITH CLUSTERING ORDER BY (ts DESC)
AND compaction = {
'class': 'TimeWindowCompactionStrategy',
'compaction_window_unit': 'DAYS',
'compaction_window_size': 1
}
AND default_time_to_live = 2592000; -- 30 daysFollow-up Questions
- How do LCS, STCS, and TWCS differ and when do you use each?
- Why can setting consistency to ALL hurt performance?
- How do you diagnose and fix a tombstone problem?
- What nodetool commands do you use to investigate latency?
- How does JVM heap sizing affect Cassandra's GC behavior?
MCQ Practice
1. Which compaction strategy best fits time-series data with TTL?
TWCS groups data into time windows, letting whole expired windows drop efficiently — ideal for TTL'd time-series.
2. What is the primary lever for Cassandra performance?
A query-first data model with bounded, evenly distributed partitions matters more than any operational knob.
3. Which consistency level balances latency and availability in one DC?
LOCAL_QUORUM requires a majority within the local data center, balancing strong-enough reads with low latency.
Flash Cards
Biggest performance lever in Cassandra? — The data model — query-first tables with bounded, evenly distributed partitions.
When to use LCS vs STCS? — LCS for read-heavy workloads, STCS for write-heavy; TWCS for time-series/TTL data.
Why LOCAL_QUORUM? — It requires a local-DC majority, balancing consistency with low latency and availability.
How to reduce tombstone impact? — Avoid frequent deletes/null inserts, tune gc_grace_seconds, and use TWCS with TTL for expiring data.