Advanced Performance Topics

Caching Strategies in Cassandra

Give Cassandra a memory boost! Caching keeps popular data ready in RAM, so queries don’t have to search storage every time — like keeping your favorite snacks within arm’s reach.

📖 The Story: Lisa's 100ms to 2ms Journey

Lisa's e-commerce platform served 10 million users. Product pages loaded in 100ms - acceptable but not great. Her manager wanted sub-10ms response times. Here's how caching made it possible...

😔 The Problem: Everything from Disk

Lisa's Initial Setup:

📊 Read Pattern: Product catalog (1M products, heavily read)
⚡ Query Latency: 100ms per product page
💾 Caching: None - every read hits disk!
🔥 Disk I/O: 80% utilization (bottleneck!)
😡 User Experience: Pages felt sluggish

What Was Happening:

Every Query: Read from 5-10 SSTables on disk
Bloom Filter Check: 0.5ms (in memory - fast)
Partition Index Lookup: 5ms (disk read - slow!)
Data Block Read: 10-20ms per SSTable
Multiple SSTables: 5-10 SSTables × 15ms = 75-150ms!
Total: 100ms average, 200ms P99

                    -- Every product query hit disk
                    SELECT * FROM products 
                    WHERE product_id = 12345;

                    -- Execution breakdown:
                    /*
                    Bloom filter checks: 0.5ms (memory ✓)
                    Partition index reads: 5ms × 10 SSTables = 50ms (disk ✗)
                    Data block reads: 5ms × 10 SSTables = 50ms (disk ✗)
                    Total: 100ms
                    */
                                    

🚀 The Solution: Three-Layer Caching!

Lisa's Optimized Setup:

Layer 1: Row Cache (Hot Products)

                    -- Enable row cache for top 10K products
                    ALTER TABLE products
                    WITH caching = {
                        'keys': 'ALL',
                        'rows_per_partition': 'ALL'
                    };

                    -- Configure in cassandra.yaml:
                    row_cache_size_in_mb: 2048  # 2GB for hot products
                                        

✅ Result: Hot products served from RAM - 0.5ms latency!

Layer 2: Key Cache (Always On)

                    -- Already enabled by default!
                    key_cache_size_in_mb: 1024  # 1GB (default: auto)
                                        

✅ Result: Skip partition index reads - saves 5-10ms!

Layer 3: OS Page Cache (Automatic)

                    -- Use remaining RAM for OS page cache
                    -- 64GB server:
                    --   JVM heap: 16GB
                    --   Row cache: 2GB
                    --   Key cache: 1GB
                    --   OS page cache: 45GB (automatic!)
                                        

✅ Result: Frequently accessed SSTables cached - 2-5ms!

The Results:

⚡ Hot Products: 100ms → 0.5ms (200x faster!)
⚡ Warm Products: 100ms → 2-5ms (20-50x faster!)
⚡ Cold Products: 100ms → 10-20ms (still 5-10x faster!)
📊 Cache Hit Rate: 95% (excellent!)
💾 Disk I/O: 80% → 20% (freed up disk!)
😊 User Experience: Pages feel instant!

Lisa learned: Caching = 100x performance improvement for free! 🎉

💾 Caching Fundamentals

Understand how Cassandra's multi-layer caching works!

🎯 Why Caching Matters

Cassandra's read path involves multiple disk I/O operations. Each SSTable read takes 5-20ms on SSD. Caching stores frequently accessed data in RAM (0.1ms access time), making reads 100-200x faster!

The Read Path Without Caching

Cassandra's Three Cache Layers

🔥

Row Cache

What: Entire rows in memory
Speed: 0.1-0.5ms (fastest!)
Use Case: Hot data (top 10%)
Size: 1-5GB typical
Hit Rate: 90%+ for hot data

🔑

Key Cache

What: Partition key locations
Speed: 1-2ms (fast!)
Use Case: Skip index lookup
Size: 100MB-1GB typical
Hit Rate: 95%+ always on

