Cassandra medium
A table for 'Global Events' uses a constant value (e.g., `event_log`) as its Partition Key. This allows it to store all historical events in a single partition. Why is this model critically flawed at scale?
- A It creates a 'Hot Partition': One specific node must handle 100% of the writes and store 100% of the data, while other cluster nodes sit idle.
- B Cassandra forbids partitions from containing more than exactly 1,000 rows.
- C Data within a single partition cannot be sorted by time.
- D Using a constant partition key makes it impossible to use the `DELETE` command.
Answer: A. It creates a 'Hot Partition': One specific node must handle 100% of the writes and store 100% of the data, while other cluster nodes sit idle.
A partition is a unit of distribution. If your key is not diverse, you cannot scale horizontally. Furthermore, massive partitions (>100MB-1GB) cause 'Heap Congestion' during compaction and repair, often leading to node instability and GC pauses.
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?