What are materialized views in Cassandra?
Understand Cassandra materialized views: how they auto-sync a base table under a new key, their CQL syntax, trade-offs, and when to avoid them.
Expected Interview Answer
A materialized view in Cassandra is a server-maintained table that automatically mirrors data from a base table under a different primary key, letting you query the same data by a new access pattern without writing to two tables yourself. Cassandra keeps the view in sync as the base table changes.
You define a view with CREATE MATERIALIZED VIEW AS SELECT, choosing a new partition and clustering key so queries can filter the data differently. Every insert, update, or delete on the base table triggers a corresponding write to the view, handled by the coordinator. This automates the denormalization Cassandra normally requires, but it carries caveats: views add write amplification, can drift out of sync under certain failure scenarios, and were long marked experimental — so many teams still prefer manual denormalized tables in production.
- Automatic synchronization from base table to view
- Query the same data by an alternative key without app-side dual writes
- Reduces boilerplate compared to hand-maintained denormalized tables
- Consistent view definition enforced by the server
- Simplifies read paths for secondary access patterns
AI Mentor Explanation
A materialized view is like a second scoreboard that automatically re-sorts the same match data by bowler instead of by batter. You never update it by hand — every ball logged on the main board instantly reappears, reorganized, on the bowler board. That auto-mirroring under a new arrangement is exactly what Cassandra does when it keeps a view in sync with its base table.
Step-by-Step Explanation
Step 1
Start with a base table
Define your primary table with its natural partition key and columns.
Step 2
Pick a new access pattern
Decide which alternative column you need to query the same data by.
Step 3
Create the view
Use CREATE MATERIALIZED VIEW AS SELECT with a new PRIMARY KEY covering the base key columns.
Step 4
Let Cassandra sync
Writes to the base table automatically propagate to the view — no dual writes in your app.
Step 5
Weigh the trade-offs
Account for write amplification and potential drift; consider manual denormalization for critical paths.
What Interviewer Expects
- Definition as a server-maintained, auto-synced denormalized table
- Understanding the CREATE MATERIALIZED VIEW AS SELECT syntax and key rules
- Awareness of write amplification and consistency caveats
- Knowing views were experimental and why teams may avoid them
- Comparison with manual denormalized tables
Common Mistakes
- Thinking a view is a virtual query rather than a stored copy
- Omitting base primary key columns from the view's primary key
- Ignoring write amplification on high-throughput base tables
- Assuming views never drift out of sync with the base table
- Using views for many access patterns without measuring cost
Best Answer (HR Friendly)
“A materialized view is a second copy of a table that Cassandra keeps automatically up to date, but organized by a different key so you can look up the same data in another way. It saves you from manually maintaining duplicate tables, though it adds extra write work behind the scenes.”
Code Example
CREATE TABLE users (
user_id uuid PRIMARY KEY,
country text,
email text
);
CREATE MATERIALIZED VIEW users_by_country AS
SELECT user_id, country, email
FROM users
WHERE country IS NOT NULL AND user_id IS NOT NULL
PRIMARY KEY (country, user_id);
-- Now queryable by country, auto-synced from users
SELECT * FROM users_by_country WHERE country = 'India';Follow-up Questions
- How does a materialized view differ from a secondary index?
- What causes a materialized view to drift out of sync?
- Why must the view's primary key include the base primary key columns?
- What is write amplification and how do views cause it?
- When would you choose manual denormalization over a view?
MCQ Practice
1. How is a Cassandra materialized view kept up to date?
Cassandra propagates every base-table write to the view automatically, so the app doesn't dual-write.
2. What must a materialized view's primary key always include?
The view's key must cover all base primary key columns so each base row maps to exactly one view row.
3. A key drawback of materialized views is?
Each base write triggers a view write (amplification), and views can drift out of sync under some failure conditions.
Flash Cards
What is a materialized view in Cassandra? — A server-maintained table mirroring a base table under a different primary key, auto-synced on writes.
View vs secondary index? — A view is a full stored copy re-keyed; a secondary index is a per-node index of one column.
Main downside of views? — Write amplification and potential inconsistency/drift under failures.
What must the view key contain? — All of the base table's primary key columns, plus the new access column.