Streams and Tables
Allison Walther
Integration Architect (Presenter)
Streams and Tables
While relational databases center around the concept of a table, ksqlDB has two first-class object types: streams and tables.
Streams are unbounded series of events, while tables are the current state of a given key.
Both streams and tables are built from Apache Kafka topics; the difference is only the semantic interpretation of the data. Which you choose is determined by how you want to use the data.
Taking the chess board example in the graphic above, a single Kafka topic would hold the history of all the moves.
- A ksqlDB stream on that topic would apply a schema to it, and from that you could replay some or all of the game, or identify any events involving a specific piece or square.
- A ksqlDB table on the same topic would apply a schema to it and tell you the current location of each piece. Each time a piece moves (and a new event is written to the Kafka topic), the table updates its state.
To learn more about this important concept in the space of event streaming, see Streams and Tables in Apache Kafka: A Primer.
Use the promo code KSQLDB101 & CONFLUENTDEV1 to get $25 of free Confluent Cloud usage and skip credit card entry.
Be the first to get updates and new content
We will only share developer content and updates, including notifications when new content is added. We will never send you sales emails. 🙂 By subscribing, you understand we will process your personal information in accordance with our Privacy Statement.
Streams and Tables
Hi, I'm Allison Walther with Confluent. Let's take a look at some key, get it, concepts and semantics in ksqlDB. Whilst ksqlDB reads and writes from Kafka topics. It can model how it works with that data in different ways. We've got some sample data here showing where people are going. Each event has a person's name and their current location. We're going to see how these events can be modeled as either a stream or a table and what the difference is. We have a stream on the left and a table on the right. With only one event, they appear identical. As we add a second event, the stream grows. Streams behave the same as their underlying Kafka topics. They are unbounded and append only, so they grow with each new event. Tables, on the other hand, store the latest value of a given key. It's important to note that a key is required in order to have a table. The only way that a table grows in size is as new keys are added. A new person in our case. Now, any events arriving with either key will cause an update to our table. While our stream continues to grow with each new event, a table is a fast way to get the current state of a given key. We can easily tell that Robin is in Ilkley and Allison is in Boulder. But if we wanted to replay the history of their recent movements, the table wouldn't help us. We'd need a stream for that. We can see that streams and tables are just different ways of working with events, each with its own strengths. In our example, we are using the same events for both, but a more realistic example might have inventory as a table and orders as a stream. Together, streams and tables are a powerful combination for building event streaming applications.