💾

OS Page Cache

What: SSTables in OS memory
Speed: 2-5ms (good!)
Use Case: Warm data
Size: All remaining RAM
Hit Rate: 60-80% for warm

🔥 Row Cache (Layer 1)

The fastest cache - stores entire rows in memory!

⚡ How Row Cache Works

Row cache stores complete partition data in off-heap memory. When a row is cached, Cassandra can return it in 0.1-0.5ms without touching SSTables at all. It's 100-200x faster than disk!

Enabling Row Cache

                    -- Enable row cache for a table
                    ALTER TABLE products
                    WITH caching = {
                        'keys': 'ALL',                    -- Cache all partition keys
                        'rows_per_partition': '100'    -- Cache up to 100 rows per partition
                    };

                    -- Cache entire partitions
                    ALTER TABLE user_profiles
                    WITH caching = {
                        'keys': 'ALL',
                        'rows_per_partition': 'ALL'    -- Cache all rows in partition
                    };

                    -- Disable row cache
                    ALTER TABLE large_table
                    WITH caching = {
                        'keys': 'ALL',
                        'rows_per_partition': 'NONE'   -- No row caching
                    };
                        

Row Cache Configuration

                    -- In cassandra.yaml

                    # Row cache size (off-heap memory)
                    row_cache_size_in_mb: 2048        # 2GB (0 = disabled)

                    # How often to save cache to disk
                    row_cache_save_period: 14400     # 4 hours (0 = disabled)

                    # Number of keys to save
                    row_cache_keys_to_save: 100      # Save top 100 (unlimited = all)

                    # Cache provider
                    row_cache_class_name: org.apache.cassandra.cache.OHCProvider  # Off-heap
                        

When to Use Row Cache

✅

Perfect For

Hot Data: Top 10% most accessed
Small Rows: < 1KB per row
Read-Heavy: 95%+ reads
Predictable Access: Same data repeatedly
Low Cardinality: Few distinct keys

Examples: User sessions, product catalog

❌

Avoid For

Large Rows: > 10KB per row
Write-Heavy: Frequent updates
High Cardinality: Millions of unique keys
Random Access: No clear hot data
Memory Limited: < 16GB RAM

Examples: Time-series, logs, analytics

Row Cache Performance Impact

Cache Hit (Fast Path)

                    -- Query for cached product
                    SELECT * FROM products 
                    WHERE product_id = 12345;

                    -- Execution with row cache hit:
                    /*
                    1. Check row cache: 0.1ms ✓ FOUND!
                    2. Return from memory: 0.1ms
                    Total: 0.2ms ⚡⚡⚡
                    */
                                    

Cache Miss (Slow Path)

                    -- Query for uncached product
                    SELECT * FROM products 
                    WHERE product_id = 99999;

                    -- Execution with row cache miss:
                    /*
                    1. Check row cache: 0.1ms ✗ NOT FOUND
                    2. Bloom filter: 0.5ms
                    3. Partition index: 5ms (disk)
                    4. Data block: 10ms (disk)
                    5. Cache the result: 0.5ms
                    Total: 16ms (then cached for next time!)
                    */
                                    

Row Cache Gotchas

⚠️ Invalidation on Write: Any update invalidates entire partition from cache
⚠️ Cold Start: Cache empty after restart (unless saved)
⚠️ Memory Pressure: Can cause GC issues if too large
⚠️ Not for TTL Data: Cached even after expiration (until invalidated)

Monitoring Row Cache

                    -- Check cache statistics
                    nodetool info | grep -i cache

                    -- Output:
                    /*
                    Row Cache              : entries 45231, size 1.89 GB, capacity 2 GB
                    Row Cache Hit Rate     : 0.94567 (94.5% ✅ Excellent!)
                    Row Cache Requests     : 1500000
                    Row Cache Hits         : 1418505
                    */

                    -- Good hit rate: > 90%
                    -- Poor hit rate: < 70% (consider disabling)
                        

