Cassandra hard
For a Time-Series workload where 1 billion metrics are stored daily and deleted after 30 days via TTL, why is TWCS significantly more efficient than LCS or STCS?
- A It uses AI to predict when a node will crash.
- B Zero-Impact Deletions: It isolates data into time-based SSTables (buckets). Once the entire window expires, Cassandra can simply drop the physical file from the OS, bypassing the row-by-row tombstone compaction process entirely.
- C It allows the database to run without a Commit Log.
- D It prevents the disk from rotating too fast.
Answer: B. Zero-Impact Deletions: It isolates data into time-based SSTables (buckets). Once the entire window expires, Cassandra can simply drop the physical file from the OS, bypassing the row-by-row tombstone compaction process entirely.
In other strategies, expired data is merged with new data, forcing the database to keep 'checking' it until a tombstone is eventually purged. TWCS groups data by time; when the 'Window' (e.g., 24 hours) is older than the TTL, the whole file is discarded. This results in the lowest possible Disk I/O overhead.
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?