867 lines
26 KiB
Plaintext
867 lines
26 KiB
Plaintext
[[search-request-highlighting]]
|
|
=== Highlighting
|
|
|
|
Highlighters allow you to produce highlighted snippets from one or more fields
|
|
in your search results.
|
|
The following is an example of the search request body:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "content": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"fields" : {
|
|
"comment" : {}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
In the above case, the `comment` field will be highlighted for each
|
|
search hit (there will be another element in each search hit, called
|
|
`highlight`, which includes the highlighted fields and the highlighted
|
|
fragments).
|
|
|
|
[NOTE]
|
|
==================================
|
|
In order to perform highlighting, the actual content of the field is
|
|
required. If the field in question is stored (has `store` set to `true`
|
|
in the mapping) it will be used, otherwise, the actual `_source` will
|
|
be loaded and the relevant field will be extracted from it.
|
|
|
|
The `_all` field cannot be extracted from `_source`, so it can only
|
|
be used for highlighting if it mapped to have `store` set to `true`.
|
|
==================================
|
|
|
|
The field name supports wildcard notation. For example, using `comment_*`
|
|
will cause all <<text,text>> and <<keyword,keyword>> fields (and <<string,string>>
|
|
from versions before 5.0) that match the expression to be highlighted.
|
|
Note that all other fields will not be highlighted. If you use a custom mapper and want to
|
|
highlight on a field anyway, you have to provide the field name explicitly.
|
|
|
|
[[unified-highlighter]]
|
|
==== Unified Highlighter
|
|
|
|
The unified highlighter (which is used by default if no highlighter type is specified)
|
|
uses the Lucene Unified Highlighter.
|
|
This highlighter breaks the text into sentences and scores individual sentences as
|
|
if they were documents in this corpus, using the BM25 algorithm.
|
|
It also supports accurate phrase and multi-term (fuzzy, prefix, regex) highlighting.
|
|
|
|
===== Offsets Strategy
|
|
|
|
In order to create meaningful search snippets from the terms being queried,
|
|
a highlighter needs to know the start and end character offsets of each word
|
|
in the original text.
|
|
These offsets can be obtained from:
|
|
|
|
* The postings list (fields mapped as "index_options": "offsets").
|
|
* Term vectors (fields mapped as "term_vectors": "with_positions_offsets").
|
|
* The original field, by reanalysing the text on-the-fly.
|
|
|
|
====== Plain highlighting
|
|
|
|
This mode is picked when there is no other alternative.
|
|
It creates a tiny in-memory index and re-runs the original query criteria through
|
|
Lucene's query execution planner to get access to low-level match information on the current document.
|
|
This is repeated for every field and every document that needs highlighting.
|
|
|
|
====== Postings
|
|
|
|
If `index_options` is set to `offsets` in the mapping the `unified` highlighter
|
|
will use this information to highlight documents without re-analyzing the text.
|
|
It re-runs the original query directly on the postings and extracts the matching offsets
|
|
directly from the index limiting the collection to the highlighted documents.
|
|
This mode is faster on large fields since it doesn't require to reanalyze the text to be highlighted
|
|
and requires less disk space than term_vectors, needed for the fast vector
|
|
highlighting.
|
|
|
|
Here is an example of setting the `comment` field in the index mapping to allow for
|
|
highlighting using the postings:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT /example
|
|
{
|
|
"mappings": {
|
|
"doc" : {
|
|
"properties": {
|
|
"comment" : {
|
|
"type": "text",
|
|
"index_options" : "offsets"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
====== Term Vectors
|
|
|
|
If `term_vector` information is provided by setting `term_vector` to
|
|
`with_positions_offsets` in the mapping then the `unified` highlighter
|
|
will automatically use the `term_vector` to highlight the field.
|
|
The `term_vector` highlighting is faster to highlight multi-term queries like
|
|
`prefix` or `wildcard` because it can access the dictionary of term for each document
|
|
but it is also usually more costly than using the `postings` directly.
|
|
|
|
Here is an example of setting the `comment` field to allow for
|
|
highlighting using the `term_vectors` (this will cause the index to be bigger):
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT /example
|
|
{
|
|
"mappings": {
|
|
"doc" : {
|
|
"properties": {
|
|
"comment" : {
|
|
"type": "text",
|
|
"term_vector" : "with_positions_offsets"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
[[plain-highlighter]]
|
|
==== Plain highlighter
|
|
|
|
This highlighter of type `plain` uses the standard Lucene highlighter.
|
|
It tries hard to reflect the query matching logic in terms of understanding word importance and any word positioning criteria in phrase queries.
|
|
|
|
[WARNING]
|
|
If you want to highlight a lot of fields in a lot of documents with complex queries this highlighter will not be fast.
|
|
In its efforts to accurately reflect query logic it creates a tiny in-memory index and re-runs the original query criteria through
|
|
Lucene's query execution planner to get access to low-level match information on the current document.
|
|
This is repeated for every field and every document that needs highlighting. If this presents a performance issue in your system consider using an alternative highlighter.
|
|
|
|
[[fast-vector-highlighter]]
|
|
==== Fast vector highlighter
|
|
|
|
This highlighter of type `fvh` uses the Lucene Fast Vector highlighter.
|
|
This highlighter can be used on fields with `term_vector` set to
|
|
`with_positions_offsets` in the mapping.
|
|
The fast vector highlighter:
|
|
|
|
* Is faster especially for large fields (> `1MB`)
|
|
* Can be customized with `boundary_scanner` (see <<boundary-scanners,below>>)
|
|
* Requires setting `term_vector` to `with_positions_offsets` which
|
|
increases the size of the index
|
|
* Can combine matches from multiple fields into one result. See
|
|
`matched_fields`
|
|
* Can assign different weights to matches at different positions allowing
|
|
for things like phrase matches being sorted above term matches when
|
|
highlighting a Boosting Query that boosts phrase matches over term matches
|
|
|
|
Here is an example of setting the `comment` field to allow for
|
|
highlighting using the fast vector highlighter on it (this will cause
|
|
the index to be bigger):
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT /example
|
|
{
|
|
"mappings": {
|
|
"doc" : {
|
|
"properties": {
|
|
"comment" : {
|
|
"type": "text",
|
|
"term_vector" : "with_positions_offsets"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
==== Force highlighter type
|
|
|
|
The `type` field allows to force a specific highlighter type.
|
|
The allowed values are: `unified`, `plain` and `fvh`.
|
|
The following is an example that forces the use of the plain highlighter:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"fields" : {
|
|
"comment" : {"type" : "plain"}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
==== Force highlighting on source
|
|
|
|
Forces the highlighting to highlight fields based on the source even if fields are
|
|
stored separately. Defaults to `false`.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"fields" : {
|
|
"comment" : {"force_source" : true}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
[[tags]]
|
|
==== Highlighting Tags
|
|
|
|
By default, the highlighting will wrap highlighted text in `<em>` and
|
|
`</em>`. This can be controlled by setting `pre_tags` and `post_tags`,
|
|
for example:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"pre_tags" : ["<tag1>"],
|
|
"post_tags" : ["</tag1>"],
|
|
"fields" : {
|
|
"_all" : {}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
Using the fast vector highlighter there can be more tags, and the "importance"
|
|
is ordered.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"pre_tags" : ["<tag1>", "<tag2>"],
|
|
"post_tags" : ["</tag1>", "</tag2>"],
|
|
"fields" : {
|
|
"_all" : {}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
There are also built in "tag" schemas, with currently a single schema
|
|
called `styled` with the following `pre_tags`:
|
|
|
|
[source,html]
|
|
--------------------------------------------------
|
|
<em class="hlt1">, <em class="hlt2">, <em class="hlt3">,
|
|
<em class="hlt4">, <em class="hlt5">, <em class="hlt6">,
|
|
<em class="hlt7">, <em class="hlt8">, <em class="hlt9">,
|
|
<em class="hlt10">
|
|
--------------------------------------------------
|
|
|
|
and `</em>` as `post_tags`. If you think of more nice to have built in tag
|
|
schemas, just send an email to the mailing list or open an issue. Here
|
|
is an example of switching tag schemas:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"tags_schema" : "styled",
|
|
"fields" : {
|
|
"comment" : {}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
==== Encoder
|
|
|
|
An `encoder` parameter can be used to define how highlighted text will
|
|
be encoded. It can be either `default` (no encoding) or `html` (will
|
|
escape html, if you use html highlighting tags).
|
|
|
|
==== Highlighted Fragments
|
|
|
|
Each field highlighted can control the size of the highlighted fragment
|
|
in characters (defaults to `100`), and the maximum number of fragments
|
|
to return (defaults to `5`).
|
|
For example:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"fields" : {
|
|
"comment" : {"fragment_size" : 150, "number_of_fragments" : 3}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
On top of this it is possible to specify that highlighted fragments need
|
|
to be sorted by score:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"order" : "score",
|
|
"fields" : {
|
|
"comment" : {"fragment_size" : 150, "number_of_fragments" : 3}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
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
|
|
course it is highlighted. This can be very handy if short texts (like
|
|
document title or address) need to be highlighted but no fragmentation
|
|
is required. Note that `fragment_size` is ignored in this case.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"fields" : {
|
|
"_all" : {},
|
|
"blog.title" : {"number_of_fragments" : 0}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
When using `fvh` one can use `fragment_offset`
|
|
parameter to control the margin to start highlighting from.
|
|
|
|
In the case where there is no matching fragment to highlight, the default is
|
|
to not return anything. Instead, we can return a snippet of text from the
|
|
beginning of the field by setting `no_match_size` (default `0`) to the length
|
|
of the text that you want returned. The actual length may be shorter or longer than
|
|
specified as it tries to break on a word boundary.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"fields" : {
|
|
"comment" : {
|
|
"fragment_size" : 150,
|
|
"number_of_fragments" : 3,
|
|
"no_match_size": 150
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
==== Fragmenter
|
|
|
|
WARNING: This option is not supported by the `unified` highlighter
|
|
|
|
Fragmenter can control how text should be broken up in highlight snippets.
|
|
However, this option is applicable only for the Plain Highlighter.
|
|
There are two options:
|
|
|
|
[horizontal]
|
|
`simple`:: Breaks up text into same sized fragments.
|
|
`span`:: Same as the simple fragmenter, but tries not to break up text between highlighted terms (this is applicable when using phrase like queries). This is the default.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET twitter/tweet/_search
|
|
{
|
|
"query" : {
|
|
"match_phrase": { "message": "number 1" }
|
|
},
|
|
"highlight" : {
|
|
"fields" : {
|
|
"message" : {
|
|
"type": "plain",
|
|
"fragment_size" : 15,
|
|
"number_of_fragments" : 3,
|
|
"fragmenter": "simple"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
Response:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
{
|
|
...
|
|
"hits": {
|
|
"total": 1,
|
|
"max_score": 1.4818809,
|
|
"hits": [
|
|
{
|
|
"_index": "twitter",
|
|
"_type": "tweet",
|
|
"_id": "1",
|
|
"_score": 1.4818809,
|
|
"_source": {
|
|
"user": "test",
|
|
"message": "some message with the number 1",
|
|
"date": "2009-11-15T14:12:12",
|
|
"likes": 1
|
|
},
|
|
"highlight": {
|
|
"message": [
|
|
" with the <em>number</em>",
|
|
" <em>1</em>"
|
|
]
|
|
}
|
|
}
|
|
]
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// TESTRESPONSE[s/\.\.\./"took": $body.took,"timed_out": false,"_shards": $body._shards,/]
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET twitter/tweet/_search
|
|
{
|
|
"query" : {
|
|
"match_phrase": { "message": "number 1" }
|
|
},
|
|
"highlight" : {
|
|
"fields" : {
|
|
"message" : {
|
|
"type": "plain",
|
|
"fragment_size" : 15,
|
|
"number_of_fragments" : 3,
|
|
"fragmenter": "span"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
Response:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
{
|
|
...
|
|
"hits": {
|
|
"total": 1,
|
|
"max_score": 1.4818809,
|
|
"hits": [
|
|
{
|
|
"_index": "twitter",
|
|
"_type": "tweet",
|
|
"_id": "1",
|
|
"_score": 1.4818809,
|
|
"_source": {
|
|
"user": "test",
|
|
"message": "some message with the number 1",
|
|
"date": "2009-11-15T14:12:12",
|
|
"likes": 1
|
|
},
|
|
"highlight": {
|
|
"message": [
|
|
"some message with the <em>number</em> <em>1</em>"
|
|
]
|
|
}
|
|
}
|
|
]
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// TESTRESPONSE[s/\.\.\./"took": $body.took,"timed_out": false,"_shards": $body._shards,/]
|
|
|
|
If the `number_of_fragments` option is set to `0`,
|
|
`NullFragmenter` is used which does not fragment the text at all.
|
|
This is useful for highlighting the entire content of a document or field.
|
|
|
|
==== Highlight query
|
|
|
|
It is also possible to highlight against a query other than the search
|
|
query by setting `highlight_query`. This is especially useful if you
|
|
use a rescore query because those are not taken into account by
|
|
highlighting by default. Elasticsearch does not validate that
|
|
`highlight_query` contains the search query in any way so it is possible
|
|
to define it so legitimate query results aren't highlighted at all.
|
|
Generally it is better to include the search query in the
|
|
`highlight_query`. Here is an example of including both the search
|
|
query and the rescore query in `highlight_query`.
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"stored_fields": [ "_id" ],
|
|
"query" : {
|
|
"match": {
|
|
"comment": {
|
|
"query": "foo bar"
|
|
}
|
|
}
|
|
},
|
|
"rescore": {
|
|
"window_size": 50,
|
|
"query": {
|
|
"rescore_query" : {
|
|
"match_phrase": {
|
|
"comment": {
|
|
"query": "foo bar",
|
|
"slop": 1
|
|
}
|
|
}
|
|
},
|
|
"rescore_query_weight" : 10
|
|
}
|
|
},
|
|
"highlight" : {
|
|
"order" : "score",
|
|
"fields" : {
|
|
"comment" : {
|
|
"fragment_size" : 150,
|
|
"number_of_fragments" : 3,
|
|
"highlight_query": {
|
|
"bool": {
|
|
"must": {
|
|
"match": {
|
|
"comment": {
|
|
"query": "foo bar"
|
|
}
|
|
}
|
|
},
|
|
"should": {
|
|
"match_phrase": {
|
|
"comment": {
|
|
"query": "foo bar",
|
|
"slop": 1,
|
|
"boost": 10.0
|
|
}
|
|
}
|
|
},
|
|
"minimum_should_match": 0
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
[[highlighting-settings]]
|
|
==== Global Settings
|
|
|
|
Highlighting settings can be set on a global level and then overridden
|
|
at the field level.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"number_of_fragments" : 3,
|
|
"fragment_size" : 150,
|
|
"fields" : {
|
|
"_all" : { "pre_tags" : ["<em>"], "post_tags" : ["</em>"] },
|
|
"blog.title" : { "number_of_fragments" : 0 },
|
|
"blog.author" : { "number_of_fragments" : 0 },
|
|
"blog.comment" : { "number_of_fragments" : 5, "order" : "score" }
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
[[field-match]]
|
|
==== Require Field Match
|
|
|
|
`require_field_match` can be set to `false` which will cause any field to
|
|
be highlighted regardless of whether the query matched specifically on them.
|
|
The default behaviour is `true`, meaning that only fields that hold a query
|
|
match will be highlighted.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query" : {
|
|
"match": { "user": "kimchy" }
|
|
},
|
|
"highlight" : {
|
|
"require_field_match": false,
|
|
"fields": {
|
|
"_all" : { "pre_tags" : ["<em>"], "post_tags" : ["</em>"] }
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
[[boundary-scanners]]
|
|
==== Boundary Scanners
|
|
|
|
When highlighting a field using the unified highlighter or the fast vector highlighter,
|
|
you can specify how to break the highlighted fragments using `boundary_scanner`, which accepts
|
|
the following values:
|
|
|
|
* `chars` (default mode for the FVH): allows to configure which characters (`boundary_chars`)
|
|
constitute a boundary for highlighting. It's a single string with each boundary
|
|
character defined in it (defaults to `.,!? \t\n`). It also allows configuring
|
|
the `boundary_max_scan` to control how far to look for boundary characters
|
|
(defaults to `20`). Works only with the Fast Vector Highlighter.
|
|
|
|
* `sentence` and `word`: use Java's https://docs.oracle.com/javase/8/docs/api/java/text/BreakIterator.html[BreakIterator]
|
|
to break the highlighted fragments at the next _sentence_ or _word_ boundary.
|
|
You can further specify `boundary_scanner_locale` to control which Locale is used
|
|
to search the text for these boundaries.
|
|
|
|
[NOTE]
|
|
When used with the `unified` highlighter, the `sentence` scanner splits sentence
|
|
bigger than `fragment_size` at the first word boundary next to `fragment_size`.
|
|
You can set `fragment_size` to 0 to never split any sentence.
|
|
|
|
[[matched-fields]]
|
|
==== Matched Fields
|
|
|
|
WARNING: This is only supported by the `fvh` highlighter
|
|
|
|
The Fast Vector Highlighter can combine matches on multiple fields to
|
|
highlight a single field using `matched_fields`. This is most
|
|
intuitive for multifields that analyze the same string in different
|
|
ways. All `matched_fields` must have `term_vector` set to
|
|
`with_positions_offsets` but only the field to which the matches are
|
|
combined is loaded so only that field would benefit from having
|
|
`store` set to `yes`.
|
|
|
|
In the following examples `comment` is analyzed by the `english`
|
|
analyzer and `comment.plain` is analyzed by the `standard` analyzer.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query": {
|
|
"query_string": {
|
|
"query": "comment.plain:running scissors",
|
|
"fields": ["comment"]
|
|
}
|
|
},
|
|
"highlight": {
|
|
"order": "score",
|
|
"fields": {
|
|
"comment": {
|
|
"matched_fields": ["comment", "comment.plain"],
|
|
"type" : "fvh"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
The above matches both "run with scissors" and "running with scissors"
|
|
and would highlight "running" and "scissors" but not "run". If both
|
|
phrases appear in a large document then "running with scissors" is
|
|
sorted above "run with scissors" in the fragments list because there
|
|
are more matches in that fragment.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query": {
|
|
"query_string": {
|
|
"query": "running scissors",
|
|
"fields": ["comment", "comment.plain^10"]
|
|
}
|
|
},
|
|
"highlight": {
|
|
"order": "score",
|
|
"fields": {
|
|
"comment": {
|
|
"matched_fields": ["comment", "comment.plain"],
|
|
"type" : "fvh"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
The above highlights "run" as well as "running" and "scissors" but
|
|
still sorts "running with scissors" above "run with scissors" because
|
|
the plain match ("running") is boosted.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"query": {
|
|
"query_string": {
|
|
"query": "running scissors",
|
|
"fields": ["comment", "comment.plain^10"]
|
|
}
|
|
},
|
|
"highlight": {
|
|
"order": "score",
|
|
"fields": {
|
|
"comment": {
|
|
"matched_fields": ["comment.plain"],
|
|
"type" : "fvh"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
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
|
|
(`comment`) in the matched fields.
|
|
|
|
[NOTE]
|
|
Technically it is also fine to add fields to `matched_fields` that
|
|
don't share the same underlying string as the field to which the matches
|
|
are combined. The results might not make much sense and if one of the
|
|
matches is off the end of the text then the whole query will fail.
|
|
|
|
[NOTE]
|
|
===================================================================
|
|
There is a small amount of overhead involved with setting
|
|
`matched_fields` to a non-empty array so always prefer
|
|
[source,js]
|
|
--------------------------------------------------
|
|
"highlight": {
|
|
"fields": {
|
|
"comment": {}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// NOTCONSOLE
|
|
to
|
|
[source,js]
|
|
--------------------------------------------------
|
|
"highlight": {
|
|
"fields": {
|
|
"comment": {
|
|
"matched_fields": ["comment"],
|
|
"type" : "fvh"
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// NOTCONSOLE
|
|
===================================================================
|
|
|
|
[[phrase-limit]]
|
|
==== Phrase Limit
|
|
|
|
WARNING: this is only supported by the `fvh` highlighter
|
|
|
|
The fast vector highlighter has a `phrase_limit` parameter that prevents
|
|
it from analyzing too many phrases and eating tons of memory. It defaults
|
|
to 256 so only the first 256 matching phrases in the document scored
|
|
considered. You can raise the limit with the `phrase_limit` parameter but
|
|
keep in mind that scoring more phrases consumes more time and memory.
|
|
|
|
If using `matched_fields` keep in mind that `phrase_limit` phrases per
|
|
matched field are considered.
|
|
|
|
[float]
|
|
[[explicit-field-order]]
|
|
=== Field Highlight Order
|
|
Elasticsearch highlights the fields in the order that they are sent. Per the
|
|
json spec objects are unordered but if you need to be explicit about the order
|
|
that fields are highlighted then you can use an array for `fields` like this:
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /_search
|
|
{
|
|
"highlight": {
|
|
"fields": [
|
|
{ "title": {} },
|
|
{ "text": {} }
|
|
]
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[setup:twitter]
|
|
|
|
None of the highlighters built into Elasticsearch care about the order that the
|
|
fields are highlighted but a plugin may.
|