🔑 Key Cache (Layer 2)

Always-on cache that skips partition index lookups!

🎯 What Key Cache Does

Key cache stores the location of partition keys within SSTables. Without it, Cassandra must read the partition index from disk (5-10ms). With key cache, this lookup happens in memory (< 1ms). It's enabled by default and you should almost never disable it!

Key Cache vs No Key Cache

❌

Without Key Cache

Bloom filter check (0.5ms)
Read partition index from disk (5-10ms 🐌)
Read data block from disk (10ms 🐌)
Total: 15-20ms per SSTable

✅

With Key Cache (Default)

Bloom filter check (0.5ms)
Key cache lookup in memory (0.5ms ⚡)
Read data block from disk (10ms 🐌)
Total: 11ms per SSTable

Saves 5-10ms per SSTable = 50-100ms for 10 SSTables!

Key Cache Configuration

                    -- In cassandra.yaml

                    # Key cache size (defaults to 5% of heap or 100MB)
                    key_cache_size_in_mb: 1024        # 1GB recommended

                    # How often to save cache to disk
                    key_cache_save_period: 14400     # 4 hours

                    # Keys to save per SSTable
                    key_cache_keys_to_save: 100      # unlimited = all
                        

Sizing Key Cache

Key Cache Size Formula

Each cached key entry is approximately 200 bytes

                    -- Calculate required key cache size:
                    key_cache_size = num_partitions × 200 bytes

                    -- Example: 5 million partitions
                    // 5,000,000 × 200 bytes = 1GB

                    -- Example: 50 million partitions
                    // 50,000,000 × 200 bytes = 10GB
                            

Monitoring Key Cache

                    -- Check key cache statistics
                    nodetool info | grep -i "Key Cache"

                    -- Output:
                    /*
                    Key Cache              : entries 5234567, size 987 MB, capacity 1 GB
                    Key Cache Hit Rate     : 0.99123 (99.1% ✅ Excellent!)
                    Key Cache Requests     : 50000000
                    Key Cache Hits         : 49561500
                    */

                    -- Good hit rate: > 95%
                    -- If < 95%: Increase key_cache_size_in_mb
                        

Key Cache Best Practices

✅ Always Keep Enabled: It's always beneficial
✅ Size Appropriately: Should cache all partition keys if possible
✅ Monitor Hit Rate: Target > 95%
✅ Save Period: Enable save_period to survive restarts

💾 OS Page Cache (Layer 3)

The automatic cache that uses remaining system RAM!

🎯 How OS Page Cache Works

The operating system automatically caches file contents in unused RAM. When Cassandra reads an SSTable from disk, the OS caches those blocks. Next read? Served from RAM at 2-5ms instead of 10-20ms from disk. It's completely automatic and uses all RAM not allocated to JVM/caches!

Memory Allocation Strategy

OS Page Cache Benefits

✅

Advantages

Automatic: Zero configuration needed
Large: Uses all free RAM (45GB+)
No GC: Doesn't affect JVM
Smart: OS manages LRU automatically
Universal: Works for all tables

💡

How to Optimize

More RAM: More cache space
Small JVM Heap: 8-16GB leaves more for OS
Compression: More data fits in cache
Fewer SSTables: Better cache utilization
Hot Paths: Frequently read data stays cached

Monitoring OS Page Cache

                    -- Check OS cache usage (Linux)
                    free -h

                    -- Output:
                    /*
                                total        used        free      shared  buff/cache   available
                    Mem:           64G         18G         1G        100M         45G         44G
                                
                    Breakdown:
                    - Total RAM: 64GB
                    - Used (JVM): 18GB (heap + caches)
                    - Free: 1GB (unused)
                    - buff/cache: 45GB ← THIS IS OS PAGE CACHE! ⭐
                    - available: 44GB (can be used if needed)
                    */

                    -- Good: buff/cache > 50% of total RAM
                    -- Problem: buff/cache < 20% (need more RAM or reduce heap)
                        

