peloton
risingwave
peloton | risingwave | |
---|---|---|
3 | 27 | |
1,888 | 6,394 | |
- | 3.5% | |
10.0 | 10.0 | |
about 5 years ago | 3 days ago | |
C++ | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
peloton
-
Building a New Database Management System in Academia
Proud to see my name (https://twitter.com/YingjunWu) mentioned in Andy's blog. I was Andy's visiting PhD at CMU and was the top 1 contributor to Peloton (https://github.com/cmu-db/peloton).
Today, building a database from scratch is extremely difficult, for several reasons:
-
Rethinking Stream Processing and Streaming Databases
I was one of the main authors of a research project called Peloton (https://github.com/cmu-db/peloton) which was later rebranded to NoisePage (https://github.com/cmu-db/noisepage). The initial version of RisingWave actually borrowed a lot from Peloton (fun fact: that's also how DuckDB https://duckdb.org/ started!), but we decided to rewrite in Rust due to development cost and security (e.g., memory leakage) considerations (more info: https://www.risingwave-labs.com/blog/building-a-cloud-database-from-scratch-why-we-moved-from-cpp-to-rust/).
-
But that would mean caring about the little peons
I'll give you an example from my own industry. At my company we talk to university researchers, and one of the more famous university database researcher came to us to learn about our performance testing, because it turned out that the database they were working on for several years as a research project was completely unusable as they just forgot to think about that aspect. They had to abandon the project because there was no single feature that contributed to the performance issues and fixing the system was harder than starting from scratch. Here's the last commit if you don't believe me.
risingwave
-
Proton, a fast and lightweight alternative to Apache Flink
How does this compare to RisingWave and Materialize?
https://github.com/risingwavelabs/risingwave
-
RisingWave's Roadmap - Redefining Stream Processing with the Rust-Built Streaming Database
Hey everyone - One and a half year ago, we open sourced RisingWave, a Rust-built streaming database, under Apache 2.0 license. Two weeks ago, we released RisingWave 1.3. Just last week, we unveiled RisingWave's roadmap.
- Risingwave: Redefining Stream Processing
-
Highlights of RisingWave v1.3: The Open-Source Streaming Database
Look out for next month’s edition to see what new, exciting features will be added. Check out the RisingWave GitHub repository to stay up to date on the newest features and planned releases.
- Optimizing Rust Code for the Lsm-Tree Iterator in RisingWave
- Hummock: A Storage Engine Designed for Stream Processing
-
RisingWave 1.2 released - the open-source streaming database built in Rust
If interested, please feel free to join our Slack community! Thanks eveyone for your generous support!
-
Query materialized views with Java, Spring, and streaming database
We will spin up on our local environment the existing RisingWave fully-featured demo cluster on GitHub which is composed of multiple RisingWave components. To simplify this task, it leverages docker-compose.yaml file which includes additional containers for Kafka message broker, and data generation service.
-
Real-time Data Processing Pipeline With MongoDB, Kafka, Debezium And RisingWave
To complete the steps in this guide, you must download/clone and work on an existing sample project on GitHub. The project uses Docker for convenience and consistency. It provides a containerized development environment that includes the services you need to build the sample data pipeline.
-
Flink CDC / alternatives
Hey have you looked at RisingWave (https://github.com/risingwavelabs/risingwave) before? It's a stream processing system with PostgreSQL interface. It also have integrations similar to Flink CDC.
What are some alternatives?
kuzu - Embeddable property graph database management system built for query speed and scalability. Implements Cypher.
materialize - The data warehouse for operational workloads.
mutable - A Database System for Research and Fast Prototyping
datafuse - An elastic and reliable Cloud Warehouse, offers Blazing Fast Query and combines Elasticity, Simplicity, Low cost of the Cloud, built to make the Data Cloud easy [Moved to: https://github.com/datafuselabs/databend]
ksql - The database purpose-built for stream processing applications.
greptimedb - An open-source, cloud-native, distributed time-series database with PromQL/SQL/Python supported. Available on GreptimeCloud.
chdb - chDB is an embedded OLAP SQL Engine 🚀 powered by ClickHouse
roapi - Create full-fledged APIs for slowly moving datasets without writing a single line of code.
arroyo - Distributed stream processing engine in Rust
incubator-horaedb - HoraeDB is a high-performance, distributed, cloud native time-series database.
falcor - A JavaScript library for efficient data fetching
debezium - Change data capture for a variety of databases. Please log issues at https://issues.redhat.com/browse/DBZ.