roaring-rs VS atomic-server

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.

Reading through https://atomicdata.dev/ seemed like a good option for notes/cms with collaboration.

Great read, wholeheartedly agree with your sentiments! We need to combine the vision of a web of linked data with the practicality of JSON. I think you’ll like Atomic Data, a project that I’ve been working on for almost three years now. It’s a modular specification that takes a strict subset of RDF to make it highly compatible with json. I’ve also written quite a bit of docs and some implementations, such as a server (written in rust) and a data browser (similar to notion), as well as a bunch of libraries.

I use sled in Atomic Server. Here's the actual sled usage.

Working on Atomic-Server, a graph database / CMS for sharing structured data and schemas. Currently, I’m working on a CRDT implementation - trying to have conflict-free event-sourced version control system. Kind of harder than I thought!

So for the past few years, I've been working on a new open specification, called Atomic Data. It takes inspiration from the semantic web, but is far more practical in its design and easier to use. Instead of only writing a spec, I also wrote a server / database, a client (browser GUI), and various libraries - all open source.

I've made a Database with a GUI, and Tauri helped me to make the desktop build. It's really promising project. It's very flexible in how you use it - I'm currently using its async runtime to run my Rust Actix server, and using the WebView to render a React app. Being able to easily create a desktop tray icon with actions is pretty cool. I'm really looking forward to Android + iOS support.

I'm currently writing an open source database + server that helps with this process (it creates subject pages, gives you a Gui, serializes to RDF and other formats), called atomic-server. I think using this is currently the fastest way to get linked data deployed to the semantic web!

I'll just take this opportunity to promote an open source, decentralised database that I've been working on, called Atomic-Server. It's fast (written in rust), features built in full text search, authorisation, dynamic forms, and it runs on low end hardware. It features a new specification called Atomic Data that combines the best of json, rdf and type safety.

I'm working on adding authentication to atomic-server, an open source graph database with dynamic, decentralized schema validation.