OS Cache Effectiveness

Rule of Thumb:

If working set < OS cache size → 90%+ cache hit rate
If working set > OS cache size → Cache hit rate drops
Example: 100GB SSTables, 45GB OS cache → Top 45GB cached (hot data)

🎯 Caching Strategy Guide

Choose the right caching configuration for your workload!

Decision Matrix

Workload Type	Row Cache	Key Cache	OS Cache
Read-Heavy, Hot Data	✅ 2-5GB	✅ 1GB	✅ Rest of RAM
Write-Heavy	❌ Disabled	✅ 1GB	✅ Rest of RAM
Time-Series	❌ Disabled	✅ 500MB	✅ Rest of RAM
Mixed Workload	⚠️ 1-2GB (selective)	✅ 1GB	✅ Rest of RAM
Small Dataset	✅ 1-2GB	✅ 500MB	✅ Rest of RAM

Common Caching Configurations

Configuration 1: E-Commerce Product Catalog

                    -- Workload: 95% reads, hot products (top 10%)

                    -- Table config
                    ALTER TABLE products
                    WITH caching = {
                        'keys': 'ALL',
                        'rows_per_partition': 'ALL'  -- Cache hot products
                    };

                    -- cassandra.yaml
                    row_cache_size_in_mb: 4096      # 4GB for top 10K products
                    key_cache_size_in_mb: 1024      # 1GB for all keys

                    -- Result: Hot products in 0.5ms! ⚡
                                    

Configuration 2: User Session Store

                    -- Workload: 90% reads, frequent updates, hot sessions

                    -- Table config
                    ALTER TABLE sessions
                    WITH caching = {
                        'keys': 'ALL',
                        'rows_per_partition': '100'  -- Active sessions
                    };

                    -- cassandra.yaml
                    row_cache_size_in_mb: 2048      # 2GB for 1M active sessions
                    key_cache_size_in_mb: 1024      # 1GB

                    -- Result: Active sessions in 1ms! ⚡
                                    

Configuration 3: IoT Time-Series

                    -- Workload: 80% writes, mostly recent data reads

                    -- Table config
                    ALTER TABLE sensor_data
                    WITH caching = {
                        'keys': 'ALL',
                        'rows_per_partition': 'NONE'  -- No row cache (write-heavy)
                    };

                    -- cassandra.yaml
                    row_cache_size_in_mb: 0         # Disabled
                    key_cache_size_in_mb: 512       # 512MB

                    -- Rely on OS page cache for recent data
                                    

Configuration 4: Analytics (Large Scans)

                    -- Workload: Large range queries, no clear hot data

                    -- Table config
                    ALTER TABLE events
                    WITH caching = {
                        'keys': 'ALL',
                        'rows_per_partition': 'NONE'  -- No benefit from row cache
                    };

                    -- cassandra.yaml
                    row_cache_size_in_mb: 0         # Disabled
                    key_cache_size_in_mb: 1024      # 1GB

                    -- OS cache handles warm data automatically
                                    

💼 Interview Questions & Expert Answers

Master caching strategies for your interview!

1 Explain the difference between row cache, key cache, and OS page cache. When would you use each? ▼

Answer: Row cache stores entire rows in off-heap memory (0.5ms), key cache stores partition key locations (skips 5ms disk read), and OS page cache automatically caches SSTable blocks in remaining RAM (2-5ms).

Cache Type	What It Caches	Speed	When to Use
Row Cache	Entire partitions	0.5ms ⚡⚡⚡	Hot data, read-heavy, small rows
Key Cache	Partition key locations	1-2ms ⚡⚡	Always! (default on)
OS Cache	SSTable blocks	2-5ms ⚡	Always! (automatic)

Detailed Explanation:

Row Cache:

Stores complete serialized partition data
Hit = instant return from memory
Miss = read from disk + cache for next time
Invalidated on any write to partition
Use for: Product catalogs, user profiles (read-heavy, hot data)

Key Cache:

