Cassandra hard
Cassandra 3.0+ and 4.0 support moving Memtables and Bloom Filters 'Off-Heap'. What is the primary operational benefit of this configuration for a node with 128GB of RAM?
- A It allows the database to keep running even if the JVM process is killed.
- B It uses the RAM for cold storage backups.
- C GC Latency Reduction: It allows the JVM heap to remain small (e.g., 8-16GB), preventing massive 'Stop-the-World' garbage collection pauses that would occur if 100GB of buffers were inside the heap.
- D It is required for the database to connect to a cloud storage bucket.
Answer: C. GC Latency Reduction: It allows the JVM heap to remain small (e.g., 8-16GB), preventing massive 'Stop-the-World' garbage collection pauses that would occur if 100GB of buffers were inside the heap.
Java's Garbage Collector (G1GC or CMS) must scan all objects in the heap. If you have 64GB of long-lived data (like Bloom Filters) in the heap, scanning them takes forever. Off-heap memory is managed directly by the OS/Cassandra, bypassing the JVM GC entirely and keeping tail-latency (P99.9) low.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- In a Cassandra Keyspace, what does a 'Replication Factor of 3' specifically guarantee for your data redundancy?
- Unlike a Leader-Follower architecture (like MySQL or Redis), how does Cassandra maintain high availability within its node cluster?
- Cassandra Query Language (CQL) looks similar to SQL. What is a fundamental SQL feature that CQL does NOT support to ensure distributed performance?
- What is the critical architectural function of the 'Partition Key' in a Cassandra table?
- Apache Cassandra is fundamentally designed as which architectural category of NoSQL database?
- An extreme financial trading application requires 'Batch' sync for the Commit Log. What is the fundamental throughput limitation introduced by this setting?