Cassandra medium
An application uses a Cassandra table as a Queue (heavy insert and heavy delete). Suddenly, queries on empty ranges take several seconds to return. What is the root cause?
- A The cluster has run out of physical disk space.
- B The 'Tombstone Overwhelming' problem: The scanner must skip over millions of physical deletion markers (Tombstones) to prove that there is no 'live' data to return.
- C Cassandra is waiting for a Zookeeper lock that was never released.
- D The client is sending requests via the old Thrift protocol instead of CQL.
Answer: B. The 'Tombstone Overwhelming' problem: The scanner must skip over millions of physical deletion markers (Tombstones) to prove that there is no 'live' data to return.
Since SSTables are immutable, 'Deleting' a row just adds a marker. If your 'Delete Rate' is high, your SSTables fill with tombstones. A query must read everyone—live or dead—to determine what to show the user. Queues are an anti-pattern for Cassandra's LSM Architecture.
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?