Maps partition key → SSTable offset
Skips partition index read from disk
Saves 5-10ms per SSTable lookup
Small memory footprint (200 bytes per key)
Use for: Everything! Should always be enabled

OS Page Cache:

Operating system caches file blocks automatically
Uses all RAM not allocated to JVM/caches
No configuration needed - just works!
LRU managed by OS kernel
Use for: Everything! Maximize by keeping JVM heap small (8-16GB)

Key Takeaway: Key cache and OS cache are always beneficial. Row cache only for specific read-heavy workloads with hot data!

2 Why might enabling row cache actually hurt performance in some scenarios? ▼

Answer: Row cache can hurt performance when data is write-heavy (frequent invalidations), has large rows (wastes cache space), or has no clear hot data (low hit rate). It also uses off-heap memory that could be better used by OS page cache.

Scenarios Where Row Cache Hurts:

Problem 1: Write-Heavy Workload

Every write invalidates entire partition from cache
Cache constantly being invalidated and re-populated
Cache hit rate drops to 20-30% (useless!)
Wasting memory that could be used by OS cache

                    -- Example: Session store with frequent updates
                    // 1000 writes/sec per session
                    // Row cache hit rate: 25% (terrible!)
                    // Better: Disable row cache, rely on OS cache
                                            

Problem 2: Large Rows

2GB cache / 100KB per row = only 20K rows cached
Most rows never fit in cache (cache thrashing)
OS page cache could cache 2GB of SSTable blocks instead
OS cache benefits ALL tables, not just one

Problem 3: No Hot Data (Uniform Access)

Time-series: Access mostly recent data (not same rows)
Analytics: Large scans touch different data each time
Random access: No pattern to cache
Cache hit rate: 10-20% (waste of memory)

Problem 4: Memory Pressure

Row cache uses off-heap memory (outside JVM)
On 16GB server, 2GB row cache = less for OS cache
OS cache benefits all reads, row cache only cached rows
Better: Give memory to OS cache for universal benefit

When Row Cache Makes Sense:

Factor	Good for Row Cache	Bad for Row Cache
Read/Write Ratio	95%+ reads	< 80% reads
Row Size	< 1KB	> 10KB
Access Pattern	Hot data (top 10%)	Uniform or sequential
Cache Hit Rate	> 90%	< 70%

Key Takeaway: Monitor row cache hit rate. If < 70%, disable it and let OS page cache do the work!

3 How would you size the different caches for a 64GB RAM server running Cassandra? ▼

Answer: JVM heap 16GB (25%), row cache 2-4GB if applicable, key cache 1GB, leaving 45-47GB (70%) for OS page cache. The key is maximizing OS cache since it benefits all reads.

Recommended Allocation for 64GB Server:

Total: 64GB RAM

JVM Heap: 16GB (25%) - Never exceed 32GB!
Row Cache: 2-4GB (3-6%) - Only if read-heavy with hot data
Key Cache: 1GB (1.5%) - Always enable
OS Page Cache: 45-47GB (70%) - The magic happens here!

Configuration:

                    -- jvm.options
                    -Xms16G
                    -Xmx16G

                    -- cassandra.yaml
                    row_cache_size_in_mb: 4096      # 4GB (or 0 if not needed)
                    key_cache_size_in_mb: 1024      # 1GB

                    -- Memory breakdown:
                    /*
                    JVM heap:       16GB (GC-managed)
                    Row cache:       4GB (off-heap, manual management)
                    Key cache:       1GB (off-heap, manual management)
                    OS page cache:  43GB (kernel-managed, automatic!)
                    Total:          64GB
                    */
                                        

Why This Allocation?

JVM Heap (16GB):

Enough for memtables, bloom filters, compression buffers
Not too large (> 32GB causes long GC pauses)
Sweet spot: 8-16GB for most workloads

Row Cache (2-4GB):

Only if you have clear hot data (top 10% of rows)
Size based on: hot_rows × avg_row_size
Example: 1M hot products × 2KB = 2GB
If no hot data, set to 0 and use that RAM for OS cache!

Key Cache (1GB):

Formula: num_partitions × 200 bytes
5M partitions × 200 bytes = 1GB
Should cache all partition keys if possible
Monitor hit rate, increase if < 95%

OS Page Cache (43GB - Most Important!):

Automatically caches frequently accessed SSTable blocks
Benefits ALL tables, not just one
No configuration needed - just maximize available RAM
This is where most performance gains come from!

Alternative Configurations:

                    -- Config A: Read-heavy with hot data
                    JVM: 16GB, Row: 4GB, Key: 1GB, OS: 43GB

                    -- Config B: Write-heavy / No hot data
                    JVM: 16GB, Row: 0GB, Key: 1GB, OS: 47GB ✨ More for OS!

                    -- Config C: Memory-constrained (32GB total)
                    JVM: 8GB, Row: 1GB, Key: 512MB, OS: 22GB
                                        

Key Principle: When in doubt, give more RAM to OS page cache! It's universally beneficial and requires zero configuration.

4 What metrics would you monitor to determine if your caching strategy is effective? ▼

Answer: Monitor cache hit rates (row cache > 90%, key cache > 95%), read latency P99, disk I/O utilization, and cache size vs capacity. Poor hit rates or high disk I/O indicate caching issues.

Key Metrics to Monitor:

1. Cache Hit Rates

                    -- Check all cache statistics
                    nodetool info | grep -i cache

                    -- Output:
                    /*
                    Row Cache Hit Rate     : 0.94567 (94.5%)
                    Key Cache Hit Rate     : 0.99123 (99.1%)
                    */

                    -- Target hit rates:
                    // Row Cache: > 90% (if enabled)
                    // Key Cache: > 95% (should always be high)
                                            

What Hit Rates Mean:

Row Cache > 90%	✅ Excellent! Hot data well-cached
Row Cache 70-90%	⚠️ OK, consider increasing size
Row Cache < 70%	❌ Disable it! Wasting memory
Key Cache < 95%	❌ Increase size!

2. Read Latency

                    -- Check table read latency
                    nodetool tablestats keyspace.table | grep -i latency

                    -- Output:
                    /*
                    Local read latency: 2.5 ms
                    Local read P99 latency: 12 ms
                    */

                    -- Good caching indicators:
                    // Average < 5ms (hot data from cache)
                    // P99 < 20ms (even cold reads reasonably fast)
                                            

Latency Breakdown:

0.5-2ms: Row cache hit (excellent!)
2-5ms: OS cache hit (good!)
10-20ms: Disk read (acceptable)
> 50ms: Too many SSTables or slow disks (problem!)

3. Disk I/O Utilization

                    -- Check disk I/O (Linux)
                    iostat -x 5

                    -- Look at %util column:
                    /*
                    Device    r/s    w/s    %util
                    sda      500    200     45%     ← Good! Caching working
                    sdb     2000    500     95%     ← Bad! Cache not helping
                    */

                    -- Good caching: Disk < 60% utilized
                    -- Poor caching: Disk > 80% utilized
                                            

4. Cache Size vs Capacity

                    nodetool info | grep -i cache

                    /*
                    Row Cache: entries 45231, size 1.89 GB, capacity 2 GB
                                                            ↑            ↑
                                                        using 95%    allocated
                    */

                    -- If size ≈ capacity: Cache is full (good if hit rate high)
                    -- If size << capacity: Over-allocated (reduce size)
                                            

5. OS Memory Usage

                    free -h

                    /*
                                total   used   free   buff/cache
                    Mem:           64G    18G     1G         45G
                                                            ↑
                                                    OS page cache!
                    */

                    -- Good: buff/cache > 50% of total RAM
                    -- Problem: buff/cache < 30% (increase available RAM)
                                            

Decision Matrix:

