92 lines
3.6 KiB
Plaintext
92 lines
3.6 KiB
Plaintext
[[breaking_50_suggester]]
|
|
=== Suggester changes
|
|
|
|
The completion suggester has undergone a complete rewrite. This means that the
|
|
syntax and data structure for fields of type `completion` have changed, as
|
|
have the syntax and response of completion suggester requests.
|
|
|
|
For indices created before Elasticsearch 5.0.0, `completion` fields and the
|
|
completion suggester will continue to work as they did in Elasticsearch 2.x.
|
|
However, it is not possible to run a completion suggester query across indices
|
|
created in 2.x and indices created in 5.x.
|
|
|
|
It is strongly recommended to reindex indices containing 2.x `completion`
|
|
fields in 5.x to take advantage of the new features listed below.
|
|
|
|
NOTE: You will need to change the structure of the completion field values
|
|
when reindexing.
|
|
|
|
==== Completion suggester is near-real time
|
|
|
|
Previously, deleted suggestions could be included in results even
|
|
after refreshing an index. Now, deletions are visible in near-real
|
|
time, i.e. as soon as the index has been refreshed. This applies
|
|
to suggestion entries for both context and completion suggesters.
|
|
|
|
==== Completion suggester is document-oriented
|
|
|
|
Suggestions are aware of the document they belong to. This enables
|
|
retrieving any field value from the document. This is exposed
|
|
through the query-time `payload` option in `completion` and `context`
|
|
suggesters:
|
|
|
|
[source,sh]
|
|
---------------
|
|
GET /my_index/_search
|
|
{
|
|
"suggest": {
|
|
"fooSuggestion": {
|
|
"text": "f"
|
|
"completion": {
|
|
"field": "fooSuggest",
|
|
"payload": ["field1", "field2"]
|
|
}
|
|
}
|
|
}
|
|
}
|
|
---------------
|
|
|
|
Previously, `context` and `completion` suggesters supported an index-time
|
|
`payloads` option, which was used to store and return metadata with suggestions.
|
|
Now metadata can be stored as a field in the same document as the
|
|
suggestion for enabling retrieval at query-time. The support for
|
|
index-time `payloads` has been removed to avoid bloating the in-memory
|
|
index with suggestion metadata. The time that it takes to retrieve payloads
|
|
depends heavily on the size of the `_source` field. The smaller the `_source`,
|
|
the faster the retrieval.
|
|
|
|
==== Simpler completion indexing
|
|
|
|
As suggestions are document-oriented, suggestion metadata (e.g. `output`)
|
|
should now be specified as a field in the document. The support for specifying
|
|
`output` when indexing suggestion entries has been removed. Now suggestion
|
|
result entry's `text` is always the un-analyzed value of the suggestion's
|
|
`input` (same as not specifying `output` while indexing suggestions in pre-5.0
|
|
indices).
|
|
|
|
==== Completion mapping with multiple contexts
|
|
|
|
The `context` option in `completion` field mapping is now an array to support
|
|
multiple named contexts per completion field. Note that this is sugar for
|
|
indexing same suggestions under different name with different contexts.
|
|
The `default` option for a named `context` has been removed. Now querying with
|
|
no `context` against a context-enabled completion field yields results from all
|
|
indexed suggestions. Note that performance for match-all-context query
|
|
degrades with the number of unique context value for a given `completion` field.
|
|
|
|
==== Completion suggestion with multiple context filtering
|
|
|
|
Previously `context` option in a suggest request was used for filtering suggestions
|
|
by `context` value. Now, the option has been named to `contexts` to specify
|
|
multiple named context filters. Note that this is not supported by pre-5.0 indices.
|
|
Following is the `contexts` snippet for a suggest query filtered by both 'color'
|
|
and 'location' contexts:
|
|
|
|
[source,sh]
|
|
---------------
|
|
"contexts": {
|
|
"color": [ {...} ],
|
|
"location": [ {...} ]
|
|
}
|
|
---------------
|