milli VS roaring-rs

Is this a posting list? There is a lot of bioinformatics in this post, but if I squint, some of the problems do look like general information retrieval problems. Even the discussion of ordering the arrays by mass sounds like search relevance scores and makes me wonder if it makes sense to try to get something off the shelf like meillisearch/milli or tantavy to support this use case.

I'm currently not using any tool, although I am playing around with binding Milli and the most up-to-date Mentat fork to emacs with emacs-module-rs.

Yeah, we have already done that, the internal engine is called milli and could even be published on crates.io one day! The issue is with the design of the storage system itself, we use LMDB right now but maybe we can find another way to index faster and to be more oriented to distributed systems.

They have another prototype engine with more advanced features and performance too.

https://github.com/meilisearch/milli

You can look at the milli repository this is the library that we use and work on. MeiliSearch is the HTTP actix-web based server that serves the milli indices.

This library is the main bottleneck of the new MeiliSearch search engine. We will soon release a beta version, keep watching!

Working on the new MeiliSearch engine, reworked from scratch! There already is excellent external contributions 🎉

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.

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.

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.