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 ann queries inside _msearch (basically, 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 ann queries inside _msearch, so users can send multiple ann searches across different indices in a single batch request, similar to how _msearch works for traditional queries.
This feature should allow:
Executing multiple ann 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 ann is not currently supported in _msearch, the following workarounds have been explored:
Sending separate ANN _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 ann for vector similarity.
✅ Works in _msearch, but significantly slower than ann (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 ann 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:
genandre
changed the title
[FEATURE] Support knn Queries in _msearch for Multi-Collection Vector Search
[FEATURE] Support ANN Queries in _msearch for Multi-Collection Vector Search
Mar 3, 2025
Is your feature request related to a problem?
Currently, OpenSearch does not support
ann
queries inside_msearch
(basically, 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
ann
queries inside_msearch
, so users can send multipleann
searches across different indices in a single batch request, similar to how_msearch
works for traditional queries.This feature should allow:
ann
searches in one request (just like_msearch
does formatch
,term
, andscript_score
queries).What alternatives have you considered?
Since
ann
is not currently supported in_msearch
, the following workarounds have been explored:Sending separate ANN
_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 ofann
for vector similarity._msearch
, but significantly slower thanann
(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?
ann
in_msearch
, and OpenSearch could introduce this as a unique advantage.The text was updated successfully, but these errors were encountered: