Go to file
bors[bot] 834504aec0
Merge #204
204: Decorrelate Distinct, Asc/Desc, Filterable fields from the faceted fields r=Kerollmops a=Kerollmops

This PR decorrelates the fields that need to be stored in facet databases (big inverted indexes for fast access) from the filterable fields, the previously named faceted fields are now named filterable fields and are the union of the distinct attribute, all the Asc/Desc criteria and, the filterable fields.

I added two tests to make sure that the engine was correctly generating the faceted databases when a distinct attribute or an Asc/Desc criteria were added, and one to make sure that it was impossible to filter on a non-filterable field even if it was a faceted one.

Note that the `AttributesForFacetting` has also been renamed into `FilterableAttributes`. But it will be the Transplant's job to do that on the API, this change is only visible to the milli's library users.

- Related to https://github.com/meilisearch/transplant/issues/187.
- Fixes #161 by returning the documents that don't have the Asc/Desc field at the end of the bucket.
- Fixes #168.
- Fixes #152.

Co-authored-by: Kerollmops <clement@meilisearch.com>
Co-authored-by: Marin Postma <postma.marin@protonmail.com>
Co-authored-by: many <maxime@meilisearch.com>
2021-06-02 15:43:39 +00:00
.github Update following reviews 2021-06-02 11:13:22 +02:00
benchmarks remove the nop function 2021-06-02 17:09:21 +02:00
helpers Update version for the next release (v0.2.1) 2021-05-05 14:57:34 +02:00
http-ui Rename the FacetCondition into FilterCondition 2021-06-02 16:24:58 +02:00
infos Fix PR comments 2021-06-01 18:06:46 +02:00
milli Merge #204 2021-06-02 15:43:39 +00:00
search Update version for the next release (v0.2.1) 2021-05-05 14:57:34 +02:00
.gitignore Change the project to become a workspace with milli as a default-member 2021-02-12 16:15:09 +01:00
bors.toml Add bors 2021-05-03 12:29:30 +02:00
Cargo.lock add a way to provide primary_key or autogenerate documents ids 2021-06-02 11:13:20 +02:00
Cargo.toml move the benchmarks to another crate so we can download the datasets automatically without adding overhead to the build of milli 2021-06-02 11:11:50 +02:00
LICENSE Update LICENSE 2021-03-15 16:15:14 +01:00
qc_loop.sh Initial commit 2020-05-31 14:22:06 +02:00
README.md do not use echo that espaces newline 2021-04-29 09:25:35 +02:00

the milli logo

a concurrent indexer combined with fast and relevant search algorithms

Introduction

This engine is a prototype, do not use it in production. This is one of the most advanced search engine I have worked on. It currently only supports the proximity criterion.

Compile and Run the server

You can specify the number of threads to use to index documents and many other settings too.

cd http-ui
cargo run --release -- --db my-database.mdb -vvv --indexing-jobs 8

Index your documents

It can index a massive amount of documents in not much time, I already achieved to index:

  • 115m songs (song and artist name) in ~1h and take 107GB on disk.
  • 12m cities (name, timezone and country ID) in 15min and take 10GB on disk.

All of that on a 39$/month machine with 4cores.

You can feed the engine with your CSV (comma-seperated, yes) data like this:

printf "name,age\nhello,32\nkiki,24\n" | http POST 127.0.0.1:9700/documents content-type:text/csv

Here ids will be automatically generated as UUID v4 if they doesn't exist in some or every documents.

Note that it also support JSON and JSON streaming, you can send them to the engine by using the content-type:application/json and content-type:application/x-ndjson headers respectively.

Querying the engine via the website

You can query the engine by going to the HTML page itself.