NOTE: You are looking at documentation for an older release. For the latest information, see the current release documentation.
Request Body Search
editRequest Body Search
editThe search request can be executed with a search DSL, which includes the Query DSL, within its body. Here is an example:
GET /twitter/_search { "query" : { "term" : { "user" : "kimchy" } } }
And here is a sample response:
{ "took": 1, "timed_out": false, "_shards":{ "total" : 1, "successful" : 1, "skipped" : 0, "failed" : 0 }, "hits":{ "total" : 1, "max_score": 1.3862944, "hits" : [ { "_index" : "twitter", "_type" : "_doc", "_id" : "0", "_score": 1.3862944, "_source" : { "user" : "kimchy", "message": "trying out Elasticsearch", "date" : "2009-11-15T14:12:12", "likes" : 0 } } ] } }
Parameters
edit
|
A search timeout, bounding the search request to be executed within the specified time value and bail with the hits accumulated up to that point when expired. Search requests are canceled after the timeout is reached using the Search Cancellation mechanism. Defaults to no timeout. See Time units. |
|
To retrieve hits from a certain offset. Defaults to |
|
The number of hits to return. Defaults to |
|
The type of the search operation to perform. Can be
|
|
Set to |
|
Set to |
|
The maximum number of documents to collect for each shard,
upon reaching which the query execution will terminate early. If set, the
response will have a boolean field |
|
The number of shard results that should be reduced at once on the coordinating node. This value should be used as a protection mechanism to reduce the memory overhead per search request if the potential number of shards in the request can be large. |
Out of the above, the search_type
, request_cache
and the allow_partial_search_results
settings must be passed as query-string parameters. The rest of the search request should
be passed within the body itself. The body content can also be passed as a REST
parameter named source
.
Both HTTP GET and HTTP POST can be used to execute search with body. Since not all clients support GET with body, POST is allowed as well.
Fast check for any matching docs
editterminate_after
is always applied after the post_filter
and stops
the query as well as the aggregation executions when enough hits have been
collected on the shard. Though the doc count on aggregations may not reflect
the hits.total
in the response since aggregations are applied before the
post filtering.
In case we only want to know if there are any documents matching a
specific query, we can set the size
to 0
to indicate that we are not
interested in the search results. Also we can set terminate_after
to 1
to indicate that the query execution can be terminated whenever the first
matching document was found (per shard).
GET /_search?q=message:number&size=0&terminate_after=1
The response will not contain any hits as the size
was set to 0
. The
hits.total
will be either equal to 0
, indicating that there were no
matching documents, or greater than 0
meaning that there were at least
as many documents matching the query when it was early terminated.
Also if the query was terminated early, the terminated_early
flag will
be set to true
in the response.
{ "took": 3, "timed_out": false, "terminated_early": true, "_shards": { "total": 1, "successful": 1, "skipped" : 0, "failed": 0 }, "hits": { "total": 1, "max_score": 0.0, "hits": [] } }
The took
time in the response contains the milliseconds that this request
took for processing, beginning quickly after the node received the query, up
until all search related work is done and before the above JSON is returned
to the client. This means it includes the time spent waiting in thread pools,
executing a distributed search across the whole cluster and gathering all the
results.