Cassandra medium
In Cassandra, a secondary index is 'Local' to the node. What is the fundamental problem when querying a high-cardinality column (like `user_email`) via a secondary index?
- A The index query will only return results from the local node where the client happened to connect.
- B The index is stored in a centralized database which becomes a bottleneck.
- C The 'Scatter-Gather' effect: Because the Partition Key is unknown, the Coordinator must query every single node in the cluster, causing latency to spike as the cluster grows.
- D Secondary indexes are limited to exactly 1,000 entries total per table.
Answer: C. The 'Scatter-Gather' effect: Because the Partition Key is unknown, the Coordinator must query every single node in the cluster, causing latency to spike as the cluster grows.
Standard Cassandra queries are 'O(1)' (the hash tells you exactly where to go). Index queries are 'O(N)' (N = number of nodes). For high-cardinality fields, it is almost always better to create a 'Manual Index Table' (denormalization) where the field is part of a real Partition Key.
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?