mirror of
https://github.com/meilisearch/meilisearch.git
synced 2024-11-22 18:17:39 +08:00
A lightning-fast search API that fits effortlessly into your apps, websites, and workflow
app-searchdatabaseenterprise-searchfacetingfull-text-searchfuzzy-searchgeosearchhybrid-searchinstantsearchrestrustsearchsearch-as-you-typesearch-enginesemantic-searchsite-searchsynonymstypo-tolerancevector-databasevectors
8bc7dd8b03
143: Shared update store r=irevoire a=MarinPostma This PR changes the updates process so that only one instance of an update store is shared among indexes. This allows updates to always be processed sequentially without additional synchronization, and fixes the bug where all the first pending update for each index were reported as processing whereas only one was. EDIT: I ended having to rewrite the whole `UpdateStore` to allow updates being really queued and processed sequentially in the ordered they were added. For that purpose I created a `pending_queue` that orders the updates by a global update id. To find the next `update_id` to use, both globally and for each index, I have created another database that contains the next id to use. Finally, all updates that have been processed (with success or otherwise) are all stores in an `updates` database. The layout for the keys of these databases are such that it is easy to iterate over the elements for a particular index, and greatly reduces the amount of code to do so, compared to the former implementation. I have also simplified the locking mechanism for the update store, thanks to the StateLock data structure, that allow both an arbitrary number of readers and a single writer to concurrently access the state. The current state can be either Idle, Processing, or Snapshotting. When an update or snapshotting is ongoing, the process holds the state lock until it is done processing its task. When it is done, it sets bask the state to Idle. I have made other small improvements here and there, and have let some other for work, such as: - When creating an update file to hold a request's content, it would be preferable to first create a temporary file, and then atomically persist it when we have written to it. This would simplify the case when there is no data to be written to the file, since we wouldn't have to take care about cleaning after ourselves. - The logic for content validation must be factored. - Some more tests related to error handling in the process_pending_update function. - The issue #159 close #114 Co-authored-by: Marin Postma <postma.marin@protonmail.com> |
||
|---|---|---|
| .github | ||
| meilisearch-error | ||
| meilisearch-http | ||
| .dockerignore | ||
| .gitignore | ||
| bors.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| Dockerfile | ||
| LICENSE | ||
| README.md | ||
Transplant
Transplant makes communication between the users and Milli using HTTP. The final purpose of Transplant is to be merged into the current MeiliSearch repository so that users will enjoy the new search engine performance provided by Milli.
Run the alpha releases
Currently only alpha versions are available.
You can:
- Run it with Docker, for instance:
docker run -p 7700:7700 getmeili/meilisearch:v0.21.0-alpha.4 ./meilisearch
-
With the available release assets.
-
Compile from the source code:
cargo run --release
Run the tests
cargo test
If you encounter any Too many open files error when running the tests, please upgrade the maximum number of open file descriptors with this command:
ulimit -Sn 3000