bce35092ed
* Use resize rather than while-push loop
* Add deleted flags to simple vector storage
* Add deleted flag to memmap vector storage
* Map BitSlice on mmap file for deleted flags
* Use vector specific deletion BitSlice in RawScorer
* Use BitSlice for deleted points, fix check point logic, clarify names
* Extract div_ceil function to shared module
* We can use unchecked set and replace because we just checked the length
* Add deleted count function to vector storage
* Add vector storage point deletion tests
* Keep deleted state in simple vector storage with update_from, add test
* Keep deleted state in memmap vector storage with update_from, add test
* Simplify div_ceil
* Improve deletion handling in update_from in mmap vector storage
* Improve performance, use trickery to get BitSlice view over deleted mmap
* Use BitSlice where possible, construct BitVec more efficiently
* Incorporate vector specific delete flags in quantized raw scorer
* Don't pin MmapMut, it is not required
* With quantization, keep mmap deleted flags in RAM for better performance
* Advice the kernel to prepare deleted flags mmap for faster future access
* Simplify deleted bitslice access, add bound check, remove unused function
* Fix compilation on Windows
* Cleanup
* Rename delete functions to delete_{point,vec} to prevent confusion
* Use then_some rather than match a boolean
* Lock deleted flags in memory only when quantization is available
* Add docs and stabilize issue link to dev_ceil
* Flush deleted mmap when closing segment
This requires us to to wrap the memory map struct in an Arc and Mutex.
Though this may look inefficient, it doesn't have a negative side effect
on deleted flag performance, because the flags are accessed through a
BitSlice that is separate and doesn't use locking.
* Rename some point functions to vec because that makes more sense
* Simplify delete flag fetching option, use deref func instead of asterisk
* Do not calculate slice size manually, use size_of_val
* remove test raw scorer
* use deref in check
---------
Co-authored-by: Andrey Vasnetsov <andrey@vasnetsov.com>
Vector Search Engine for the next generation of AI applications
Qdrant (read: quadrant ) is a vector similarity search engine and vector database. It provides a production-ready service with a convenient API to store, search, and manage points - vectors with an additional payload. Qdrant is tailored to extended filtering support. It makes it useful for all sorts of neural-network or semantic-based matching, faceted search, and other applications.
Qdrant is written in Rust 🦀, which makes it fast and reliable even under high load.
With Qdrant, embeddings or neural network encoders can be turned into full-fledged applications for matching, searching, recommending, and much more!
Also available as managed solution in the Qdrant Cloud https://cloud.qdrant.io/ ⛅
Demo Projects
Semantic Text Search 🔍
The neural search uses semantic embeddings instead of keywords and works best with short texts. With Qdrant and a pre-trained neural network, you can build and deploy semantic neural search on your data in minutes. Try it online!
Similar Image Search - Food Discovery 🍕
There are multiple ways to discover things, text search is not the only one. In the case of food, people rely more on appearance than description and ingredients. So why not let people choose their next lunch by its appearance, even if they don’t know the name of the dish? Check it out!
Extreme classification - E-commerce Product Categorization 📺
Extreme classification is a rapidly growing research area within machine learning focusing on multi-class and multi-label problems involving an extremely large number of labels. Sometimes it is millions and tens of millions of classes. The most promising way to solve this problem is to use similarity learning models. We put together a demo example of how you could approach the problem with a pre-trained transformer model and Qdrant. So you can play with it online!
More solutions
|
|
|
| Semantic Text Search | Similar Image Search | Recommendations |
|
|
|
| Chat Bots | Matching Engines | Anomaly Detection |
API
REST
Online OpenAPI 3.0 documentation is available here. OpenAPI makes it easy to generate a client for virtually any framework or programming language.
You can also download raw OpenAPI definitions.
gRPC
For faster production-tier searches, Qdrant also provides a gRPC interface. You can find gRPC documentation here.
Clients
Qdrant offers the following client libraries to help you integrate it into your application stack with ease:
Features
Filtering and Payload
Qdrant supports any JSON payload associated with vectors. It does not only store payload but also allows filter results based on payload values.
It allows any combinations of should, must, and must_not conditions, but unlike ElasticSearch post-filtering, Qdrant guarantees all relevant vectors are retrieved.
Rich Data Types
Vector payload supports a large variety of data types and query conditions, including string matching, numerical ranges, geo-locations, and more. Payload filtering conditions allow you to build almost any custom business logic that should work on top of similarity matching.
Query Planning and Payload Indexes
Using the information about the stored payload values, the query planner decides on the best way to execute the query.
For example, if the search space limited by filters is small, it is more efficient to use a full brute force than an index.
SIMD Hardware Acceleration
Qdrant can take advantage of modern CPU x86-x64 architectures. It allows you to search even faster on modern hardware.
Write-Ahead Logging
Once the service confirmed an update - it won't lose data even in case of power shut down. All operations are stored in the update journal and the latest database state could be easily reconstructed at any moment.
Distributed Deployment
Since v0.8.0 Qdrant supports distributed deployment. In this mode, multiple Qdrant machines are joined into a cluster to provide horizontal scaling. Coordination with the distributed consensus is provided by the Raft protocol.
Stand-alone
Qdrant does not rely on any external database or orchestration controller, which makes it very easy to configure.
Usage
Docker 🐳
Build your own from source
docker build . --tag=qdrant/qdrant
Or use latest pre-built image from DockerHub
docker pull qdrant/qdrant
To run the container, use the command:
docker run -p 6333:6333 qdrant/qdrant
And once you need a fine-grained setup, you can also define a storage path and custom configuration:
docker run -p 6333:6333 \
-v $(pwd)/path/to/data:/qdrant/storage \
-v $(pwd)/path/to/custom_config.yaml:/qdrant/config/production.yaml \
qdrant/qdrant
/qdrant/storage- is a place where Qdrant persists all your data. Make sure to mount it as a volume, otherwise docker will drop it with the container./qdrant/config/production.yaml- is the file with engine configuration. You can override any value from the reference config
Now Qdrant should be accessible at localhost:6333.
Docs 📓
- The best place to start is Quick Start Guide
- The Documentation
- Use the OpenAPI specification as a reference
- Follow our Step-by-Step Tutorial to create your first neural network project with Qdrant
- Assess Qdrant's performance in our benchmarks
- Check out our further plans in v1.0 Roadmap
Contacts
- Join our Discord channel
- Follow us on Twitter
- Subscribe to our Newsletters
- Write us an email info@qdrant.tech
Building something special with Qdrant? We can help!
Contributors ✨
Thanks to the people who contributed to Qdrant:
License
Qdrant is licensed under the Apache License, Version 2.0. View a copy of the License file.