liveBook · Manning

Materialized view

As explained in Kafka for Architects

A materialized view is a stored, continuously maintained representation of query results that can be read without recomputing the underlying query.

A materialized view stores a continuously updated, precomputed representation of query results. In ksqlDB, it is locally stored in RocksDB and replicated through Kafka, allowing keyed queries to return current state immediately without scanning a topic. section 8.4.1

This contrasts with querying a stream or table directly: a pull query scans the underlying Kafka topic or changelog for the latest matching record, while a materialized view reads an already indexed result. Pull queries remain transient and terminate after returning the current state. section 8.4.1

Aggregated order state

An order-count view groups orders by country and maintains the resulting totals as events arrive, making current aggregate state available for immediate keyed reads. section 8.4.1

Listing 8.5 Counting the number of orders per country
CREATE TABLE Orders_Count_By_Country AS
    SELECT country, COUNT(*) AS total_orders  #1
    FROM Orders
    GROUP BY country  #2
    EMIT CHANGES;

Browse a ksqlDB definition that creates a maintained table of order counts grouped by country. section 8.4.1

How Kafka for Architects covers it

How deep it goes
Explains local storage, indexing, RocksDB backing, and Kafka replication, but not view-maintenance internals.
Examples
Demonstrates a maintained order-count table grouped by country.
What you can do after
Evaluate current-state query trade-offs between indexed views and direct topic scans.
How it connects
Connects materialized views with pull queries, Kafka topics, changelogs, RocksDB, Kafka Streams, and ksqlDB.

Also explained in

Compare how 5 books explain materialized view →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kafka for Architects. The section links point to the parts of the book it draws on.