Multi-search
As the name suggests, the multi-search operation lets you bundle multiple search requests into a single request. OpenSearch then executes the searches in parallel, so you get back the response more quickly compared to sending one request per search. OpenSearch executes each search independently, so the failure of one doesn’t affect the others.
copy
Path and HTTP methods
- Metadata lines include options, such as which indices to search and the type of search.
- Query lines use the .
Just like the bulk operation, the JSON doesn’t need to be minified—spaces are fine—but it does need to be on a single line. OpenSearch uses newline characters to parse multi-search requests and requires that the request body end with a newline character.
URL parameters and metadata options
All multi-search URL parameters are optional. Some can also be applied per-search as part of each metadata line.
Option | Type | Description |
---|---|---|
index | String, string array | If you don’t specify an index or multiple indices as part of the URL (or want to override the URL value for an individual search), you can include it here. Examples include “logs-*” and . |
preference | String | The nodes or shards that you’d like to perform the search. This setting can be useful for testing, but in most situations, the default behavior provides the best search latencies. Options include _local , _only_local , _prefer_nodes , _only_nodes , and _shards . These last three options accept a list of nodes or shards. Examples include “_only_nodes:data-node1,data-node2” and “_shards:0,1 . |
request_cache | Boolean | Whether to cache results, which can improve latency for repeat searches. Default is to use the index.requests.cache.enable setting for the index (which defaults to true for new indices). |
routing | String | Comma-separated custom routing values (e.g. . |
Response
OpenSearch returns an array with the results of each search in the same order as the multi-search request.