You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, OpenSearch does not support knn queries inside _msearch, which prevents performing approximate nearest neighbor (ANN) search across multiple indices in a single request.
This limitation makes it difficult to efficiently retrieve vector search results from multiple collections, requiring multiple separate queries instead. This increases query complexity, latency, and response merging overhead in applications that need multi-collection vector search.
What solution would you like?
I would like OpenSearch to support knn queries inside _msearch, so users can send multiple knn searches across different indices in a single batch request, similar to how _msearch works for traditional queries.
This feature should allow:
Executing multiple knn searches in one request (just like _msearch does for match, term, and script_score queries).
Efficiently retrieving results from multiple indices without requiring separate requests.
Merging results from multiple indices with minimal performance overhead.
What alternatives have you considered?
Since knn is not currently supported in _msearch, the following workarounds have been explored:
Sending separate KNN _search queries per index and merging results client-side.
🚀 Fast, but requires extra logic in the application to merge responses manually.
❌ Increases request overhead due to multiple network calls.
Reindexing all collections into a single index and filtering with a type field.
✅ Works well for some cases, but does not scale well if collections are large and frequently updated.
❌ Requires additional storage and maintenance overhead.
Using _msearch with script_score instead of knn for vector similarity.
✅ Works in _msearch, but significantly slower than knn (brute-force computation instead of ANN indexing).
None of these alternatives fully solve the problem in an efficient and scalable way.
Do you have any additional context?
Elasticsearch also does not support knn in _msearch, and OpenSearch could introduce this as a unique advantage.
The ability to batch vector searches would be highly beneficial for multi-collection vector search use cases, such as:
Searching across multiple document repositories in a single request.
Performing multi-modal search (e.g., combining text, image, or embeddings from different sources).
Improving efficiency in real-time recommendation systems that rely on fast ANN lookups.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
Currently, OpenSearch does not support
knn
queries inside_msearch
, which prevents performing approximate nearest neighbor (ANN) search across multiple indices in a single request.This limitation makes it difficult to efficiently retrieve vector search results from multiple collections, requiring multiple separate queries instead. This increases query complexity, latency, and response merging overhead in applications that need multi-collection vector search.
What solution would you like?
I would like OpenSearch to support
knn
queries inside_msearch
, so users can send multipleknn
searches across different indices in a single batch request, similar to how_msearch
works for traditional queries.This feature should allow:
knn
searches in one request (just like_msearch
does formatch
,term
, andscript_score
queries).What alternatives have you considered?
Since
knn
is not currently supported in_msearch
, the following workarounds have been explored:Sending separate KNN
_search
queries per index and merging results client-side.Reindexing all collections into a single index and filtering with a
type
field.Using
_msearch
withscript_score
instead ofknn
for vector similarity._msearch
, but significantly slower thanknn
(brute-force computation instead of ANN indexing).None of these alternatives fully solve the problem in an efficient and scalable way.
Do you have any additional context?
knn
in_msearch
, and OpenSearch could introduce this as a unique advantage.The text was updated successfully, but these errors were encountered: