2013-08-28 19:24:34 -04:00
|
|
|
[[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
|
2013-08-28 19:24:34 -04:00
|
|
|
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
|
2013-10-13 10:46:56 -04:00
|
|
|
<<multi-index,multi index syntax>>. For
|
2013-08-28 19:24:34 -04:00
|
|
|
example, we can search on all documents across all types within the
|
|
|
|
twitter index:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
GET /twitter/_search?q=user:kimchy
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
// CONSOLE
|
|
|
|
// TEST[setup:twitter]
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
We can also search within specific types:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
GET /twitter/tweet,user/_search?q=user:kimchy
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
// CONSOLE
|
|
|
|
// TEST[setup:twitter]
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
We can also search all tweets with a certain tag across several indices
|
|
|
|
(for example, when each user has his own index):
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
GET /kimchy,elasticsearch/tweet/_search?q=tag:wow
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
// CONSOLE
|
|
|
|
// TEST[s/^/PUT kimchy\nPUT elasticsearch\n/]
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
Or we can search all tweets across all available indices using `_all`
|
|
|
|
placeholder:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
GET /_all/tweet/_search?q=tag:wow
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
// CONSOLE
|
|
|
|
// TEST[setup:twitter]
|
2013-08-28 19:24:34 -04:00
|
|
|
|
|
|
|
Or even search across all indices and all types:
|
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
GET /_search?q=tag:wow
|
2013-08-28 19:24:34 -04:00
|
|
|
--------------------------------------------------
|
2016-09-14 11:23:25 -04:00
|
|
|
// CONSOLE
|
|
|
|
// TEST[setup:twitter]
|
2016-03-30 03:58:42 -04:00
|
|
|
|
|
|
|
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.
|