2658c5c545
fixes after review bump the version of the tokenizer implement a first version of the stop_words The front must provide a BTreeSet containing the stop words The stop_words are set at None if an empty Set is provided add the stop-words in the http-ui interface Use maplit in the test and remove all the useless drop(rtxn) at the end of all tests Integrate the stop_words in the querytree remove the stop_words from the querytree except if it was a prefix or a typo more fixes after review |
||
---|---|---|
.github/workflows | ||
helpers | ||
http-ui | ||
infos | ||
milli | ||
search | ||
.gitignore | ||
Cargo.lock | ||
Cargo.toml | ||
LICENSE | ||
qc_loop.sh | ||
README.md |
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.