mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-09 06:25:07 +00:00
040b86a76b
Now that we have incremental reduce functions for topN and aggregations we can set the default for `action.search.shard_count.limit` to unlimited. This still allows users to restrict these settings while by default we executed across all shards matching the search requests index pattern.
70 lines
2.3 KiB
Plaintext
70 lines
2.3 KiB
Plaintext
[[search-search]]
|
|
== Search
|
|
|
|
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
|
|
<<search-uri-request,query string as a parameter>>, or using a
|
|
<<search-request-body,request body>>.
|
|
|
|
["float",id="search-multi-index-type"]
|
|
=== Multi-Index, Multi-Type
|
|
|
|
All search APIs can be applied across multiple types within an index, and
|
|
across multiple indices with support for the
|
|
<<multi-index,multi index syntax>>. For
|
|
example, we can search on all documents across all types within the
|
|
twitter index:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /twitter/_search?q=user:kimchy
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
We can also search within specific types:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /twitter/tweet,user/_search?q=user:kimchy
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
We can also search all tweets with a certain tag across several indices
|
|
(for example, when each user has his own index):
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /kimchy,elasticsearch/tweet/_search?q=tag:wow
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[s/^/PUT kimchy\nPUT elasticsearch\n/]
|
|
|
|
Or we can search all tweets across all available indices using `_all`
|
|
placeholder:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_all/tweet/_search?q=tag:wow
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
Or even search across all indices and all types:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search?q=tag:wow
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
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.
|