greptimedb VS sled

GreptimeAI, built upon the open-source time-series database GreptimeDB, offers an observability solution for Large Language Model (LLM) applications, currently supporting both LangChain and OpenAI's ecosystem. GreptimeAI enables you to understand cost, performance, traffic and security aspects in real-time, helping teams enhance the reliability of LLM applications.

Continuing to work hard on a new MetricEngine in GreptimeDB. BTW, If you have a keen interest in Rust or database development, GreptimeDB might be a good starting point. Check it out for some good first issues here.

Since the very first day of GreptimeDB going open-source, it embraced the automated software building process with GitHub Actions, and leading to the inaugural Release Pipeline.

Born from the open-source project GreptimeDB, GreptimeCloud serves as a fully-managed, serverless cloud backend for Prometheus, offering integrated support for remote read/write protocols and PromQL as one of our primary query languages.

Recently, while working on our GreptimeDB project, we encountered an issue with calling asynchronous Rust code in a synchronous context.

To explore data stored in GreptimeDB through PromQL, GreptimeDB needs to provide the ability to parse the query into AST (abstract syntax tree), and retrieve data from memory or disk via logical and physical plans. Since there is no ready-to-use PromQL Rust Parser, our team decides to develop it by ourselves. We’re glad to announce that promql-parser v0.1.0 is now available.

This is truly a fantastic combination -- implement the logic in Rust and use it in Python. GreptimeDB also implements a similar functionality that allows writing Python script to do post-process of SQL query results, with the help of RustPython and Arrow. Maybe this combination can bring a sweet point between performance and efficiency.

docs: https://docs.greptime.com/user-guide/coprocessor-and-scripti...

code: https://github.com/GreptimeTeam/greptimedb/tree/develop/src/...

a few times, seems interesting. The author's also built a lot of other cool concurrency primitives for Rust as well.

[0] https://github.com/spacejam/sled

- Dropbox [3] uses a similar approach but they talk about it a bit more abstractly.

Sans-IO is more documented in Python [4], but str0m [5] and quinn-proto [6] are the best examples in Rust I’m aware of. Note that sans-IO is orthogonal to deterministic test frameworks, but it composes well with them.

With the disclaimer that my opinions are mine and mine alone, and don’t reflect the company I work at —— I do work at a rust shop that has utilized these techniques on some projects.

TigerBeetle is an amazing example and I’ve looked at it before! They are really the best example of this approach outside of FoundationDB I think.

[0]: https://risingwave.com/blog/deterministic-simulation-a-new-e...

[1]: https://risingwave.com/blog/applying-deterministic-simulatio...

[2]: https://dropbox.tech/infrastructure/-testing-our-new-sync-en...

[3]: https://github.com/spacejam/sled

[4]: https://fractalideas.com/blog/sans-io-when-rubber-meets-road...

[5]: https://github.com/algesten/str0m

[6]: https://docs.rs/quinn-proto/0.10.6/quinn_proto/struct.Connec...

Sled uses bw-tree actually https://github.com/spacejam/sled/wiki/sled-architectural-outlook

There is a valid argument to be made for threads over async in a large percentage of use cases where async is considered the default. If this is what you are referring to however, I don't think they ever referred to async as completely useless: https://github.com/spacejam/sled/issues/1123.

Have you looked into other pure-Rust databases as well, such as sled or GlueSQL which has an SQL interface on top of sled? I wonder how those would compare to Persy.

I'm not sure what you need. Are these of any use? https://github.com/meilisearch/heed https://github.com/spacejam/sled

There is also Sled but as I understand it that is being reworked to use the author's new DB core Marble

There are some databases like sled/FlashDB designed to be embedded to other applications even bare metal microcontrollers. But I do doubt the potential bussiness value of a pure embedded database.

https://github.com/spacejam/sled

To add transaction support, you probably need a good understanding of how the memtable works in Log Structured Merge trees: