Go to file
bors[bot] 51cf44d6fd
Merge #456
456: Remove useless grenad merging r=Kerollmops a=Kerollmops

This PR must be merged after #454.

This PR removes the part of code that was merging all of the grenad Readers merging that we don't need as the indexer should have merged them and, therefore, we should only have one final grenad Reader. We reduce the amount of CPU usage and memory pressure we were doing uselessly.

`@ManyTheFish` are you sure I can skip merging the `word_docids` database?

Here is the benchmark comparison with the previously merged PR #454:
```
group                                              indexing_reintroduce-appending-sorted-values_c05e42a8    indexing_remove-useless-grenad-merging_d5b8b5a2
-----                                              -----------------------------------------------------    -----------------------------------------------
indexing/Indexing movies with default settings     1.06      16.6±1.04s        ? ?/sec                      1.00      15.7±0.93s        ? ?/sec
indexing/Indexing songs with default settings      1.16      60.1±7.07s        ? ?/sec                      1.00      51.7±5.98s        ? ?/sec
indexing/Indexing songs without faceted numbers    1.06      55.4±6.14s        ? ?/sec                      1.00      52.2±4.13s        ? ?/sec
```

And the comparison with multi-batch indexing before #436, we can see that we gain time for benchmarks that index datasets in multiple batches but there is _so much_ variance that it's not clear.

```
group                                                             indexing_benchmark-multi-batch-indexing-before-speed-up_45f52620    indexing_remove-useless-grenad-merging_d5b8b5a2
-----                                                             ----------------------------------------------------------------    -----------------------------------------------
indexing/Indexing geo_point                                       1.07       6.6±0.08s        ? ?/sec                                 1.00       6.2±0.11s        ? ?/sec
indexing/Indexing songs in three batches with default settings    1.12      57.7±2.14s        ? ?/sec                                 1.00      51.5±3.80s        ? ?/sec
indexing/Indexing songs with default settings                     1.00      47.5±2.52s        ? ?/sec                                 1.09      51.7±5.98s        ? ?/sec
indexing/Indexing songs without any facets                        1.00      43.5±1.43s        ? ?/sec                                 1.12      48.8±3.73s        ? ?/sec
indexing/Indexing songs without faceted numbers                   1.00      47.1±2.23s        ? ?/sec                                 1.11      52.2±4.13s        ? ?/sec
indexing/Indexing wiki                                            1.00    917.3±30.01s        ? ?/sec                                 1.09    998.7±38.92s        ? ?/sec
indexing/Indexing wiki in three batches                           1.09   1091.2±32.73s        ? ?/sec                                 1.00    996.5±15.70s        ? ?/sec
```

What do you think `@irevoire?` Should we change the benchmarks to make them do more runs?

Co-authored-by: Kerollmops <clement@meilisearch.com>
2022-03-01 16:48:08 +00:00
.github Raise the GitHub CI timeout limit to 72h 2022-02-23 15:27:51 +01:00
benchmarks Apply GitHub suggestions 2022-02-23 16:20:29 +01:00
cli bump milli 2022-02-16 13:27:41 +01:00
filter-parser Replace MeiliSearch by Meilisearch 2022-01-26 17:49:55 +01:00
helpers bump milli 2022-02-16 13:27:41 +01:00
http-ui bump milli 2022-02-16 13:27:41 +01:00
infos bump milli 2022-02-16 13:27:41 +01:00
milli Replace the ugly unwraps by clean if let Somes 2022-02-28 16:31:33 +01:00
script format the whole project 2021-06-16 18:33:33 +02:00
.gitignore Change the project to become a workspace with milli as a default-member 2021-02-12 16:15:09 +01:00
.rustfmt.toml format the whole project 2021-06-16 18:33:33 +02:00
bors.toml update bors 2021-07-26 15:31:00 +02:00
Cargo.toml Rename the filter_parser crate into filter-parser 2021-11-09 16:41:10 +01:00
LICENSE Update LICENSE 2022-02-15 15:52:50 +01:00
README.md Replace meilisearch by Meilisearch 2022-01-26 17:48:22 +01:00

the milli logo

a concurrent indexer combined with fast and relevant search algorithms

Introduction

This repository contains the core engine used in Meilisearch.

It contains a library that can manage one and only one index. Meilisearch manages the multi-index itself. Milli is unable to store updates in a store: it is the job of something else above and this is why it is only able to process one update at a time.

This repository contains crates to quickly debug the engine:

  • There are benchmarks located in the benchmarks crate.
  • The http-ui crate is a simple HTTP dashboard to tests the features like for real!
  • The infos crate is used to dump the internal data-structure and ensure correctness.
  • The search crate is a simple command-line that helps run flamegraph on top of it.
  • The helpers crate is only used to modify the database inplace, sometimes.

Compile and run the HTTP debug 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 ~48min and take 81GiB on disk.
  • 12m cities (name, timezone and country ID) in ~4min and take 6GiB on disk.

These metrics are done on a MacBook Pro with the M1 processor.

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

printf "id,name,age\n1,hello,32\n2,kiki,24\n" | http POST 127.0.0.1:9700/documents content-type:text/csv

Don't forget to specify the id of the documents. Also, note that it supports 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.

Contributing

You can setup a git-hook to stop you from making a commit too fast. It'll stop you if:

  • Any of the workspaces does not build
  • Your code is not well-formatted

These two things are also checked in the CI, so ignoring the hook won't help you merge your code. But if you need to, you can still add --no-verify when creating your commit to ignore the hook.

To enable the hook, run the following command from the root of the project:

cp script/pre-commit .git/hooks/pre-commit