WARNING: Version 6.1 of Elasticsearch has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
The search API allows you to execute a search query and get back search hits that match the query. The query can either be provided using a simple query string as a parameter, or using a request body.
All search APIs can be applied across multiple types within an index, and across multiple indices with support for the multi index syntax. For example, we can search on all documents across all types within the twitter index:
We can also search within specific types:
We can also search all tweets with a certain tag across several indices (for example, when each user has his own index):
Or we can search all tweets across all available indices using
Or even search across all indices and all types:
By default Elasticsearch doesn’t reject any search requests based on the number
of shards the request hits. While Elasticsearch will optimize the search execution
on the coordinating node a large number of shards can have a significant impact
CPU and memory wise. It is usually a better idea to organize data in such a way
that there are fewer larger shards. In case you would like to configure a soft
limit, you can update the
action.search.shard_count.limit cluster setting in order
to reject search requests that hit too many shards.
max_concurrent_shard_requests request parameter can be used to control
the maximum number of concurrent shard requests the search API will execute for this request.
This parameter should be used to protect a singe request from overloading a cluster ie. a default
request will hit all indices in a cluster which could cause shard request rejections if the
number of shards per node is high. This default is based on the number of data nodes in
the cluster but at most