snowykami/meilisearch
1
0
Fork 0
mirror of https://github.com/meilisearch/meilisearch.git synced 2024-11-23 10:37:41 +08:00
Code Issues Actions 8 Packages Projects Releases Wiki Activity
A lightning-fast search API that fits effortlessly into your apps, websites, and workflow
666 Commits 165 Branches 386 Tags 80 MiB
Rust 99.9%
da036dcc3e
Go to file
tamo da036dcc3e
Revert "Integrate the stop_words in the querytree" 
This reverts commit 12fb509d84.
We revert this commit because it's causing the bug #150.
The initial algorithm we implemented for the stop_words was:

1. remove the stop_words from the dataset
2. keep the stop_words in the query to see if we can generate new words by
   integrating typos or if the word was a prefix
=> This was causing the bug since, in the case of “The hobbit”, we were
   **always** looking for something starting with “t he” or “th e”
   instead of ignoring the word completely.

For now we are going to fix the bug by completely ignoring the
stop_words in the query.
This could cause another problem were someone mistyped a normal word and
ended up typing a stop_word.

For example imagine someone searching for the music “Won't he do it”.
If that person misplace one space and write “Won' the do it” then we
will loose a part of the request.

One fix would be to update our query tree to something like that:

---------------------
OR
  OR
    TOLERANT hobbit # the first option is to ignore the stop_word
    AND
      CONSECUTIVE   # the second option is to do as we are doing
        EXACT t	    # currently
        EXACT he
      TOLERANT hobbit
---------------------

This would increase drastically the size of our query tree on request
with a lot of stop_words. For example think of “The Lord Of The Rings”.

For now whatsoever we decided we were going to ignore this problem and consider
that it doesn't reduce too much the relevancy of the search to do that
while it improves the performances.
2021-04-12 18:35:33 +02:00
.github Add release drafter files 2021-04-12 10:18:39 +02:00
helpers Introduce an helpers crate that export the database to stdout 2021-03-01 19:55:04 +01:00
http-ui test(http): combine settings assert_(ser|de)_tokens into 1 test 2021-04-10 12:13:59 +03:00
infos Simplify the output of database sizes in the infos crate 2021-03-08 18:47:33 +01:00
milli Revert "Integrate the stop_words in the querytree" 2021-04-12 18:35:33 +02:00
search Fix error displaying of the workspace members 2021-03-01 19:48:01 +01:00
.gitignore Change the project to become a workspace with milli as a default-member 2021-02-12 16:15:09 +01:00
Cargo.lock test(http): combine settings assert_(ser|de)_tokens into 1 test 2021-04-10 12:13:59 +03:00
Cargo.toml Introduce an helpers crate that export the database to stdout 2021-03-01 19:55:04 +01: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 Fix the REAMD.md bash example 2021-03-08 18:56:22 +01:00

README.md

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 -- serve --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:

echo "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.