Speaker
Abstract
Streaming databases have gained significant attention in recent years. From its name, it is evident that a streaming database combines the power of stream processing and databases. The fundamental concept behind streaming databases is to provide efficient data storage capabilities to facilitate seamless stream processing.
In this presentation, I will delve into the evolution of streaming databases over the past two decades. Furthermore, I will highlight the distinctive features and design principles that set streaming databases apart from conventional database systems and stream processing engines. Through the use of real-world scenarios, I will demonstrate how streaming databases can simplify the data stack and enhance cost efficiency when building real-time applications, such as network monitoring, ad recommendation, and crypto trading.
Interview
I'm the founder of RisingWave Labs, the company that develops a distributed SQL streaming database called RisingWave. Our goal is to make stream processing simpler and more cost efficient.
Streaming databases are gaining popularity these days, but many people wonder how they differ from conventional stream processing systems and real-time OLAP databases. Starting with the basic concept, I will delve into technical details and use cases, explaining why people need streaming databases in their modern data stack.
My primary audience consists of data engineers or engineering leaders seeking modern technologies for real-time analytics and stream processing.
I aim to provide my audience with a comprehensive understanding of the modern real-time data processing ecosystem, empowering them to make informed decisions when choosing among various systems.
Topics
QCon San Francisco 2023 is a three day conference for senior software engineers, architects and team leads. An international program committee of working engineers selects every session. Patterns and practices, not products and pitches.
From the same track
Monday 2 October
10:35 Ballroom A Session Graph Databases LIquid: A Large-Scale Relational Graph Database Scott Meyer Distinguished Software Engineer @LinkedIn, Creator of the Graph Database, LIquid, Metaweb/freebase Alum We describe LIquid(1 2), the graph database built to host LinkedIn. 11:45 Seacliff ABC Session Data PRQL: A Simple, Powerful, Pipelined SQL Replacement Aljaž Mur Eržen Compiler Developer @EdgeDB & PRQL Maintainer Most databases use SQL as the interface to access relational data. Because of that, we associate SQL to be the language of relational algebra. But its affinity with the English language and unclear and inconsistent semantics leave a lot of space for improvements. 13:35 Ballroom A Session Stream Processing Streaming Databases: Embracing the Convergence of Stream Processing and Databases Yingjun Wu Founder and CEO @RisingWave Labs, Previously Engineer @AWS Redshift & Researcher @IBM Research Almaden Streaming databases have gained significant attention in recent years. From its name, it is evident that a streaming database combines the power of stream processing and databases. 14:45 Ballroom A Session Distributed Systems Redesigning OLTP for a New Order of Magnitude Joran Greef Founder and CEO @TigerBeetle The world is becoming more transactional. From colocation and server rental to serverless and usage-based billing. From coal to clean energy and smart meters that arbitrage solar prices 1440 times a month instead of monthly. Not to mention FedNow or the tsunami of instant payments. 15:55 Ballroom A Session Data Lakes Incremental Data Processing with Apache Hudi Saketh Chintapalli, Bhavani Sudha Saktheeswaran Incremental Data Processing is an emerging style of data processing gathering attention recently that has the potential to deliver orders of magnitude speed and efficiency over traditional batch processing on data lakes and data warehouses. 17:05 Ballroom A Session Architecture Sleeping at Scale - Delivering 10k Timers per Second per Node with Rust, Tokio, Kafka, and Scylla Lily Mara, Hunter Laine As a part of OneSignal’s no-code Journeys system, we knew that we would need a way to store billions of timers.