What are the differences and advantages from the materialized view capability in StarRocks Community Edition and Apache Doris?

[sszc]

The StarRocks Community Edition and Apache Doris both support direct data ingestion from Kafka. They also use materialized views for aggregation and real-time data reflection through landing tables. I'm curious about the distinctions and advantages that RisingWave offers in comparison.

[lmatz]

Ease-of-use

If we take a look at Starrock's 2024 roadmap: StarRocks/starrocks#39686 (comment)

we can find that:

support incremental refresh of MV(like flink stream computing), rather than refresh a whole table or partition

This is a critical difference.
Risingwave, as well as Flink, does fully incremental computation with no limitations, i.e. we write an SQL and the execution engine will take every opportunity to do incremental computation without any user intervention. Risingwave has no such concept as "refresh a whole or partition". The "refresh" in Risingwave is always continuous and incremental. Logically, it is the most efficient way of keeping the materialized view up to date with the input data(or let's say base table).

In practice, Risingwave's SQL is compatible with Postgres and it just works. No matter whether aggregation, join, distinct, top-n, or anything, they are all supported and computed incrementally.

Low-latency & High-freshness

There is no new concept or know-how that a user of Risingwave needs to learn. It just works and works efficiently. Risingwave is a dedicated incremental computation engine that is purposely built and delivers sub-second latency/freshness.

Consistency

Besides, Risingwave guarantees consistency among all the materialized views when you query them. In short, all the materialized views (if they are reading input from the same sources, i.e. the same Kafka topic, or CDC from the same Postgres table), they must reflect the changes induced by the same set of data.

Super Fast Scaling

The throughput of streaming data typically fluctuates a lot. When any system continuously and incrementally computes a materialized view, it needs to constantly adjust its resources to match the current workload, e.g. avoid wasting resources or fall short of handling throughput spikes.
Risingwave, due to its storage-compute decoupled architecture, can scale in/out/up/down within single-digit seconds.

[sszc]

Thank you very much for your response.

[yingjunwu]

hey @sszc - thanks for your interest. Please check the answer here: https://tutorials.risingwave.com/docs/faq#how-are-the-materialized-views-in-streaming-databases-different-from-those-in-olap-databases.

Compared to certain OLAP databases' materialized views, RisingWave can reduce cost by 95% in production use cases: https://risingwave.com/blog/95-cost-reduction-how-risingwave-powers-metabit-tradings-real-time-monitoring-platform/.

[sszc]

Thank you very much for your response.
Currently, it appears that RisingWave cluster deployment can only be carried out through Kubernetes (K8s). Are there any plans to provide a conventional cluster deployment method?