OpenSearch/docs/reference/search/search.asciidoc

69 lines
2.2 KiB
Plaintext
Raw Normal View History

[[search-search]]
== Search
2016-05-10 03:39:42 -04:00
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 rejects search requests that would query more than
1000 shards. The reason is that such large numbers of shards make the job of
the coordinating node very CPU and memory intensive. 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 bypass this limit, which is discouraged, you can update
the `action.search.shard_count.limit` cluster setting to a greater value.