WARNING: The 1.x versions of Elasticsearch have passed their EOL dates. If you are running a 1.x version, we strongly advise you to upgrade.
This documentation is no longer maintained and may be removed. For the latest information, see the current Elasticsearch documentation.
Search Optionsedit
A few optional query-string parameters can influence the search process.
preferenceedit
The preference
parameter allows you to control which shards or nodes are
used to handle the search request. It accepts values such as _primary
,
_primary_first
, _local
, _only_node:xyz
, _prefer_node:xyz
, and
_shards:2,3
, which are explained in detail on the
search preference
documentation page.
However, the most generally useful value is some arbitrary string, to avoid the bouncing results problem.
timeoutedit
By default, the coordinating node waits to receive a response from all shards. If one node is having trouble, it could slow down the response to all search requests.
The timeout
parameter tells the coordinating node how long it should wait
before giving up and just returning the results that it already has. It can be
better to return some results than none at all.
The response to a search request will indicate whether the search timed out and how many shards responded successfully:
If all copies of a shard fail for other reasons—perhaps because of a
hardware failure—this will also be reflected in the _shards
section of
the response.
routingedit
In Routing a Document to a Shard, we explained how a custom routing
parameter could be
provided at index time to ensure that all related documents, such as the
documents belonging to a single user, are stored on a single shard. At search
time, instead of searching on all the shards of an index, you can specify
one or more routing
values to limit the search to just those shards:
GET /_search?routing=user_1,user2
This technique comes in handy when designing very large search systems, and we discuss it in detail in Designing for Scale.
search_typeedit
While query_then_fetch
is the default search type, other search types can
be specified for particular purposes, for example:
GET /_search?search_type=count
-
count
-
The
count
search type has only aquery
phase. It can be used when you don’t need search results, just a document count or aggregations on documents matching the query. -
query_and_fetch
-
The
query_and_fetch
search type combines the query and fetch phases into a single step. This is an internal optimization that is used when a search request targets a single shard only, such as when arouting
value has been specified. While you can choose to use this search type manually, it is almost never useful to do so. -
dfs_query_then_fetch
anddfs_query_and_fetch
-
The
dfs
search types have a prequery phase that fetches the term frequencies from all involved shards in order to calculate global term frequencies. We discuss this further in Relevance Is Broken!. -
scan
-
The
scan
search type is used in conjunction with thescroll
API to retrieve large numbers of results efficiently. It does this by disabling sorting. We discuss scan-and-scroll in the next section.