Cassandra hard
In a cluster with high 'Mutation' (Write) frequency, why is the `Row Cache` almost universally disabled by experts?
- A Because it only supports JSON data.
- B Invalidation Storms: Every single write (Update/Delete/Insert) to a row immediately invalidates its entry in the Row Cache. In high-write environments, the 'Hit Rate' falls to zero, but the system still wastes CPU and RAM managing the cache logic.
- C The Row Cache is too fast for the network to handle.
- D It is an enterprise-only feature that requires a specific license key.
Answer: B. Invalidation Storms: Every single write (Update/Delete/Insert) to a row immediately invalidates its entry in the Row Cache. In high-write environments, the 'Hit Rate' falls to zero, but the system still wastes CPU and RAM managing the cache logic.
Unlike some DBs where caching is 'Magic', Cassandra Row Cache is very specific. The 'Key Cache' (which maps keys to disk offsets) is cheap and effective. The Row Cache (which stores full row objects in RAM) is only effective for 'Static' data that is read millions of times more than it is changed.
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?