honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[DOCS] Replace `twitter` dataset in search/agg docs (#60667) (#60675)

This commit is contained in:
James Rodewig 2020-08-04 14:16:38 -04:00 committed by GitHub
parent 5db283262e
commit a21ec410c7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
33 changed files with 693 additions and 880 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
docs/build.gradle
View File

@ -122,52 +122,6 @@ buildRestTests.docs = fileTree(projectDir) {
listSnippets.docs = buildRestTests.docs
Closure setupTwitter = { String name, int count ->
buildRestTests.setups[name] = '''
- do:
indices.create:
index: twitter
body:
settings:
number_of_shards: 1
number_of_replicas: 1
mappings:
properties:
user:
type: keyword
doc_values: true
date:
type: date
likes:
type: long
location:
properties:
city:
type: keyword
country:
type: keyword
- do:
bulk:
index: twitter
refresh: true
body: |'''
for (int i = 0; i < count; i++) {
String body
if (i == 0) {
body = """{"user": "kimchy", "message": "trying out Elasticsearch", "date": "2009-11-15T14:12:12", "likes": 0,
"location": { "city": "Amsterdam", "country": "Netherlands" }}"""
} else {
body = """{"user": "test", "message": "some message with the number $i", "date": "2009-11-15T14:12:12", "likes": $i}"""
}
buildRestTests.setups[name] += """
{"index":{"_id": "$i"}}
$body"""
}
}
setupTwitter('twitter', 5)
setupTwitter('big_twitter', 120)
setupTwitter('huge_twitter', 1200)
Closure setupMyIndex = { String name, int count ->
buildRestTests.setups[name] = '''
- do:
@ -181,6 +135,12 @@ Closure setupMyIndex = { String name, int count ->
properties:
"@timestamp":
type: date
http:
properties:
request:
properties:
method:
type: keyword
message:
type: text
user:
@ -211,6 +171,31 @@ setupMyIndex('my_index', 5)
setupMyIndex('my_index_big', 120)
setupMyIndex('my_index_huge', 1200)
// Used for several full-text search and agg examples
buildRestTests.setups['messages'] = '''
- do:
indices.create:
index: my-index-000001
body:
settings:
number_of_shards: 1
number_of_replicas: 1
- do:
bulk:
index: my-index-000001
refresh: true
body: |
{"index":{"_id": "0"}}
{"message": "trying out Elasticsearch" }
{"index":{"_id": "1"}}
{"message": "some message with the number 1" }
{"index":{"_id": "2"}}
{"message": "some message with the number 2" }
{"index":{"_id": "3"}}
{"message": "some message with the number 3" }
{"index":{"_id": "4"}}
{"message": "some message with the number 4" }'''
buildRestTests.setups['host'] = '''
# Fetch the http host. We use the host of the master because we know there will always be a master.
- do:

2
docs/reference/aggregations/bucket/composite-aggregation.asciidoc
View File

@ -642,7 +642,7 @@ For instance the following index sort:
[source,console]
--------------------------------------------------
PUT twitter
PUT my-index-000001
{
"settings": {
"index": {

26
docs/reference/aggregations/metrics/string-stats-aggregation.asciidoc
View File

@ -19,18 +19,18 @@ The string stats aggregation returns the following results:
the aggregation. Shannon entropy quantifies the amount of information contained in the field. It is a very useful metric for
measuring a wide range of properties of a data set, such as diversity, similarity, randomness etc.
Assuming the data consists of twitter messages:
For example:
[source,console]
--------------------------------------------------
POST /twitter/_search?size=0
POST /my-index-000001/_search?size=0
{
"aggs": {
"message_stats": { "string_stats": { "field": "message.keyword" } }
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
The above aggregation computes the string statistics for the `message` field in all documents. The aggregation type
is `string_stats` and the `field` parameter defines the field of the documents the stats will be computed on.
@ -64,7 +64,7 @@ by the aggregation. To view the probability distribution for all characters, we
[source,console]
--------------------------------------------------
POST /twitter/_search?size=0
POST /my-index-000001/_search?size=0
{
"aggs": {
"message_stats": {
@ -76,7 +76,7 @@ POST /twitter/_search?size=0
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
<1> Set the `show_distribution` parameter to `true`, so that probability distribution for all characters is returned in the results.
@ -131,7 +131,7 @@ Computing the message string stats based on a script:
[source,console]
--------------------------------------------------
POST /twitter/_search?size=0
POST /my-index-000001/_search?size=0
{
"aggs": {
"message_stats": {
@ -145,14 +145,14 @@ POST /twitter/_search?size=0
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters.
To use a stored script use the following syntax:
[source,console]
--------------------------------------------------
POST /twitter/_search?size=0
POST /my-index-000001/_search?size=0
{
"aggs": {
"message_stats": {
@ -168,7 +168,7 @@ POST /twitter/_search?size=0
}
}
--------------------------------------------------
// TEST[setup:twitter,stored_example_script]
// TEST[setup:messages,stored_example_script]
===== Value Script
@ -176,7 +176,7 @@ We can use a value script to modify the message (eg we can add a prefix) and com
[source,console]
--------------------------------------------------
POST /twitter/_search?size=0
POST /my-index-000001/_search?size=0
{
"aggs": {
"message_stats": {
@ -194,7 +194,7 @@ POST /twitter/_search?size=0
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
==== Missing value
@ -203,7 +203,7 @@ By default they will be ignored but it is also possible to treat them as if they
[source,console]
--------------------------------------------------
POST /twitter/_search?size=0
POST /my-index-000001/_search?size=0
{
"aggs": {
"message_stats": {
@ -215,6 +215,6 @@ POST /twitter/_search?size=0
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
<1> Documents without a value in the `message` field will be treated as documents that have the value `[empty message]`.

42
docs/reference/aggregations/misc.asciidoc
View File

@ -17,19 +17,19 @@ setting `size=0`. For example:
[source,console]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"size": 0,
"aggregations": {
"my_agg": {
"terms": {
"field": "text"
"field": "user.id"
}
}
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
Setting `size` to `0` avoids executing the fetch phase of the search making the request more efficient.
@ -43,7 +43,7 @@ Consider this example where we want to associate the color blue with our `terms`
[source,console]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"size": 0,
"aggs": {
@ -58,7 +58,7 @@ GET /twitter/_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
Then that piece of metadata will be returned in place for our `titles` terms aggregation
@ -89,24 +89,24 @@ Sometimes you need to know the exact type of an aggregation in order to parse it
can be used to change the aggregation's name in the response so that it will be prefixed by its internal type.
Considering the following <<search-aggregations-bucket-datehistogram-aggregation,`date_histogram` aggregation>> named
`tweets_over_time` which has a sub <<search-aggregations-metrics-top-hits-aggregation, 'top_hits` aggregation>> named
`requests_over_time` which has a sub <<search-aggregations-metrics-top-hits-aggregation, `top_hits` aggregation>> named
`top_users`:
[source,console]
--------------------------------------------------
GET /twitter/_search?typed_keys
GET /my-index-000001/_search?typed_keys
{
"aggregations": {
"tweets_over_time": {
"requests_over_time": {
"date_histogram": {
"field": "date",
"field": "@timestamp",
"calendar_interval": "year"
},
"aggregations": {
"top_users": {
"top_hits": {
"size": 1,
"_source": ["user", "likes", "message"]
"_source": ["user.id", "http.response.bytes", "message"]
}
}
}
@ -114,20 +114,20 @@ GET /twitter/_search?typed_keys
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
In the response, the aggregations names will be changed to respectively `date_histogram#tweets_over_time` and
In the response, the aggregations names will be changed to respectively `date_histogram#requests_over_time` and
`top_hits#top_users`, reflecting the internal types of each aggregation:
[source,console-result]
--------------------------------------------------
{
"aggregations": {
"date_histogram#tweets_over_time": { <1>
"buckets": [
"date_histogram#requests_over_time": { <1>
"buckets": [
{
"key_as_string": "2009-01-01T00:00:00.000Z",
"key": 1230768000000,
"key_as_string": "2099-01-01T00:00:00.000Z",
"key": 4070908800000,
"doc_count": 5,
"top_hits#top_users": { <2>
"hits": {
@ -138,14 +138,14 @@ In the response, the aggregations names will be changed to respectively `date_hi
"max_score": 1.0,
"hits": [
{
"_index": "twitter",
"_index": "my-index-000001",
"_type": "_doc",
"_id": "0",
"_score": 1.0,
"_source": {
"user": "kimchy",
"message": "trying out Elasticsearch",
"likes": 0
"user": { "id": "kimchy"},
"message": "GET /search HTTP/1.1 200 1070000",
"http": { "response": { "bytes": 1070000 } }
}
}
]
@ -160,7 +160,7 @@ In the response, the aggregations names will be changed to respectively `date_hi
--------------------------------------------------
// TESTRESPONSE[s/\.\.\./"took": "$body.took", "timed_out": false, "_shards": "$body._shards", "hits": "$body.hits"/]
<1> The name `tweets_over_time` now contains the `date_histogram` prefix.
<1> The name `requests_over_time` now contains the `date_histogram` prefix.
<2> The name `top_users` now contains the `top_hits` prefix.
NOTE: For some aggregations, it is possible that the returned type is not the same as the one provided with the

262
docs/reference/indices/put-mapping.asciidoc
View File

@ -11,7 +11,7 @@ For data streams, these changes are applied to all backing indices by default.
[source,console]
----
PUT /twitter/_mapping
PUT /my-index-000001/_mapping
{
"properties": {
"email": {
@ -20,7 +20,7 @@ PUT /twitter/_mapping
}
}
----
// TEST[setup:twitter]
// TEST[setup:my_index]
NOTE: Before 7.0.0, the 'mappings' definition used to include a type name.
Although specifying types in requests is now deprecated, a type can still be
@ -116,42 +116,38 @@ PUT /publications/_mapping
===== Multiple targets
The PUT mapping API can be applied to multiple data streams or indices with a single request.
For example, you can update mappings for the `twitter-1` and `twitter-2` indices at the same time:
For example, you can update mappings for the `my-index-000001` and `my-index-000002` indices at the same time:
[source,console]
--------------------------------------------------
# Create the two indices
PUT /twitter-1
PUT /twitter-2
PUT /my-index-000001
PUT /my-index-000002
# Update both mappings
PUT /twitter-1,twitter-2/_mapping <1>
PUT /my-index-000001,my-index-000002/_mapping
{
"properties": {
"user_name": {
"type": "text"
"user": {
"properties": {
"name": {
"type": "keyword"
}
}
}
}
}
--------------------------------------------------
// TEST[setup:twitter]
<1> Note that the indices specified (`twitter-1,twitter-2`) follows <<multi-index,multiple index names>> and wildcard format.
[[add-new-field-to-object]]
===== Add new properties to an existing object field
You can use the put mapping API
to add new properties
to an existing <<object,`object`>> field.
To see how this works,
try the following example.
You can use the put mapping API to add new properties to an existing
<<object,`object`>> field. To see how this works, try the following example.
Use the <<indices-create-index,create index>> API
to create an index
with the `name` object field
and an inner `first` text field.
Use the <<indices-create-index,create index>> API to create an index with the
`name` object field and an inner `first` text field.
[source,console]
----
@ -171,9 +167,8 @@ PUT /my-index-000001
}
----
Use the put mapping API
to add a new inner `last` text field
to the `name` field.
Use the put mapping API to add a new inner `last` text field to the `name`
field.
[source,console]
----
@ -192,56 +187,18 @@ PUT /my-index-000001/_mapping
----
// TEST[continued]
Use the <<indices-get-mapping,get mapping>> API
to verify your changes.
[source,console]
----
GET /my-index-000001/_mapping
----
// TEST[continued]
The API returns the following response:
[source,console-result]
----
{
"my-index-000001" : {
"mappings" : {
"properties" : {
"name" : {
"properties" : {
"first" : {
"type" : "text"
},
"last" : {
"type" : "text"
}
}
}
}
}
}
}
----
[[add-multi-fields-existing-field-ex]]
===== Add multi-fields to an existing field
<<multi-fields,Multi-fields>>
let you index the same field
in different ways.
You can use the put mapping API
to update the `fields` mapping parameter
and enable multi-fields for an existing field.
<<multi-fields,Multi-fields>> let you index the same field in different ways.
You can use the put mapping API to update the `fields` mapping parameter and
enable multi-fields for an existing field.
To see how this works,
try the following example.
To see how this works, try the following example.
Use the <<indices-create-index,create index>> API
to create an index
with the `city` <<text,text>> field.
Use the <<indices-create-index,create index>> API to create an index with the
`city` <<text,text>> field.
[source,console]
----
@ -257,14 +214,11 @@ PUT /my-index-000001
}
----
While text fields work well for full-text search,
<<keyword,keyword>> fields are not analyzed
and may work better for sorting or aggregations.
While text fields work well for full-text search, <<keyword,keyword>> fields are
not analyzed and may work better for sorting or aggregations.
Use the put mapping API
to enable a multi-field for the `city` field.
This request adds the `city.raw` keyword multi-field,
which can be used for sorting.
Use the put mapping API to enable a multi-field for the `city` field. This
request adds the `city.raw` keyword multi-field, which can be used for sorting.
[source,console]
----
@ -284,57 +238,20 @@ PUT /my-index-000001/_mapping
----
// TEST[continued]
Use the <<indices-get-mapping,get mapping>> API
to verify your changes.
[source,console]
----
GET /my-index-000001/_mapping
----
// TEST[continued]
The API returns the following response:
[source,console-result]
----
{
"my-index-000001" : {
"mappings" : {
"properties" : {
"city" : {
"type" : "text",
"fields" : {
"raw" : {
"type" : "keyword"
}
}
}
}
}
}
}
----
[[change-existing-mapping-parms]]
===== Change supported mapping parameters for an existing field
The documentation for each <<mapping-params,mapping parameter>>
indicates whether you can update it
for an existing field
using the put mapping API.
For example,
you can use the put mapping API
to update the <<ignore-above,`ignore_above`>> parameter.
The documentation for each <<mapping-params,mapping parameter>> indicates
whether you can update it for an existing field using the put mapping API. For
example, you can use the put mapping API to update the
<<ignore-above,`ignore_above`>> parameter.
To see how this works,
try the following example.
To see how this works, try the following example.
Use the <<indices-create-index,create index>> API to create an index
containing a `user_id` keyword field.
The `user_id` field
has an `ignore_above` parameter value
of `20`.
Use the <<indices-create-index,create index>> API to create an index containing
a `user_id` keyword field. The `user_id` field has an `ignore_above` parameter
value of `20`.
[source,console]
----
@ -351,9 +268,7 @@ PUT /my-index-000001
}
----
Use the put mapping API
to change the `ignore_above` parameter value
to `100`.
Use the put mapping API to change the `ignore_above` parameter value to `100`.
[source,console]
----
@ -369,33 +284,6 @@ PUT /my-index-000001/_mapping
----
// TEST[continued]
Use the <<indices-get-mapping,get mapping>> API
to verify your changes.
[source,console]
----
GET /my-index-000001/_mapping
----
// TEST[continued]
The API returns the following response:
[source,console-result]
----
{
"my-index-000001" : {
"mappings" : {
"properties" : {
"user_id" : {
"type" : "keyword",
"ignore_above" : 100
}
}
}
}
}
----
[[updating-field-mappings]]
===== Change the mapping of an existing field
@ -417,13 +305,13 @@ To see how you can change the mapping of an existing field in an index,
try the following example.
Use the <<indices-create-index,create index>> API
to create the `users` index
to create an index
with the `user_id` field
with the <<number,`long`>> field type.
[source,console]
----
PUT /users
PUT /my-index-000001
{
"mappings" : {
"properties": {
@ -441,12 +329,12 @@ with `user_id` field values.
[source,console]
----
POST /users/_doc?refresh=wait_for
POST /my-index-000001/_doc?refresh=wait_for
{
"user_id" : 12345
}
POST /users/_doc?refresh=wait_for
POST /my-index-000001/_doc?refresh=wait_for
{
"user_id" : 12346
}
@ -456,11 +344,11 @@ POST /users/_doc?refresh=wait_for
To change the `user_id` field
to the <<keyword,`keyword`>> field type,
use the create index API
to create the `new_users` index with the correct mapping.
to create a new index with the correct mapping.
[source,console]
----
PUT /new_users
PUT /my-new-index-000001
{
"mappings" : {
"properties": {
@ -474,49 +362,23 @@ PUT /new_users
// TEST[continued]
Use the <<docs-reindex,reindex>> API
to copy documents from the `users` index
to the `new_users` index.
to copy documents from the old index
to the new one.
[source,console]
----
POST /_reindex
{
"source": {
"index": "users"
"index": "my-index-000001"
},
"dest": {
"index": "new_users"
"index": "my-new-index-000001"
}
}
----
// TEST[continued]
The API returns the following response:
[source,console-result]
----
{
"took": 147,
"timed_out": false,
"total": 2,
"updated": 0,
"created": 2,
"deleted": 0,
"batches": 1,
"version_conflicts": 0,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1.0,
"throttled_until_millis": 0,
"failures" : [ ]
}
----
// TESTRESPONSE[s/"took": 147/"took": "$body.took"/]
[[rename-existing-field]]
===== Rename a field
@ -561,33 +423,3 @@ PUT /my-index-000001/_mapping
}
----
// TEST[continued]
Use the <<indices-get-mapping,get mapping>> API
to verify your changes.
[source,console]
----
GET /my-index-000001/_mapping
----
// TEST[continued]
The API returns the following response:
[source,console-result]
----
{
"my-index-000001" : {
"mappings" : {
"properties" : {
"user_id" : {
"type" : "alias",
"path" : "user_identifier"
},
"user_identifier" : {
"type" : "keyword"
}
}
}
}
}
----

14
docs/reference/indices/synced-flush.asciidoc
View File

@ -10,7 +10,7 @@ Performs a synced flush on one or more indices.
[source,console]
--------------------------------------------------
POST /twitter/_flush/synced
POST /my-index-000001/_flush/synced
--------------------------------------------------
// TEST[skip: Synced flush can conflict with scheduled flushes in doc tests]
@ -80,7 +80,7 @@ section of the shard stats returned by the <<indices-stats,indices stats>> API:
[source,console]
--------------------------------------------------
GET /twitter/_stats?filter_path=**.commit&level=shards <1>
GET /my-index-000001/_stats?filter_path=**.commit&level=shards <1>
--------------------------------------------------
// TEST[skip: Synced flush can conflict with scheduled flushes in doc tests]
@ -92,7 +92,7 @@ The API returns the following response:
--------------------------------------------------
{
"indices": {
"twitter": {
"my-index-000001": {
"shards": {
"0": [
{
@ -208,7 +208,7 @@ successfully sync-flushed:
"successful": 2,
"failed": 0
},
"twitter": {
"my-index-000001": {
"total": 2,
"successful": 2,
"failed": 0
@ -228,7 +228,7 @@ due to pending operations:
"successful": 2,
"failed": 2
},
"twitter": {
"my-index-000001": {
"total": 4,
"successful": 2,
"failed": 2,
@ -255,7 +255,7 @@ This case is reported as follows:
"successful": 1,
"failed": 1
},
"twitter": {
"my-index-000001": {
"total": 4,
"successful": 3,
"failed": 1,
@ -269,7 +269,7 @@ This case is reported as follows:
"node": "SZNr2J_ORxKTLUCydGX4zA",
"relocating_node": null,
"shard": 1,
"index": "twitter"
"index": "my-index-000001"
}
}
]

4
docs/reference/indices/types-exists.asciidoc
View File

@ -10,9 +10,9 @@ Checks if a <<mapping-type-field,mapping type>> exists.
[source,console]
----
HEAD twitter/_mapping/tweet
HEAD my-index-000001/_mapping/message
----
// TEST[setup:twitter]
// TEST[setup:my_index]
// TEST[warning:Type exists requests are deprecated, as types have been deprecated.]

10
docs/reference/query-dsl/function-score-query.asciidoc
View File

@ -144,7 +144,7 @@ GET /_search
},
"script_score": {
"script": {
"source": "Math.log(2 + doc['likes'].value)"
"source": "Math.log(2 + doc['my-int'].value)"
}
}
}
@ -186,7 +186,7 @@ GET /_search
"a": 5,
"b": 1.2
},
"source": "params.a / Math.pow(params.b, doc['likes'].value)"
"source": "params.a / Math.pow(params.b, doc['my-int'].value)"
}
}
}
@ -261,7 +261,7 @@ influence the score. It's similar to using the `script_score` function, however,
it avoids the overhead of scripting. If used on a multi-valued field, only the
first value of the field is used in calculations.
As an example, imagine you have a document indexed with a numeric `likes`
As an example, imagine you have a document indexed with a numeric `my-int`
field and wish to influence the score of a document with this field, an example
doing so would look like:
@ -272,7 +272,7 @@ GET /_search
"query": {
"function_score": {
"field_value_factor": {
"field": "likes",
"field": "my-int",
"factor": 1.2,
"modifier": "sqrt",
"missing": 1
@ -285,7 +285,7 @@ GET /_search
Which will translate into the following formula for scoring:
`sqrt(1.2 * doc['likes'].value)`
`sqrt(1.2 * doc['my-int'].value)`
There are a number of options for the `field_value_factor` function:

20
docs/reference/query-dsl/script-score-query.asciidoc
View File

@ -12,7 +12,7 @@ The `script_score` query is useful if, for example, a scoring function is expens
[[script-score-query-ex-request]]
==== Example request
The following `script_score` query assigns each returned document a score equal to the `likes` field value divided by `10`.
The following `script_score` query assigns each returned document a score equal to the `my-int` field value divided by `10`.
[source,console]
--------------------------------------------------
@ -24,7 +24,7 @@ GET /_search
"match": { "message": "elasticsearch" }
},
"script": {
"source": "doc['likes'].value / 10 "
"source": "doc['my-int'].value / 10 "
}
}
}
@ -90,7 +90,7 @@ These functions take advantage of efficiencies from {es}' internal mechanisms.
[source,js]
--------------------------------------------------
"script" : {
"source" : "saturation(doc['likes'].value, 1)"
"source" : "saturation(doc['my-int'].value, 1)"
}
--------------------------------------------------
// NOTCONSOLE
@ -102,7 +102,7 @@ These functions take advantage of efficiencies from {es}' internal mechanisms.
[source,js]
--------------------------------------------------
"script" : {
"source" : "sigmoid(doc['likes'].value, 2, 1)"
"source" : "sigmoid(doc['my-int'].value, 2, 1)"
}
--------------------------------------------------
// NOTCONSOLE
@ -343,7 +343,7 @@ Using an <<search-explain, explain request>> provides an explanation of how the
[source,console]
--------------------------------------------------
GET /twitter/_explain/0
GET /my-index-000001/_explain/0
{
"query": {
"script_score": {
@ -352,18 +352,18 @@ GET /twitter/_explain/0
},
"script": {
"source": """
long likes = doc['likes'].value;
double normalizedLikes = likes / 10;
long count = doc['count'].value;
double normalizedCount = count / 10;
if (explanation != null) {
explanation.set('normalized likes = likes / 10 = ' + likes + ' / 10 = ' + normalizedLikes);
explanation.set('normalized count = count / 10 = ' + count + ' / 10 = ' + normalizedCount);
}
return normalizedLikes;
return normalizedCount;
"""
}
}
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
Note that the `explanation` will be null when using in a normal `_search` request, so having a conditional guard is best practice.

4
docs/reference/scripting/using.asciidoc
View File

@ -116,7 +116,7 @@ Short form:
[source,js]
----------------------
"script": "ctx._source.likes++"
"script": "ctx._source.my-int++"
----------------------
// NOTCONSOLE
@ -125,7 +125,7 @@ The same script in the normal form:
[source,js]
----------------------
"script": {
"source": "ctx._source.likes++"
"source": "ctx._source.my-int++"
}
----------------------
// NOTCONSOLE

2
docs/reference/search/clear-scroll-api.asciidoc
View File

@ -18,7 +18,7 @@ GET /_search?scroll=1m
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
////
[source,console]

20
docs/reference/search/count.asciidoc
View File

@ -5,12 +5,12 @@ Gets the number of matches for a search query.
[source,console]
--------------------------------------------------
GET /twitter/_count?q=user:kimchy
GET /my-index-000001/_count?q=user:kimchy
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
NOTE: The query being sent in the body must be nested in a `query` key, same as
the <<search-search,search api>> works.
the <<search-search,search API>> works.
[[search-count-api-request]]
@ -97,23 +97,23 @@ include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=query]
[source,console]
--------------------------------------------------
PUT /twitter/_doc/1?refresh
PUT /my-index-000001/_doc/1?refresh
{
"user": "kimchy"
"user.id": "kimchy"
}
GET /twitter/_count?q=user:kimchy
GET /my-index-000001/_count?q=user:kimchy
GET /twitter/_count
GET /my-index-000001/_count
{
"query" : {
"term" : { "user" : "kimchy" }
"term" : { "user.id" : "kimchy" }
}
}
--------------------------------------------------
Both examples above do the same: count the number of tweets from the `twitter`
index for a certain user. The API returns the following response:
Both examples above do the same: count the number of documents in
`my-index-000001` with a `user.id` of `kimchy`. The API returns the following response:
[source,console-result]
--------------------------------------------------

14
docs/reference/search/explain.asciidoc
View File

@ -6,14 +6,14 @@ query.
[source,console]
--------------------------------------------------
GET /twitter/_explain/0
GET /my-index-000001/_explain/0
{
"query" : {
"match" : { "message" : "elasticsearch" }
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
[[sample-api-request]]
@ -87,14 +87,14 @@ include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=query]
[source,console]
--------------------------------------------------
GET /twitter/_explain/0
GET /my-index-000001/_explain/0
{
"query" : {
"match" : { "message" : "elasticsearch" }
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
The API returns the following response:
@ -102,7 +102,7 @@ The API returns the following response:
[source,console-result]
--------------------------------------------------
{
"_index":"twitter",
"_index":"my-index-000001",
"_type":"_doc",
"_id":"0",
"matched":true,
@ -181,9 +181,9 @@ explain API:
[source,console]
--------------------------------------------------
GET /twitter/_explain/0?q=message:search
GET /my-index-000001/_explain/0?q=message:search
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
The API returns the same result as the previous request.

8
docs/reference/search/field-caps.asciidoc
View File

@ -116,9 +116,9 @@ The request can be restricted to specific data streams and indices:
[source,console]
--------------------------------------------------
GET twitter/_field_caps?fields=rating
GET my-index-000001/_field_caps?fields=rating
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The next example API call requests information about the `rating` and the
@ -228,7 +228,7 @@ It is also possible to filter indices with a query:
[source,console]
--------------------------------------------------
POST twitter*/_field_caps?fields=rating
POST my-index-*/_field_caps?fields=rating
{
"index_filter": {
"range": {
@ -239,7 +239,7 @@ POST twitter*/_field_caps?fields=rating
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
In which case indices that rewrite the provided filter to `match_none` on every shard

24
docs/reference/search/multi-search.asciidoc
View File

@ -8,13 +8,13 @@ Executes several searches with a single API request.
[source,console]
--------------------------------------------------
GET twitter/_msearch
GET my-index-000001/_msearch
{ }
{"query" : {"match" : { "message": "this is a test"}}}
{"index": "twitter2"}
{"index": "my-index-000002"}
{"query" : {"match_all" : {}}}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[[search-multi-search-api-request]]
==== {api-request-title}
@ -299,19 +299,19 @@ unless explicitly specified in the header's `index` parameter. For example:
[source,console]
--------------------------------------------------
GET twitter/_msearch
GET my-index-000001/_msearch
{}
{"query" : {"match_all" : {}}, "from" : 0, "size" : 10}
{}
{"query" : {"match_all" : {}}}
{"index" : "twitter2"}
{"index" : "my-index-000002"}
{"query" : {"match_all" : {}}}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The above will execute the search against the `twitter` index for all the
The above will execute the search against the `my-index-000001` index for all the
requests that don't define an `index` target in the request body. The last
search will be executed against the `twitter2` index.
search will be executed against the `my-index-000002` index.
The `search_type` can be set in a similar manner to globally apply to
all search requests.
@ -333,12 +333,12 @@ templates:
[source,console]
-----------------------------------------------
GET _msearch/template
{"index" : "twitter"}
{"index" : "my-index-000001"}
{ "source" : "{ \"query\": { \"match\": { \"message\" : \"{{keywords}}\" } } } }", "params": { "query_type": "match", "keywords": "some message" } }
{"index" : "twitter"}
{"index" : "my-index-000001"}
{ "source" : "{ \"query\": { \"match_{{template}}\": {} } }", "params": { "template": "all" } }
-----------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
You can also create search templates:
@ -359,7 +359,7 @@ POST /_scripts/my_template_1
}
}
------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[source,console]

612
docs/reference/search/profile.asciidoc
View File

@ -30,15 +30,15 @@ Any `_search` request can be profiled by adding a top-level `profile` parameter:
[source,console]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"profile": true,<1>
"query" : {
"match" : { "message" : "some number" }
"match" : { "message" : "GET /search" }
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
<1> Setting the top-level `profile` parameter to `true` will enable profiling
for the search.
@ -49,127 +49,127 @@ The API returns the following result:
[source,console-result]
--------------------------------------------------
{
"took": 25,
"timed_out": false,
"_shards": {
"total": 1,
"successful": 1,
"skipped" : 0,
"failed": 0
},
"hits": {
"total" : {
"value": 4,
"relation": "eq"
},
"max_score": 0.5093388,
"hits": [...] <1>
},
"profile": {
"shards": [
{
"id": "[2aE02wS1R8q_QFnYu6vDVQ][twitter][0]",
"searches": [
"took": 25,
"timed_out": false,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
},
"hits": {
"total": {
"value": 5,
"relation": "eq"
},
"max_score": 0.17402273,
"hits": [...] <1>
},
"profile": {
"shards": [
{
"id": "[2aE02wS1R8q_QFnYu6vDVQ][my-index-000001][0]",
"searches": [
{
"query": [
{
"query": [
{
"type": "BooleanQuery",
"description": "message:some message:number",
"time_in_nanos": "1873811",
"breakdown": {
"score": 51306,
"score_count": 4,
"build_scorer": 2935582,
"build_scorer_count": 1,
"match": 0,
"match_count": 0,
"create_weight": 919297,
"create_weight_count": 1,
"next_doc": 53876,
"next_doc_count": 5,
"advance": 0,
"advance_count": 0,
"compute_max_score": 0,
"compute_max_score_count": 0,
"shallow_advance": 0,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"set_min_competitive_score_count": 0
},
"children": [
{
"type": "TermQuery",
"description": "message:some",
"time_in_nanos": "391943",
"breakdown": {
"score": 28776,
"score_count": 4,
"build_scorer": 784451,
"build_scorer_count": 1,
"match": 0,
"match_count": 0,
"create_weight": 1669564,
"create_weight_count": 1,
"next_doc": 10111,
"next_doc_count": 5,
"advance": 0,
"advance_count": 0,
"compute_max_score": 0,
"compute_max_score_count": 0,
"shallow_advance": 0,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"set_min_competitive_score_count": 0
}
},
{
"type": "TermQuery",
"description": "message:number",
"time_in_nanos": "210682",
"breakdown": {
"score": 4552,
"score_count": 4,
"build_scorer": 42602,
"build_scorer_count": 1,
"match": 0,
"match_count": 0,
"create_weight": 89323,
"create_weight_count": 1,
"next_doc": 2852,
"next_doc_count": 5,
"advance": 0,
"advance_count": 0,
"compute_max_score": 0,
"compute_max_score_count": 0,
"shallow_advance": 0,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"set_min_competitive_score_count": 0
}
}
]
"type": "BooleanQuery",
"description": "message:get
message:search", "time_in_nanos" : 11972972, "breakdown" :
{
"set_min_competitive_score_count": 0,
"match_count": 5,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"next_doc": 39022,
"match": 4456,
"next_doc_count": 5,
"score_count": 5,
"compute_max_score_count": 0,
"compute_max_score": 0,
"advance": 84525,
"advance_count": 1,
"score": 37779,
"build_scorer_count": 2,
"create_weight": 4694895,
"shallow_advance": 0,
"create_weight_count": 1,
"build_scorer": 7112295
},
"children": [
{
"type": "TermQuery",
"description": "message:get",
"time_in_nanos": 3801935,
"breakdown": {
"set_min_competitive_score_count": 0,
"match_count": 0,
"shallow_advance_count": 3,
"set_min_competitive_score": 0,
"next_doc": 0,
"match": 0,
"next_doc_count": 0,
"score_count": 5,
"compute_max_score_count": 3,
"compute_max_score": 32487,
"advance": 5749,
"advance_count": 6,
"score": 16219,
"build_scorer_count": 3,
"create_weight": 2382719,
"shallow_advance": 9754,
"create_weight_count": 1,
"build_scorer": 1355007
}
],
"rewrite_time": 51443,
"collector": [
{
"name": "SimpleTopScoreDocCollector",
"reason": "search_top_hits",
"time_in_nanos": "32273"
},
{
"type": "TermQuery",
"description": "message:search",
"time_in_nanos": 205654,
"breakdown": {
"set_min_competitive_score_count": 0,
"match_count": 0,
"shallow_advance_count": 3,
"set_min_competitive_score": 0,
"next_doc": 0,
"match": 0,
"next_doc_count": 0,
"score_count": 5,
"compute_max_score_count": 3,
"compute_max_score": 6678,
"advance": 12733,
"advance_count": 6,
"score": 6627,
"build_scorer_count": 3,
"create_weight": 130951,
"shallow_advance": 2512,
"create_weight_count": 1,
"build_scorer": 46153
}
]
}
]
}
],
"aggregations": []
}
]
}
],
"rewrite_time": 451233,
"collector": [
{
"name": "SimpleTopScoreDocCollector",
"reason": "search_top_hits",
"time_in_nanos": 775274
}
]
}
],
"aggregations": []
}
]
}
}
--------------------------------------------------
// TESTRESPONSE[s/"took": 25/"took": $body.took/]
// TESTRESPONSE[s/"hits": \[...\]/"hits": $body.$_path/]
// TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
// TESTRESPONSE[s/\[2aE02wS1R8q_QFnYu6vDVQ\]\[twitter\]\[0\]/$body.$_path/]
// TESTRESPONSE[s/\[2aE02wS1R8q_QFnYu6vDVQ\]\[my-index-000001\]\[0\]/$body.$_path/]
<1> Search results are returned, but were omitted here for brevity.
@ -185,7 +185,7 @@ The overall structure of the profile response is as follows:
"profile": {
"shards": [
{
"id": "[2aE02wS1R8q_QFnYu6vDVQ][twitter][0]", <1>
"id": "[2aE02wS1R8q_QFnYu6vDVQ][my-index-000001][0]", <1>
"searches": [
{
"query": [...], <2>
@ -201,7 +201,7 @@ The overall structure of the profile response is as follows:
--------------------------------------------------
// TESTRESPONSE[s/"profile": /"took": $body.took, "timed_out": $body.timed_out, "_shards": $body._shards, "hits": $body.hits, "profile": /]
// TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
// TESTRESPONSE[s/\[2aE02wS1R8q_QFnYu6vDVQ\]\[twitter\]\[0\]/$body.$_path/]
// TESTRESPONSE[s/\[2aE02wS1R8q_QFnYu6vDVQ\]\[my-index-000001\]\[0\]/$body.$_path/]
// TESTRESPONSE[s/"query": \[...\]/"query": $body.$_path/]
// TESTRESPONSE[s/"collector": \[...\]/"collector": $body.$_path/]
// TESTRESPONSE[s/"aggregations": \[...\]/"aggregations": []/]
@ -271,20 +271,20 @@ Using our previous `match` query example, let's analyze the `query` section:
"query": [
{
"type": "BooleanQuery",
"description": "message:some message:number",
"time_in_nanos": "1873811",
"description": "message:get message:search",
"time_in_nanos": "11972972",
"breakdown": {...}, <1>
"children": [
{
"type": "TermQuery",
"description": "message:some",
"time_in_nanos": "391943",
"description": "message:get",
"time_in_nanos": "3801935",
"breakdown": {...}
},
{
"type": "TermQuery",
"description": "message:number",
"time_in_nanos": "210682",
"description": "message:search",
"time_in_nanos": "205654",
"breakdown": {...}
}
]
@ -323,27 +323,27 @@ Lucene execution:
[source,console-result]
--------------------------------------------------
"breakdown": {
"score": 51306,
"score_count": 4,
"build_scorer": 2935582,
"build_scorer_count": 1,
"match": 0,
"match_count": 0,
"create_weight": 919297,
"create_weight_count": 1,
"next_doc": 53876,
"next_doc_count": 5,
"advance": 0,
"advance_count": 0,
"compute_max_score": 0,
"compute_max_score_count": 0,
"shallow_advance": 0,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"set_min_competitive_score_count": 0
"set_min_competitive_score_count": 0,
"match_count": 5,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"next_doc": 39022,
"match": 4456,
"next_doc_count": 5,
"score_count": 5,
"compute_max_score_count": 0,
"compute_max_score": 0,
"advance": 84525,
"advance_count": 1,
"score": 37779,
"build_scorer_count": 2,
"create_weight": 4694895,
"shallow_advance": 0,
"create_weight_count": 1,
"build_scorer": 7112295
}
--------------------------------------------------
// TESTRESPONSE[s/^/{\n"took": $body.took,\n"timed_out": $body.timed_out,\n"_shards": $body._shards,\n"hits": $body.hits,\n"profile": {\n"shards": [ {\n"id": "$body.$_path",\n"searches": [{\n"query": [{\n"type": "BooleanQuery",\n"description": "message:some message:number",\n"time_in_nanos": $body.$_path,/]
// TESTRESPONSE[s/^/{\n"took": $body.took,\n"timed_out": $body.timed_out,\n"_shards": $body._shards,\n"hits": $body.hits,\n"profile": {\n"shards": [ {\n"id": "$body.$_path",\n"searches": [{\n"query": [{\n"type": "BooleanQuery",\n"description": "message:get message:search",\n"time_in_nanos": $body.$_path,/]
// TESTRESPONSE[s/}$/},\n"children": $body.$_path}],\n"rewrite_time": $body.$_path, "collector": $body.$_path}], "aggregations": []}]}}/]
// TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
@ -437,11 +437,11 @@ Looking at the previous example:
[source,console-result]
--------------------------------------------------
"collector": [
{
"name": "SimpleTopScoreDocCollector",
"reason": "search_top_hits",
"time_in_nanos": "32273"
}
{
"name": "SimpleTopScoreDocCollector",
"reason": "search_top_hits",
"time_in_nanos": 775274
}
]
--------------------------------------------------
// TESTRESPONSE[s/^/{\n"took": $body.took,\n"timed_out": $body.timed_out,\n"_shards": $body._shards,\n"hits": $body.hits,\n"profile": {\n"shards": [ {\n"id": "$body.$_path",\n"searches": [{\n"query": $body.$_path,\n"rewrite_time": $body.$_path,/]
@ -531,20 +531,20 @@ profile the following query:
[source,console]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"profile": true,
"query": {
"term": {
"user": {
"value": "test"
"user.id": {
"value": "elkbee"
}
}
},
"aggs": {
"my_scoped_agg": {
"terms": {
"field": "likes"
"field": "http.response.status_code"
}
},
"my_global_agg": {
@ -552,7 +552,7 @@ GET /twitter/_search
"aggs": {
"my_level_agg": {
"terms": {
"field": "likes"
"field": "http.response.status_code"
}
}
}
@ -560,13 +560,14 @@ GET /twitter/_search
},
"post_filter": {
"match": {
"message": "some"
"message": "search"
}
}
}
--------------------------------------------------
// TEST[setup:my_index]
// TEST[s/_search/_search\?filter_path=profile.shards.id,profile.shards.searches,profile.shards.aggregations/]
// TEST[continued]
This example has:
@ -581,112 +582,112 @@ The API returns the following result:
[source,console-result]
--------------------------------------------------
{
...
"profile": {
"shards": [
{
"id": "[P6-vulHtQRWuD4YnubWb7A][test][0]",
"searches": [
...
"profile": {
"shards": [
{
"id": "[P6-vulHtQRWuD4YnubWb7A][my-index-000001][0]",
"searches": [
{
"query": [
{
"type": "TermQuery",
"description": "message:search",
"time_in_nanos": 141618,
"breakdown": {
"set_min_competitive_score_count": 0,
"match_count": 0,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"next_doc": 0,
"match": 0,
"next_doc_count": 0,
"score_count": 0,
"compute_max_score_count": 0,
"compute_max_score": 0,
"advance": 3942,
"advance_count": 4,
"score": 0,
"build_scorer_count": 2,
"create_weight": 38380,
"shallow_advance": 0,
"create_weight_count": 1,
"build_scorer": 99296
}
},
{
"type": "TermQuery",
"description": "user.id:elkbee",
"time_in_nanos": 163081,
"breakdown": {
"set_min_competitive_score_count": 0,
"match_count": 0,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"next_doc": 2447,
"match": 0,
"next_doc_count": 4,
"score_count": 4,
"compute_max_score_count": 0,
"compute_max_score": 0,
"advance": 3552,
"advance_count": 1,
"score": 5027,
"build_scorer_count": 2,
"create_weight": 107840,
"shallow_advance": 0,
"create_weight_count": 1,
"build_scorer": 44215
}
}
],
"rewrite_time": 4769,
"collector": [
{
"name": "MultiCollector",
"reason": "search_multi",
"time_in_nanos": 1945072,
"children": [
{
"query": [
{
"type": "TermQuery",
"description": "message:some",
"time_in_nanos": "409456",
"breakdown": {
"score": 0,
"build_scorer_count": 1,
"match_count": 0,
"create_weight": 31584,
"next_doc": 0,
"match": 0,
"create_weight_count": 1,
"next_doc_count": 2,
"score_count": 1,
"build_scorer": 377872,
"advance": 0,
"advance_count": 0,
"compute_max_score": 0,
"compute_max_score_count": 0,
"shallow_advance": 0,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"set_min_competitive_score_count": 0
}
},
{
"type": "TermQuery",
"description": "user:test",
"time_in_nanos": "303702",
"breakdown": {
"score": 0,
"build_scorer_count": 1,
"match_count": 0,
"create_weight": 185215,
"next_doc": 5936,
"match": 0,
"create_weight_count": 1,
"next_doc_count": 2,
"score_count": 1,
"build_scorer": 112551,
"advance": 0,
"advance_count": 0,
"compute_max_score": 0,
"compute_max_score_count": 0,
"shallow_advance": 0,
"shallow_advance_count": 0,
"set_min_competitive_score": 0,
"set_min_competitive_score_count": 0
}
}
],
"rewrite_time": 7208,
"collector": [
{
"name": "MultiCollector",
"reason": "search_multi",
"time_in_nanos": 1820,
"children": [
{
"name": "FilteredCollector",
"reason": "search_post_filter",
"time_in_nanos": 7735,
"children": [
{
"name": "SimpleTopScoreDocCollector",
"reason": "search_top_hits",
"time_in_nanos": 1328
}
]
},
{
"name": "MultiBucketCollector: [[my_scoped_agg, my_global_agg]]",
"reason": "aggregation",
"time_in_nanos": 8273
}
]
}
]
"name": "FilteredCollector",
"reason": "search_post_filter",
"time_in_nanos": 500850,
"children": [
{
"name": "SimpleTopScoreDocCollector",
"reason": "search_top_hits",
"time_in_nanos": 22577
}
]
},
{
"name": "MultiBucketCollector: [[my_scoped_agg, my_global_agg]]",
"reason": "aggregation",
"time_in_nanos": 867617
}
],
"aggregations": [...] <1>
}
]
]
}
]
}
],
"aggregations": [...] <1>
}
]
}
}
--------------------------------------------------
// TESTRESPONSE[s/"aggregations": \[\.\.\.\]/"aggregations": $body.$_path/]
// TESTRESPONSE[s/\.\.\.//]
// TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
// TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[test\]\[0\]"/"id": $body.profile.shards.0.id/]
// TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[my-index-000001\]\[0\]"/"id": $body.profile.shards.0.id/]
<1> The `"aggregations"` portion has been omitted because it will be covered in
the next section.
As you can see, the output is significantly more verbose than before. All the
major portions of the query are represented:
1. The first `TermQuery` (user:test) represents the main `term` query.
2. The second `TermQuery` (message:some) represents the `post_filter` query.
1. The first `TermQuery` (user.id:elkbee) represents the main `term` query.
2. The second `TermQuery` (message:search) represents the `post_filter` query.
The Collector tree is fairly straightforward, showing how a single
CancellableCollector wraps a MultiCollector which also wraps a FilteredCollector
@ -734,20 +735,20 @@ and look at the aggregation profile this time:
[source,console]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"profile": true,
"query": {
"term": {
"user": {
"value": "test"
"user.id": {
"value": "elkbee"
}
}
},
"aggs": {
"my_scoped_agg": {
"terms": {
"field": "likes"
"field": "http.response.status_code"
}
},
"my_global_agg": {
@ -755,7 +756,7 @@ GET /twitter/_search
"aggs": {
"my_level_agg": {
"terms": {
"field": "likes"
"field": "http.response.status_code"
}
}
}
@ -763,7 +764,7 @@ GET /twitter/_search
},
"post_filter": {
"match": {
"message": "some"
"message": "search"
}
}
}
@ -777,61 +778,61 @@ This yields the following aggregation profile output:
[source,console-result]
--------------------------------------------------
{
"profile" : {
"shards" : [
"profile": {
"shards": [
{
"aggregations" : [
"aggregations": [
{
"type" : "NumericTermsAggregator",
"description" : "my_scoped_agg",
"time_in_nanos" : 195386,
"breakdown" : {
"reduce" : 0,
"build_aggregation" : 81171,
"build_aggregation_count" : 1,
"initialize" : 22753,
"initialize_count" : 1,
"reduce_count" : 0,
"collect" : 91456,
"collect_count" : 4
"type": "NumericTermsAggregator",
"description": "my_scoped_agg",
"time_in_nanos": 79294,
"breakdown": {
"reduce": 0,
"build_aggregation": 30885,
"build_aggregation_count": 1,
"initialize": 2623,
"initialize_count": 1,
"reduce_count": 0,
"collect": 45786,
"collect_count": 4
},
"debug": {
"result_strategy": "long_terms",
"total_buckets": 4
"total_buckets": 1,
"result_strategy": "long_terms"
}
},
{
"type" : "GlobalAggregator",
"description" : "my_global_agg",
"time_in_nanos" : 190430,
"breakdown" : {
"reduce" : 0,
"build_aggregation" : 59990,
"build_aggregation_count" : 1,
"initialize" : 29619,
"initialize_count" : 1,
"reduce_count" : 0,
"collect" : 100815,
"collect_count" : 4
"type": "GlobalAggregator",
"description": "my_global_agg",
"time_in_nanos": 104325,
"breakdown": {
"reduce": 0,
"build_aggregation": 22470,
"build_aggregation_count": 1,
"initialize": 12454,
"initialize_count": 1,
"reduce_count": 0,
"collect": 69401,
"collect_count": 4
},
"children" : [
"children": [
{
"type" : "NumericTermsAggregator",
"description" : "my_level_agg",
"time_in_nanos" : 160329,
"breakdown" : {
"reduce" : 0,
"build_aggregation" : 55712,
"build_aggregation_count" : 1,
"initialize" : 10559,
"initialize_count" : 1,
"reduce_count" : 0,
"collect" : 94052,
"collect_count" : 4,
"type": "NumericTermsAggregator",
"description": "my_level_agg",
"time_in_nanos": 76876,
"breakdown": {
"reduce": 0,
"build_aggregation": 13824,
"build_aggregation_count": 1,
"initialize": 1441,
"initialize_count": 1,
"reduce_count": 0,
"collect": 61611,
"collect_count": 4
},
"debug": {
"result_strategy": "long_terms",
"total_buckets": 4
"total_buckets": 1,
"result_strategy": "long_terms"
}
}
]
@ -844,13 +845,13 @@ This yields the following aggregation profile output:
--------------------------------------------------
// TESTRESPONSE[s/\.\.\.//]
// TESTRESPONSE[s/(?<=[" ])\d+(\.\d+)?/$body.$_path/]
// TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[test\]\[0\]"/"id": $body.profile.shards.0.id/]
// TESTRESPONSE[s/"id": "\[P6-vulHtQRWuD4YnubWb7A\]\[my-index-000001\]\[0\]"/"id": $body.profile.shards.0.id/]
From the profile structure we can see that the `my_scoped_agg` is internally
being run as a `NumericTermsAggregator` (because the field it is aggregating,
`likes`, is a numeric field). At the same level, we see a `GlobalAggregator`
`http.response.status_code`, is a numeric field). At the same level, we see a `GlobalAggregator`
which comes from `my_global_agg`. That aggregation then has a child
`NumericTermsAggregator` which comes from the second term's aggregation on `likes`.
`NumericTermsAggregator` which comes from the second term's aggregation on `http.response.status_code`.
The `time_in_nanos` field shows the time executed by each aggregation, and is
inclusive of all children. While the overall time is useful, the `breakdown`
@ -870,14 +871,13 @@ The `breakdown` component lists detailed statistics about low-level execution:
--------------------------------------------------
"breakdown": {
"reduce": 0,
"build_aggregation": 30885,
"build_aggregation_count": 1,
"initialize": 2623,
"initialize_count": 1,
"reduce_count": 0,
"build_aggregation": 49765,
"build_aggregation_count": 300,
"initialize": 52785,
"initialize_count": 300,
"reduce_count": 0,
"collect": 3155490036,
"collect_count": 1800
"collect": 45786,
"collect_count": 4
}
--------------------------------------------------
// NOTCONSOLE

20
docs/reference/search/rank-eval.asciidoc
View File

@ -230,7 +230,7 @@ that contains one relevant result in position 1.
[source,console]
--------------------------------
GET /twitter/_rank_eval
GET /my-index-000001/_rank_eval
{
"requests": [
{
@ -247,7 +247,7 @@ GET /twitter/_rank_eval
}
}
--------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The `precision` metric takes the following optional parameters
@ -285,7 +285,7 @@ that contains one relevant result in position 1.
[source,console]
--------------------------------
GET /twitter/_rank_eval
GET /my-index-000001/_rank_eval
{
"requests": [
{
@ -301,7 +301,7 @@ GET /twitter/_rank_eval
}
}
--------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The `recall` metric takes the following optional parameters
@ -326,7 +326,7 @@ https://en.wikipedia.org/wiki/Mean_reciprocal_rank[mean reciprocal rank].
[source,console]
--------------------------------
GET /twitter/_rank_eval
GET /my-index-000001/_rank_eval
{
"requests": [
{
@ -342,7 +342,7 @@ GET /twitter/_rank_eval
}
}
--------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The `mean_reciprocal_rank` metric takes the following optional parameters
@ -370,7 +370,7 @@ the overall DCG metric.
[source,console]
--------------------------------
GET /twitter/_rank_eval
GET /my-index-000001/_rank_eval
{
"requests": [
{
@ -386,7 +386,7 @@ GET /twitter/_rank_eval
}
}
--------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The `dcg` metric takes the following optional parameters:
@ -426,7 +426,7 @@ for.
[source,console]
--------------------------------
GET /twitter/_rank_eval
GET /my-index-000001/_rank_eval
{
"requests": [
{
@ -442,7 +442,7 @@ GET /twitter/_rank_eval
}
}
--------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The `expected_reciprocal_rank` metric takes the following parameters:

10
docs/reference/search/request-body.asciidoc
View File

@ -5,14 +5,14 @@ Specifies search criteria as request body parameters.
[source,console]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"query" : {
"term" : { "user" : "kimchy" }
"term" : { "user.id" : "kimchy" }
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[[search-request-body-api-request]]
@ -63,9 +63,9 @@ matching document was found (per shard).
[source,console]
--------------------------------------------------
GET /_search?q=message:number&size=0&terminate_after=1
GET /_search?q=user.id:elkbee&size=0&terminate_after=1
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The response will not contain any hits as the `size` was set to `0`. The

102
docs/reference/search/request/collapse.asciidoc
View File

@ -3,29 +3,31 @@
You can use the `collapse` parameter to collapse search results based
on field values. The collapsing is done by selecting only the top sorted
document per collapse key. For instance the query below retrieves the best tweet
for each user and sorts them by number of likes.
document per collapse key.
For example, the following search collapses results by `user.id` and sorts them
by `http.response.bytes`.
[source,console]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"query": {
"match": {
"message": "elasticsearch"
"message": "GET /search"
}
},
"collapse": {
"field": "user" <1>
"field": "user.id" <1>
},
"sort": [ "likes" ], <2>
"from": 10 <3>
"sort": [ "http.response.bytes" ], <2>
"from": 10 <3>
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
<1> collapse the result set using the "user" field
<2> sort the top docs by number of likes
<1> Collapse the result set using the "user.id" field
<2> Sort the results by `http.response.bytes`
<3> define the offset of the first collapsed result
WARNING: The total number of hits in the response indicates the number of matching documents without collapsing.
@ -43,32 +45,32 @@ It is also possible to expand each collapsed top hits with the `inner_hits` opti
[source,console]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"query": {
"match": {
"message": "elasticsearch"
"message": "GET /search"
}
},
"collapse": {
"field": "user", <1>
"field": "user.id", <1>
"inner_hits": {
"name": "last_tweets", <2>
"size": 5, <3>
"sort": [ { "date": "asc" } ] <4>
"name": "most_recent", <2>
"size": 5, <3>
"sort": [ { "@timestamp": "asc" } ] <4>
},
"max_concurrent_group_searches": 4 <5>
"max_concurrent_group_searches": 4 <5>
},
"sort": [ "likes" ]
"sort": [ "http.response.bytes" ]
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
<1> collapse the result set using the "user" field
<1> collapse the result set using the "user.id" field
<2> the name used for the inner hit section in the response
<3> the number of inner_hits to retrieve per collapse key
<4> how to sort the document inside each group
<5> the number of concurrent requests allowed to retrieve the inner_hits` per group
<5> the number of concurrent requests allowed to retrieve the `inner_hits` per group
See <<request-body-search-inner-hits, inner hits>> for the complete list of supported options and the format of the response.
@ -77,36 +79,36 @@ multiple representations of the collapsed hits.
[source,console]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"query": {
"match": {
"message": "elasticsearch"
"message": "GET /search"
}
},
"collapse": {
"field": "user", <1>
"field": "user.id", <1>
"inner_hits": [
{
"name": "most_liked", <2>
"name": "largest_responses", <2>
"size": 3,
"sort": [ "likes" ]
"sort": [ "http.response.bytes" ]
},
{
"name": "most_recent", <3>
"name": "most_recent", <3>
"size": 3,
"sort": [ { "date": "asc" } ]
"sort": [ { "@timestamp": "asc" } ]
}
]
},
"sort": [ "likes" ]
"sort": [ "http.response.bytes" ]
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
<1> collapse the result set using the "user" field
<2> return the three most liked tweets for the user
<3> return the three most recent tweets for the user
<1> collapse the result set using the "user.id" field
<2> return the three largest HTTP responses for the user
<3> return the three most recent HTTP responses for the user
The expansion of the group is done by sending an additional query for each
`inner_hit` request for each collapsed hit returned in the response. This can significantly slow things down
@ -124,24 +126,24 @@ WARNING: `collapse` cannot be used in conjunction with <<scroll-search-results,
=== Second level of collapsing
Second level of collapsing is also supported and is applied to `inner_hits`.
For example, the following request finds the top scored tweets for
each country, and within each country finds the top scored tweets
for each user.
For example, the following search collapses results by `geo.country_name`.
Within each `geo.country_name`, inner hits are collapsed by `user.id`.
[source,js]
--------------------------------------------------
GET /twitter/_search
GET /my-index-000001/_search
{
"query": {
"match": {
"message": "elasticsearch"
"message": "GET /search"
}
},
"collapse": {
"field": "country",
"field": "geo.country_name",
"inner_hits": {
"name": "by_location",
"collapse": { "field": "user" },
"collapse": { "field": "user.id" },
"size": 3
}
}
@ -157,12 +159,12 @@ Response:
...
"hits": [
{
"_index": "twitter",
"_index": "my-index-000001",
"_type": "_doc",
"_id": "9",
"_score": ...,
"_source": {...},
"fields": { "country": [ "UK" ] },
"fields": { "geo": { "country_name": [ "UK" ] }},
"inner_hits": {
"by_location": {
"hits": {
@ -170,15 +172,15 @@ Response:
"hits": [
{
...
"fields": { "user": [ "user124" ] }
"fields": { "user": "id": { [ "user124" ] }}
},
{
...
"fields": { "user": [ "user589" ] }
"fields": { "user": "id": { [ "user589" ] }}
},
{
...
"fields": { "user": [ "user001" ] }
"fields": { "user": "id": { [ "user001" ] }}
}
]
}
@ -186,13 +188,13 @@ Response:
}
},
{
"_index": "twitter",
"_index": "my-index-000001",
"_type": "_doc",
"_id": "1",
"_score": ..,
"_source": {...
},
"fields": { "country": [ "Canada" ] },
"fields": { "geo": { "country_name": [ "Canada" ] }},
"inner_hits": {
"by_location": {
"hits": {
@ -200,15 +202,15 @@ Response:
"hits": [
{
...
"fields": { "user": [ "user444" ] }
"fields": { "user": "id": { [ "user444" ] }}
},
{
...
"fields": { "user": [ "user1111" ] }
"fields": { "user": "id": { [ "user1111" ] }
},
{
...
"fields": { "user": [ "user999" ] }
"fields": { "user": "id": { [ "user999" ] }}
}
]
}

78
docs/reference/search/request/highlighting.asciidoc
View File

@ -34,7 +34,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
{es} supports three highlighters: `unified`, `plain`, and `fvh` (fast vector
highlighter). You can specify the highlighter `type` you want to use
@ -286,7 +286,7 @@ individual fields.
GET /_search
{
"query" : {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight" : {
"number_of_fragments" : 3,
@ -300,7 +300,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[discrete]
[[specify-highlight-query]]
@ -369,7 +369,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[discrete]
[[set-highlighter-type]]
@ -384,7 +384,7 @@ The following is an example that forces the use of the plain highlighter:
GET /_search
{
"query": {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight": {
"fields": {
@ -393,7 +393,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[[configure-tags]]
[discrete]
@ -408,7 +408,7 @@ for example:
GET /_search
{
"query" : {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight" : {
"pre_tags" : ["<tag1>"],
@ -419,7 +419,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
When using the fast vector highlighter, you can specify additional tags and the
"importance" is ordered.
@ -429,7 +429,7 @@ When using the fast vector highlighter, you can specify additional tags and the
GET /_search
{
"query" : {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight" : {
"pre_tags" : ["<tag1>", "<tag2>"],
@ -440,7 +440,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
You can also use the built-in `styled` tag schema:
@ -449,7 +449,7 @@ You can also use the built-in `styled` tag schema:
GET /_search
{
"query" : {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight" : {
"tags_schema" : "styled",
@ -459,7 +459,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[discrete]
[[highlight-source]]
@ -473,7 +473,7 @@ are stored separately. Defaults to `false`.
GET /_search
{
"query" : {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight" : {
"fields" : {
@ -482,7 +482,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[[highlight-all]]
@ -497,7 +497,7 @@ By default, only fields that contains a query match are highlighted. Set
GET /_search
{
"query" : {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight" : {
"require_field_match": false,
@ -507,7 +507,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[[matched-fields]]
[discrete]
@ -546,7 +546,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The above matches both "run with scissors" and "running with scissors"
and would highlight "running" and "scissors" but not "run". If both
@ -575,7 +575,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The above highlights "run" as well as "running" and "scissors" but
still sorts "running with scissors" above "run with scissors" because
@ -602,7 +602,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The above query wouldn't highlight "run" or "scissor" but shows that
it is just fine not to list the field to which the matches are combined
@ -662,7 +662,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
None of the highlighters built into Elasticsearch care about the order that the
fields are highlighted but a plugin might.
@ -684,7 +684,7 @@ For example:
GET /_search
{
"query" : {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight" : {
"fields" : {
@ -693,7 +693,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
On top of this it is possible to specify that highlighted fragments need
to be sorted by score:
@ -703,7 +703,7 @@ to be sorted by score:
GET /_search
{
"query" : {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight" : {
"order" : "score",
@ -713,7 +713,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
If the `number_of_fragments` value is set to `0` then no fragments are
produced, instead the whole content of the field is returned, and of
@ -726,7 +726,7 @@ is required. Note that `fragment_size` is ignored in this case.
GET /_search
{
"query" : {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight" : {
"fields" : {
@ -736,7 +736,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
When using `fvh` one can use `fragment_offset`
parameter to control the margin to start highlighting from.
@ -752,7 +752,7 @@ specified as it tries to break on a word boundary.
GET /_search
{
"query": {
"match": { "user": "kimchy" }
"match": { "user.id": "kimchy" }
},
"highlight": {
"fields": {
@ -765,7 +765,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[discrete]
[[highlight-postings-list]]
@ -816,7 +816,7 @@ When using the `plain` highlighter, you can choose between the `simple` and
[source,console]
--------------------------------------------------
GET twitter/_search
GET my-index-000001/_search
{
"query": {
"match_phrase": { "message": "number 1" }
@ -833,7 +833,7 @@ GET twitter/_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
Response:
@ -849,15 +849,12 @@ Response:
"max_score": 1.6011951,
"hits": [
{
"_index": "twitter",
"_index": "my-index-000001",
"_type": "_doc",
"_id": "1",
"_score": 1.6011951,
"_source": {
"user": "test",
"message": "some message with the number 1",
"date": "2009-11-15T14:12:12",
"likes": 1
"message": "some message with the number 1"
},
"highlight": {
"message": [
@ -874,7 +871,7 @@ Response:
[source,console]
--------------------------------------------------
GET twitter/_search
GET my-index-000001/_search
{
"query": {
"match_phrase": { "message": "number 1" }
@ -891,7 +888,7 @@ GET twitter/_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
Response:
@ -907,15 +904,12 @@ Response:
"max_score": 1.6011951,
"hits": [
{
"_index": "twitter",
"_index": "my-index-000001",
"_type": "_doc",
"_id": "1",
"_score": 1.6011951,
"_source": {
"user": "test",
"message": "some message with the number 1",
"date": "2009-11-15T14:12:12",
"likes": 1
"message": "some message with the number 1"
},
"highlight": {
"message": [

6
docs/reference/search/request/rescore.asciidoc
View File

@ -68,7 +68,7 @@ POST /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The way the scores are combined can be controlled with the `score_mode`:
[cols="<,<",options="header",]
@ -120,7 +120,7 @@ POST /_search
"function_score" : {
"script_score": {
"script": {
"source": "Math.log10(doc.likes.value + 2)"
"source": "Math.log10(doc.count.value + 2)"
}
}
}
@ -129,7 +129,7 @@ POST /_search
} ]
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The first one gets the results of the query then the second one gets the
results of the first, etc. The second rescore will "see" the sorting done

2
docs/reference/search/request/script-fields.asciidoc
View File

@ -54,7 +54,7 @@ GET /_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
Note the `_source` keyword here to navigate the json-like model.

26
docs/reference/search/request/scroll.asciidoc
View File

@ -44,17 +44,17 @@ should keep the ``search context'' alive (see <<scroll-search-context>>), eg `?s
[source,console]
--------------------------------------------------
POST /twitter/_search?scroll=1m
POST /my-index-000001/_search?scroll=1m
{
"size": 100,
"query": {
"match": {
"title": "elasticsearch"
"message": "foo"
}
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
The result from the above request includes a `_scroll_id`, which should
be passed to the `scroll` API in order to retrieve the next batch of
@ -101,7 +101,7 @@ GET /_search?scroll=1m
]
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[discrete]
[[scroll-search-context]]
@ -209,7 +209,7 @@ can be consumed independently:
[source,console]
--------------------------------------------------
GET /twitter/_search?scroll=1m
GET /my-index-000001/_search?scroll=1m
{
"slice": {
"id": 0, <1>
@ -217,11 +217,11 @@ GET /twitter/_search?scroll=1m
},
"query": {
"match": {
"title": "elasticsearch"
"message": "foo"
}
}
}
GET /twitter/_search?scroll=1m
GET /my-index-000001/_search?scroll=1m
{
"slice": {
"id": 1,
@ -229,12 +229,12 @@ GET /twitter/_search?scroll=1m
},
"query": {
"match": {
"title": "elasticsearch"
"message": "foo"
}
}
}
--------------------------------------------------
// TEST[setup:big_twitter]
// TEST[setup:my_index_big]
<1> The id of the slice
<2> The maximum number of slices
@ -271,21 +271,21 @@ slice gets deterministic results.
[source,console]
--------------------------------------------------
GET /twitter/_search?scroll=1m
GET /my-index-000001/_search?scroll=1m
{
"slice": {
"field": "date",
"field": "@timestamp",
"id": 0,
"max": 10
},
"query": {
"match": {
"title": "elasticsearch"
"message": "foo"
}
}
}
--------------------------------------------------
// TEST[setup:big_twitter]
// TEST[setup:my_index_big]
For append only time-based indices, the `timestamp` field can be used safely.

16
docs/reference/search/request/search-after.asciidoc
View File

@ -13,21 +13,21 @@ Suppose that the query to retrieve the first page looks like this:
[source,console]
--------------------------------------------------
GET twitter/_search
GET my-index-000001/_search
{
"size": 10,
"query": {
"match" : {
"title" : "elasticsearch"
"message" : "foo"
}
},
"sort": [
{"date": "asc"},
{"@timestamp": "asc"},
{"tie_breaker_id": "asc"} <1>
]
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
// TEST[s/"tie_breaker_id": "asc"/"tie_breaker_id": {"unmapped_type": "keyword"}/]
<1> A copy of the `_id` field with `doc_values` enabled
@ -56,22 +56,22 @@ For instance we can use the `sort values` of the last document and pass it to `s
[source,console]
--------------------------------------------------
GET twitter/_search
GET my-index-000001/_search
{
"size": 10,
"query": {
"match" : {
"title" : "elasticsearch"
"message" : "foo"
}
},
"search_after": [1463538857, "654323"],
"sort": [
{"date": "asc"},
{"@timestamp": "asc"},
{"tie_breaker_id": "asc"}
]
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
// TEST[s/"tie_breaker_id": "asc"/"tie_breaker_id": {"unmapped_type": "keyword"}/]
NOTE: The parameter `from` must be set to 0 (or -1) when `search_after` is used.

8
docs/reference/search/request/search-type.asciidoc
View File

@ -52,9 +52,9 @@ shards*.
[source,console]
--------------------------------------------------
GET twitter/_search?search_type=query_then_fetch
GET my-index-000001/_search?search_type=query_then_fetch
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
NOTE: This is the default setting, if you do not specify a `search_type`
in your request.
@ -70,6 +70,6 @@ scoring.
[source,console]
--------------------------------------------------
GET twitter/_search?search_type=dfs_query_then_fetch
GET my-index-000001/_search?search_type=dfs_query_then_fetch
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]

14
docs/reference/search/request/track-total-hits.asciidoc
View File

@ -21,17 +21,17 @@ that `"total.value"` is the accurate count.
[source,console]
--------------------------------------------------
GET twitter/_search
GET my-index-000001/_search
{
"track_total_hits": true,
"query": {
"match" : {
"message" : "Elasticsearch"
"user.id" : "elkbee"
}
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
\... returns:
@ -66,12 +66,12 @@ the query up to 100 documents:
[source,console]
--------------------------------------------------
GET twitter/_search
GET my-index-000001/_search
{
"track_total_hits": 100,
"query": {
"match": {
"message": "Elasticsearch"
"user.id": "elkbee"
}
}
}
@ -140,12 +140,12 @@ times by setting this option to `false`:
[source,console]
--------------------------------------------------
GET twitter/_search
GET my-index-000001/_search
{
"track_total_hits": false,
"query": {
"match": {
"message": "Elasticsearch"
"user.id": "elkbee"
}
}
}

2
docs/reference/search/scroll-api.asciidoc
View File

@ -18,7 +18,7 @@ GET /_search?scroll=1m
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
////
[source,console]

54
docs/reference/search/search-fields.asciidoc
View File

@ -9,18 +9,18 @@ response, you can use the `fields` parameter:
[source,console]
----
POST twitter/_search
POST my-index-000001/_search
{
"query": {
"match": {
"message": "elasticsearch"
"message": "foo"
}
},
"fields": ["user", "date"],
"fields": ["user.id", "@timestamp"],
"_source": false
}
----
// TEST[setup:twitter]
// TEST[setup:my_index]
The `fields` parameter consults both a document's `_source` and the index
mappings to load and return values. Because it makes use of the mappings,
@ -60,30 +60,30 @@ type. By default, date fields are formatted according to the
<<mapping-date-format,date format>> parameter in their mappings.
The following search request uses the `fields` parameter to retrieve values
for the `user` field, all fields starting with `location.`, and the
`date` field:
for the `user.id` field, all fields starting with `http.response.`, and the
`@timestamp` field:
[source,console]
----
POST twitter/_search
POST my-index-000001/_search
{
"query": {
"match": {
"message": "elasticsearch"
"user.id": "kimchy"
}
},
"fields": [
"user",
"location.*", <1>
"user.id",
"http.response.*", <1>
{
"field": "date",
"field": "@timestamp",
"format": "epoch_millis" <2>
}
],
"_source": false
}
----
// TEST[continued]
// TEST[setup:my_index]
<1> Both full field names and wildcard patterns are accepted.
<2> Using object notation, you can pass a `format` parameter to apply a custom
@ -116,22 +116,22 @@ The values are returned as a flat list in the `fields` section in each hit:
"max_score" : 1.0,
"hits" : [
{
"_index" : "twitter",
"_index" : "my-index-000001",
"_id" : "0",
"_score" : 1.0,
"_type" : "_doc",
"fields" : {
"user" : [
"user.id" : [
"kimchy"
],
"date" : [
"1258294332000"
"@timestamp" : [
"4098435132000"
],
"location.city": [
"Amsterdam"
"http.response.bytes": [
1070000
],
"location.country": [
"Netherlands"
"http.response.status_code": [
200
]
}
}
@ -178,21 +178,21 @@ not supported for <<text,`text`>> or
{plugins}/mapper-annotated-text-usage.html[`text_annotated`] fields.
The following search request uses the `docvalue_fields` parameter to retrieve
doc values for the `user` field, all fields starting with `location.`, and the
`date` field:
doc values for the `user.id` field, all fields starting with `http.response.`, and the
`@timestamp` field:
[source,console]
----
GET twitter/_search
GET my-index-000001/_search
{
"query": {
"match": {
"message": "elasticsearch"
"user.id": "kimchy"
}
},
"docvalue_fields": [
"user",
"location.*", <1>
"user.id",
"http.response.*", <1>
{
"field": "date",
"format": "epoch_millis" <2>
@ -200,7 +200,7 @@ GET twitter/_search
]
}
----
// TEST[continued]
// TEST[setup:my_index]
<1> Both full field names and wildcard patterns are accepted.
<2> Using object notation, you can pass a `format` parameter to apply a custom

30
docs/reference/search/search-shards.asciidoc
View File

@ -5,9 +5,9 @@ Returns the indices and shards that a search request would be executed against.
[source,console]
--------------------------------------------------
GET /twitter/_search_shards
GET /my-index-000001/_search_shards
--------------------------------------------------
// TEST[s/^/PUT twitter\n{"settings":{"index.number_of_shards":5}}\n/]
// TEST[s/^/PUT my-index-000001\n{"settings":{"index.number_of_shards":5}}\n/]
[[search-shards-api-request]]
@ -58,9 +58,9 @@ include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=routing]
[source,console]
--------------------------------------------------
GET /twitter/_search_shards
GET /my-index-000001/_search_shards
--------------------------------------------------
// TEST[s/^/PUT twitter\n{"settings":{"index.number_of_shards":5}}\n/]
// TEST[s/^/PUT my-index-000001\n{"settings":{"index.number_of_shards":5}}\n/]
The API returns the following result:
@ -69,12 +69,12 @@ The API returns the following result:
{
"nodes": ...,
"indices" : {
"twitter": { }
"my-index-000001": { }
},
"shards": [
[
{
"index": "twitter",
"index": "my-index-000001",
"node": "JklnKbD7Tyqi9TP3_Q_tBg",
"primary": true,
"shard": 0,
@ -85,7 +85,7 @@ The API returns the following result:
],
[
{
"index": "twitter",
"index": "my-index-000001",
"node": "JklnKbD7Tyqi9TP3_Q_tBg",
"primary": true,
"shard": 1,
@ -96,7 +96,7 @@ The API returns the following result:
],
[
{
"index": "twitter",
"index": "my-index-000001",
"node": "JklnKbD7Tyqi9TP3_Q_tBg",
"primary": true,
"shard": 2,
@ -107,7 +107,7 @@ The API returns the following result:
],
[
{
"index": "twitter",
"index": "my-index-000001",
"node": "JklnKbD7Tyqi9TP3_Q_tBg",
"primary": true,
"shard": 3,
@ -118,7 +118,7 @@ The API returns the following result:
],
[
{
"index": "twitter",
"index": "my-index-000001",
"node": "JklnKbD7Tyqi9TP3_Q_tBg",
"primary": true,
"shard": 4,
@ -142,9 +142,9 @@ Specifying the same request, this time with a routing value:
[source,console]
--------------------------------------------------
GET /twitter/_search_shards?routing=foo,bar
GET /my-index-000001/_search_shards?routing=foo,bar
--------------------------------------------------
// TEST[s/^/PUT twitter\n{"settings":{"index.number_of_shards":5}}\n/]
// TEST[s/^/PUT my-index-000001\n{"settings":{"index.number_of_shards":5}}\n/]
The API returns the following result:
@ -153,12 +153,12 @@ The API returns the following result:
{
"nodes": ...,
"indices" : {
"twitter": { }
"my-index-000001": { }
},
"shards": [
[
{
"index": "twitter",
"index": "my-index-000001",
"node": "JklnKbD7Tyqi9TP3_Q_tBg",
"primary": true,
"shard": 2,
@ -169,7 +169,7 @@ The API returns the following result:
],
[
{
"index": "twitter",
"index": "my-index-000001",
"node": "JklnKbD7Tyqi9TP3_Q_tBg",
"primary": true,
"shard": 3,

6
docs/reference/search/search-template.asciidoc
View File

@ -13,12 +13,12 @@ GET _search/template
},
"params" : {
"my_field" : "message",
"my_value" : "some message",
"my_value" : "foo",
"my_size" : 5
}
}
------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[[search-template-api-request]]
==== {api-request-title}
@ -306,7 +306,7 @@ GET _search/template
}
}
------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[[search-template-converting-to-json]]
===== Converting parameters to JSON

10
docs/reference/search/suggesters.asciidoc
View File

@ -6,7 +6,7 @@ Parts of the suggest feature are still under development.
[source,console]
--------------------------------------------------
POST twitter/_search
POST my-index-000001/_search
{
"query" : {
"match": {
@ -23,7 +23,7 @@ POST twitter/_search
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
[[search-suggesters-api-request]]
@ -61,14 +61,14 @@ POST _search
"my-suggest-2" : {
"text" : "kmichy",
"term" : {
"field" : "user"
"field" : "user.id"
}
}
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
// TEST[s/^/PUT my-index-000001\/_mapping\n{"properties":{"user":{"properties":{"id":{"type":"keyword"}}}}}\n/]
The below suggest response example includes the suggestion response for
`my-suggest-1` and `my-suggest-2`. Each suggestion part contains

2
docs/reference/search/suggesters/misc.asciidoc
View File

@ -25,7 +25,7 @@ POST _search?typed_keys
}
}
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:messages]
In the response, the suggester names will be changed to respectively `term#my-first-suggester` and
`phrase#my-second-suggester`, reflecting the types of each suggestion:

46
docs/reference/search/validate.asciidoc
View File

@ -5,9 +5,9 @@ Validates a potentially expensive query without executing it.
[source,console]
--------------------------------------------------
GET twitter/_validate/query?q=user:foo
GET my-index-000001/_validate/query?q=user.id:kimchy
--------------------------------------------------
// TEST[setup:twitter]
// TEST[setup:my_index]
[[search-validate-api-request]]
@ -79,11 +79,11 @@ include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=search-q]
[source,console]
--------------------------------------------------
PUT twitter/_bulk?refresh
PUT my-index-000001/_bulk?refresh
{"index":{"_id":1}}
{"user" : "kimchy", "post_date" : "2009-11-15T14:12:12", "message" : "trying out Elasticsearch"}
{"user" : { "id": "kimchy" }, "@timestamp" : "2099-11-15T14:12:12", "message" : "trying out Elasticsearch"}
{"index":{"_id":2}}
{"user" : "kimchi", "post_date" : "2009-11-15T14:12:13", "message" : "My username is similar to @kimchy!"}
{"user" : { "id": "kimchi" }, "@timestamp" : "2099-11-15T14:12:13", "message" : "My user ID is similar to kimchy!"}
--------------------------------------------------
@ -91,7 +91,7 @@ When sent a valid query:
[source,console]
--------------------------------------------------
GET twitter/_validate/query?q=user:foo
GET my-index-000001/_validate/query?q=user.id:kimchy
--------------------------------------------------
// TEST[continued]
@ -108,7 +108,7 @@ The query may also be sent in the request body:
[source,console]
--------------------------------------------------
GET twitter/_validate/query
GET my-index-000001/_validate/query
{
"query" : {
"bool" : {
@ -118,7 +118,7 @@ GET twitter/_validate/query
}
},
"filter" : {
"term" : { "user" : "kimchy" }
"term" : { "user.id" : "kimchy" }
}
}
}
@ -135,11 +135,11 @@ mapping, and 'foo' does not correctly parse into a date:
[source,console]
--------------------------------------------------
GET twitter/_validate/query
GET my-index-000001/_validate/query
{
"query": {
"query_string": {
"query": "post_date:foo",
"query": "@timestamp:foo",
"lenient": false
}
}
@ -159,11 +159,11 @@ why a query failed:
[source,console]
--------------------------------------------------
GET twitter/_validate/query?explain=true
GET my-index-000001/_validate/query?explain=true
{
"query": {
"query_string": {
"query": "post_date:foo",
"query": "@timestamp:foo",
"lenient": false
}
}
@ -184,9 +184,9 @@ The API returns the following response:
"failed" : 0
},
"explanations" : [ {
"index" : "twitter",
"index" : "my-index-000001",
"valid" : false,
"error" : "twitter/IAEc2nIXSSunQA_suI0MLw] QueryShardException[failed to create query:...failed to parse date field [foo]"
"error" : "my-index-000001/IAEc2nIXSSunQA_suI0MLw] QueryShardException[failed to create query:...failed to parse date field [foo]"
} ]
}
--------------------------------------------------
@ -200,7 +200,7 @@ showing the actual Lucene query that will be executed.
[source,console]
--------------------------------------------------
GET twitter/_validate/query?rewrite=true
GET my-index-000001/_validate/query?rewrite=true
{
"query": {
"more_like_this": {
@ -228,7 +228,7 @@ The API returns the following response:
},
"explanations": [
{
"index": "twitter",
"index": "my-index-000001",
"valid": true,
"explanation": "((user:terminator^3.71334 plot:future^2.763601 plot:human^2.8415773 plot:sarah^3.4193945 plot:kyle^3.8244398 plot:cyborg^3.9177752 plot:connor^4.040236 plot:reese^4.7133346 ... )~6) -ConstantScore(_id:2)) #(ConstantScore(_type:_doc))^0.0"
}
@ -248,21 +248,21 @@ all available shards.
////
[source,console]
--------------------------------------------------
PUT twitter/_bulk?refresh
PUT my-index-000001/_bulk?refresh
{"index":{"_id":1}}
{"user" : "kimchy", "post_date" : "2009-11-15T14:12:12", "message" : "trying out Elasticsearch"}
{"user" : { "id": "kimchy" }, "@timestamp" : "2099-11-15T14:12:12", "message" : "trying out Elasticsearch"}
{"index":{"_id":2}}
{"user" : "kimchi", "post_date" : "2009-11-15T14:12:13", "message" : "My username is similar to @kimchy!"}
{"user" : { "id": "kimchi" }, "@timestamp" : "2099-11-15T14:12:13", "message" : "My user ID is similar to kimchy!"}
--------------------------------------------------
////
[source,console]
--------------------------------------------------
GET twitter/_validate/query?rewrite=true&all_shards=true
GET my-index-000001/_validate/query?rewrite=true&all_shards=true
{
"query": {
"match": {
"user": {
"user.id": {
"query": "kimchy",
"fuzziness": "auto"
}
@ -285,10 +285,10 @@ The API returns the following response:
},
"explanations": [
{
"index": "twitter",
"index": "my-index-000001",
"shard": 0,
"valid": true,
"explanation": "(user:kimchi)^0.8333333 user:kimchy"
"explanation": "(user.id:kimchi)^0.8333333 user.id:kimchy"
}
]
}