bonsaidb VS roaring-rs

What about https://github.com/khonsulabs/bonsaidb? Progress seems stall since last summer but very cool project

There is Nebari which is the KV part of BonsaiDB I've used both successfully (and that is currently in production)

In BonsaiDb, I define entire test suites as macros. This crate has a common trait that has multiple implementations in different crates. Each implementation needs to be tested thoroughly. For cargo test to be able to work in each crate independently, I needed to have the #[test]-annotated functions in the crate being built. By using a macro, I can define the functions in one location and invoke the macro in each crate to import the test suite into that crate.

I'm finishing up a large refactor of BonsaiDb which will add support for using BonsaiDb in non-async code.

I'm working on a major refactoring of BonsaiDb, aiming to improve the design of several interrelated features. While it started by aiming to enable a non-async interface for BonsaiDb, I realized mid-refactor that another major refactor would be better to do simultaneously rather than separately. Thank goodness that refactoring in Rust is such a wonderful experience!

For collections, we haven't addressed migrations yet. It's one of the higher priority things on my mind, however, so it probably will be in the next release.

It depends on what you mean by "support graphs". If you mean support the abillity to build a GraphQL interface in front of it, yes that is already possible in a limited fashion, although there are no first-class relationship types yet.

Replication is not implemented yet.

The README has a link to the code coverage report. There is a common test suite that is run across all mechanisms that database access is offered, and there are additional crate-specific tests as needed.

I'm trying to release the first alpha of BonsaiDb. I'm wrapping up replacing OPAQUE with Argon2, in an effort to make upgrading less likely to cause issues in the future (given that OPAQUE is still a draft protocol). I still love OPAQUE and will bring it back in the future.

There are issues and pull requests but I advise you to look at the milli folder in the Meilisearch repository, it’s where all the logic is done. We extensively use RoaringBitmaps, heed the LMDB wrapper and grenad when indexing.

I am sure that /u/saik0 can answer with a thorough response here but in the broad lines, we introduced raw simd calls by using the core::simd module. That discussion can be seen in one of our issues about introducing SIMD in this crate.

On some benchmarks, we are faster but most of the time we aren't. We absolutely need to introduce benchmarks with the croaring-rs library and most of those performances gain could also be achieved with other methods to do multi-ops for example.

Sorry, should have searched first. See https://github.com/RoaringBitmap/roaring-rs/issues/204

We tried to release the new version of roaring-rs, better compressed bitset in Rust, but found out that the core library simd module was blocking us. We now have to work on std::simd to release the blocking features.

Yeah, it can be attributed to using the roaring-rs library, but not just that, we have done so much to improve the search performances by reducing the number of set-operations we do.

Given the shoutouts to Burntsushi and Lemire this is almost certainly a bitmap trigram index based engine similar to https://github.com/google/zoekt

The index is likely based on Roaring bitmaps, presumably https://github.com/RoaringBitmap/roaring-rs in this case.

Nice architecture, exactly how I would have done it also.

I have worked on roaring-rs, a very fast library to do set operations like unions and intersections, and improved the four operations by using the standard ops traits.

I have implemented a better way of specifying ranges to be inserted or removed from a RoaringBitmap by using the RangeBounds trait. The roaring-rs library exposes fast data-structures to do set operations, like intersections and unions.