Skip to content

Latest commit

 

History

History
107 lines (83 loc) · 4.49 KB

15_Search_options.asciidoc

File metadata and controls

107 lines (83 loc) · 4.49 KB
Raw

Search Options

A few optional query-string parameters can influence the search process.

preference

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 {ref}/search-request-preference.html[search preference] documentation page.

However, the most generally useful value is some arbitrary string, to avoid the bouncing results problem.

Bouncing Results

Imagine that you are sorting your results by a timestamp field, and two documents have the same timestamp. Because search requests are round-robined between all available shard copies, these two documents may be returned in one order when the request is served by the primary, and in another order when served by the replica.

This is known as the bouncing results problem: every time the user refreshes the page, the results appear in a different order. The problem can be avoided by always using the same shards for the same user, which can be done by setting the preference parameter to an arbitrary string like the user’s session ID.

timeout

By default, shards process all the data they have before returning a response to the coordinating node, which will in turn merge these responses to build the final response.

This means that the time it takes to run a search request is the sum of the time it takes to process the slowest shard and the time it takes to merge responses. If one node is having trouble, it could slow down the response to all search requests.

The timeout parameter tells shards how long they are allowed to process data before returning a response to the coordinating node. If there was not enough time to process all data, results for this shard will be partial, even possibly empty.

The response to a search request will indicate whether any shards returned a partial response with the timed_out property:

    ...
    "timed_out":     true,  (1)
    ...

  1. The search request timed out.

Warning

It’s important to know that the timeout is still a best-effort operation; it’s possible for the query to surpass the allotted timeout. There are two reasons for this behavior:

  1. Timeout checks are performed on a per-document basis. However, some query types have a significant amount of work that must be performed before documents are evaluated. This "setup" phase does not consult the timeout, and so very long setup times can cause the overall latency to shoot past the timeout.

  2. Because the time is once per document, a very long query can execute on a single document and it won’t timeout until the next document is evaluated. This also means poorly written scripts (e.g. ones with infinite loops) will be allowed to execute forever.

routing

In [routing-value], 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 [scale].

search_type

The default search type is query_then_fetch . In some cases, you might want to explicitly set the search_type to dfs_query_then_fetch to improve the accuracy of relevance scoring:

GET /_search?search_type=dfs_query_then_fetch

The dfs_query_then_fetch search type has a prequery phase that fetches the term frequencies from all involved shards to calculate global term frequencies. We discuss this further in [relevance-is-broken].