Symptom	Diagnosis	Action
Row cache hit < 70%	No clear hot data	Disable row cache
Key cache hit < 95%	Cache too small	Increase key_cache_size_in_mb
High disk I/O (> 80%)	Cache misses	Add RAM or reduce heap
P99 latency > 50ms	Cold reads slow	Check SSTable count, compaction

Monitoring Best Practices:

✅ Check cache hit rates daily
✅ Alert if row cache < 70% (disable it!)
✅ Alert if key cache < 95% (increase size!)
✅ Monitor P99 latency trends
✅ Track disk I/O utilization

5 Explain what happens to row cache when you update or delete a row. Why is this important for write-heavy workloads? ▼

Answer: Any write (update, delete, insert) to a partition invalidates the ENTIRE partition from row cache. For write-heavy workloads, this causes constant cache invalidation, resulting in low hit rates and wasted memory.

What Happens on Write:

Write Arrives: UPDATE user SET name = 'Jane' WHERE user_id = 123
Write to Commit Log: Written to disk (durable)
Write to Memtable: In-memory write
Invalidate Row Cache: ENTIRE partition for user_id=123 removed from cache!
Acknowledge Write: Success returned to client
Next Read: Cache miss → read from disk → cache again

Why Invalidate Entire Partition?

Row cache stores serialized partition data. Cassandra can't easily update just one column in cached data. Simpler/safer to invalidate entire partition and re-cache on next read.

                    -- Example: Write-heavy workload

                    -- User session with frequent updates:
                    UPDATE sessions 
                    SET last_activity = now() 
                    WHERE session_id = 123;
                    -- ← Entire partition invalidated from cache!

                    -- 10 seconds later, another update:
                    UPDATE sessions 
                    SET last_activity = now() 
                    WHERE session_id = 123;
                    -- ← Invalidated again!

                    -- Result: Cache constantly churning, low hit rate!
                                        

Impact on Write-Heavy Workloads:

Workload	Read/Write	Cache Hit Rate	Recommendation
Product Catalog	99% read, 1% write	95%+ ✅	Enable row cache
User Profiles	90% read, 10% write	70-85% ⚠️	Maybe (test it!)
Shopping Carts	70% read, 30% write	40-60% ❌	Disable row cache
Sessions (active)	60% read, 40% write	20-30% ❌	Disable row cache
Time-Series	20% read, 80% write	< 10% ❌	Disable row cache

Real-World Example:

                    -- Shopping cart: 1000 updates/minute per cart
                    // Write every 6 seconds on average
                    // Cache invalidated every 6 seconds
                    // Cache only useful for 6 seconds!
                    // Hit rate: 25% (terrible!)

                    -- Solution: Disable row cache
                    ALTER TABLE shopping_carts
                    WITH caching = {
                        'keys': 'ALL',
                        'rows_per_partition': 'NONE'  -- Disabled!
                    };

                    -- Result: 2GB freed for OS cache
                    // OS cache helps ALL reads, not just cached rows
                    // Better overall performance!
                                        

Key Takeaway: Row cache only helps when reads significantly outnumber writes (95%+ read ratio). For write-heavy workloads, disable it and use that memory for OS page cache!

🎓 Chapter Summary: Caching Strategy Mastery

You now understand Cassandra's caching system at a production level!

The Three Cache Layers:

🔥 Row Cache: 0.5ms - Hot data only (read-heavy, hit rate > 90%)
🔑 Key Cache: 1-2ms - Always enable! (saves 5-10ms per SSTable)
💾 OS Page Cache: 2-5ms - Automatic! (maximize by keeping heap small)

Golden Rules:

✅ Always enable key cache - universally beneficial
✅ Maximize OS page cache - keep JVM heap 8-16GB
⚠️ Row cache only for read-heavy - 95%+ reads with hot data
❌ Disable row cache if hit rate < 70% - wasting memory

64GB Server Allocation:

JVM: 16GB | Row: 0-4GB | Key: 1GB | OS: 43-47GB

Remember Lisa: 100ms → 0.5ms with proper caching! 🚀

Responsive Ad