Generate precomputed or preformatted views of data from one or more data stores when the source data isn't in an ideal format for specific query operations. This pattern supports efficient querying, fast data extraction, and improved application performance. Trade-offs get attention as well, covering disposable read-only views that can be rebuilt from source and the eventual consistency model the approach accepts.
Summary
- Problem: Data stores (especially NoSQL) are usually optimized for writes rather than reads. When a complex query needs to combine data from several entities or compute aggregate values, performance suffers badly if raw data has to be processed every time.
- Solution: Create a "view" that holds the results of complex queries and store it physically (materialized). The view contains only the data required for a specific query or a set of related queries.
- Characteristics of a materialized view:
- Disposable: The view can be deleted and completely rebuilt from the source data at any time.
- Read-only: The application never updates the materialized view directly; it only reads from it.
- Precomputed: It can include computed columns, transformation results, or the results of joins across multiple tables/partitions.
- Refresh mechanisms:
- Event-driven: Update the view as soon as the source data changes (often combined with the CQRS or Event Sourcing patterns).
- Scheduled: Update periodically (for example, hourly or daily) if the data doesn't need to be highly real time.
- Benefits:
- Significantly improves query performance for complex reports or dashboards.
- Reduces load on the primary data stores.
- Simplifies application code because complex join/aggregation logic doesn't have to run on the client side.
When to Use This Pattern
- When the source data is hard to query directly (unstructured, semi-structured, or distributed data).
- When you need temporary views to serve reports, the UI, or data extraction.
- When you need to support offline scenarios by caching the view data locally.
- When you need to grant access to subsets of data for security reasons (you don't want to expose all the source data).
When Not to Use This Pattern
- The source data is simple and easy to query with good performance.
- The source data changes so quickly that the cost of updating the view exceeds the benefit.
- The system requires immediate (strong) consistency. Materialized views typically follow an eventual consistency model.
Relationship with Other Patterns
- CQRS: Often used to separate the read side (using a materialized view) from the write side.
- Event Sourcing: A materialized view is the only practical way to get the current state of an entity from a sequence of events.
Source: Microsoft Learn - Materialized View Pattern
See also: CQRS Pattern · Event Sourcing Pattern · Index Table Pattern