目录
fvh查询时出现StringIndexOutOfBoundsException越界
高亮查询使用介绍
Elasticsearch 的高亮（highlight）可以从搜索结果中的一个或多个字段中获取突出显示的摘要，以便向用户显示查询匹配的位置。
一个最基础的请求实例：
GET /my_index/_search
{
"query": {
"match": {
"content": "Elasticsearch"
}
},
"highlight": {
"fields": {
"content": {}
}
}
}基于这一请求返回的高亮片段会默认使用<em></em> 高亮标识
高亮参数
高亮查询能使用的参数很多，包含如下：
| 参数 | 说明 |
|---|---|
| boundary_chars | 包含每个边界字符的字符串。默认为,! ?\ \ n。 |
| boundary_max_scan | 扫描边界字符的距离。默认为20。 |
| boundary_scanner | 指定如何分割突出显示的片段，支持chars、sentence、word三种方式。 |
| boundary_scanner_locale | 用来设置搜索和确定单词边界的本地化设置，此参数使用语言标记的形式（"en-US", "fr-FR", "ja-JP"） |
| encoder | 表示代码段应该是HTML编码的:默认(无编码)还是HTML (HTML-转义代码段文本，然后插入高亮标记) |
| fields | 指定检索高亮显示的字段。可以使用通配符来指定字段。例如，可以指定comment**来获取以comment*开头的所有文本和关键字字段的高亮显示。 |
| force_source | 根据源高亮显示。默认值为false。 |
| fragmenter | 指定文本应如何在突出显示片段中拆分:支持参数simple或者span。 |
| fragment_offset | 控制要开始突出显示的空白。仅在使用fvh highlighter时有效。 |
| fragment_size | 字符中突出显示的片段的大小。默认为100。 |
| highlight_query | 突出显示搜索查询之外的其他查询的匹配项。这在使用重打分查询时特别有用，因为默认情况下高亮显示不会考虑这些问题。 |
| matched_fields | 组合多个匹配结果以突出显示单个字段，对于使用不同方式分析同一字符串的多字段。所有的matched_fields必须将term_vector设置为with_positions_offsets，但是只有将匹配项组合到的字段才会被加载，因此只有将store设置为yes才能使该字段受益。只适用于fvh highlighter。 |
| no_match_size | 如果没有要突出显示的匹配片段，则希望从字段开头返回的文本量。默认为0(不返回任何内容)。 |
| number_of_fragments | 返回的片段的最大数量。如果片段的数量设置为0，则不会返回任何片段。相反，突出显示并返回整个字段内容。当需要突出显示短文本(如标题或地址)，但不需要分段时，使用此配置非常方便。如果number_of_fragments为0，则忽略fragment_size。默认为5。 |
| order | 设置为score时，按分数对突出显示的片段进行排序。默认情况下，片段将按照它们在字段中出现的顺序输出(order:none)。将此选项设置为score将首先输出最相关的片段。每个高亮应用自己的逻辑来计算相关性得分。 |
| phrase_limit | 控制文档中所考虑的匹配短语的数量。防止fvh highlighter分析太多的短语和消耗太多的内存。提高限制会增加查询时间并消耗更多内存。默认为256。 |
| pre_tags | 与post_tags一起使用，定义用于突出显示文本的HTML标记。默认情况下，突出显示的文本被包装在和标记中。指定为字符串数组。 |
| post_tags | 与pre_tags一起使用，定义用于突出显示文本的HTML标记。默认情况下，突出显示的文本被包装在和标记中。指定为字符串数组。 |
| require_field_match | 默认情况下，只突出显示包含查询匹配的字段。将require_field_match设置为false以突出显示所有字段。默认值为true。 |
| tags_schema | 设置为使用内置标记模式的样式。 |
| type | 使用的高亮模式，可选项为***unified*** 、plain 或***fvh*** 。默认为unified。 |
三种分析器
在es的官方文档中提到，es提供了三种高亮分析器，分别是默认的unified、plain、fvh。这三种模式都是基于更底层的Lucene进行的实现，unified使用Lucene Unified Highlighter，plain使用standard Lucene highlighter，fvh使用Lucene Fast Vector highlighter。
三种高亮器各有优缺点
默认的 unified highlighter 是最基本的高亮器。unified highlighter 高亮器是个实时分析处理高亮器，即用户在查询的时候，搜索引擎查询到了目标数据docid后，将需要高亮的字段数据提取到内存，再调用该字段的分析器进行处理，分析器对文本进行分析处理，分析完成后采用相似度算法计算得分最高的前n组并高亮段返回数据。实现高亮功能需要对 _source 中保存的原始文档进行二次分析，其速度在三种高亮器里最慢，优点是不需要额外的存储空间。
unified的这种实时分析机制会让ES占用较少的IO资源同时也占用较少的存储空间（词库较全的话相比fvh方式能节省一半的存储空间），其实时计算高亮是采用cpu资源来缓解io压力，在高亮字段较短（比如高亮文章的标题）时候速度较快，同时因io访问的次数少，io压力较小，有利于提高系统吞吐量。
为解决 highlighter 高亮器质大文本字段上高亮速度跟不上的问题，lucene高亮模块提供了基于向量的高亮方式 fast-vector-highlighter（也称为fvh）。fast-vector-highlighter 高亮器利用建索引时候保存好的词向量来直接计算高亮段落，在高亮过程中比plain高亮方式少了实时分析过程，取而代之的是直接从磁盘中将分词结果直接读取到内存中进行计算，故需要在字段的映射中设置 term_vector 参数的取值为 with_positions_offsets，即保存关键词的位置和偏移信息，占用的存储空间最大，但实现高亮功能速度最快，是典型的空间换时间的做法。例如，配置 comment 字段使用 fast-vector-highlighter 高亮器，映射如下：
PUT /example
{
"mappings": {
"doc": {
"properties": {
"comment": {
"type": "text",
"term_vector": "with_positions_offsets"
}
}
}
}
}fvh在高亮时候的逻辑如下：
-
分析高亮查询语法，提取表达式中的高亮词集合
-
从磁盘上读取该文档字段下的词向量集合
-
遍历词向量集合，提取自表达式中出现的词向量
-
根据提取到目标词向量读取词频信息，根据词频获取每个位置信息、偏移量
-
通过相似度算法获取得分较高的前n组高亮信息
-
读取字段内容（多字段用空格隔开），根据提取的词向量直接定位截取高亮字段
由此可见，fvh 省去了实时分析过程，但是多了词条向量信息存储和读取，在词库丰富的系统中，存储词向量往往要比不存储词向量多占用一倍的空间，同时在高亮时候会比plain高亮多出至少一倍的io操作次数，读取的字节大小也多出至少一倍，大量的io请求会让搜索引擎并发能力降低。
与plain方式相比，fvh高亮在文档字段内容较大的情况下具有较大优势，特别是在使用ssd的情况下
postings-highlighter 高亮器实现高亮功能不需要二次分析，高亮方式与fvh相似，采用词量向量的方式进行高亮，与fvh高亮不同的是postings高亮只存储了词向量的位置信息，并未存储词向量的偏移量，故中大字段存储中，postings其比fvh节省约20-30%的存储空间，速度与fvh基本相当。需要在字段的映射中设置 index_options 参数的取值为 offsets，即保存关键词的偏移量，速度快于默认的 highlighter 高亮器。例如，配置 comment 字段使用 postings-highlighter 高亮器，映射如下：
PUT /example
{
"mappings": {
"doc": {
"properties": {
"comment": {
"type": "text",
"index_options": "offsets"
}
}
}
}
}在实际使用中，postings高亮的优点和缺点都不突出，故建议开发者在做高亮需求时候，可对小字段采用highlighter高亮方式，大字段采用fast-vector-highlighter即可满足需求。
可能存在的查询问题
fvh查询时出现StringIndexOutOfBoundsException越界
在某些场景可能会发现使用fvh查询会报错，es返回数组越界，通过查询es github的issue发现，这是更底层的Lucene的Lucene Fast Vector highlighter一直存在的bug，只能规避使用fvh才能解决
检索高亮不正确
这大概是es高亮器最常见的问题，在实际使用过程中，发现不管是unified、plain还是fvh，都会在某些case下冒出高亮不正确的毛病，例如plain模式高亮不精准，换成unified就好了，反过来的案例也存在。
研究后发现这是Lucene原本实现方式导致的固有毛病，可能只有自己实现一套检索高亮功能才是最合适的。
参考文档
In some cases FVH returns StringIndexOutOfBoundsException · Issue #22997 · elastic/elasticsearch · GitHub\] [In some cases FVH returns StringIndexOutOfBoundsException · Issue #22997 · elastic/elasticsearch · GitHub](https://github.com/elastic/elasticsearch/issues/22997 "In some cases FVH returns StringIndexOutOfBoundsException · Issue #22997 · elastic/elasticsearch · GitHub") \[Highlighting \| Elasticsearch Guide \[8.15\] \| Elastic\] [Highlighting \| Elasticsearch Guide \[8.15\] \| Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/current/highlighting.html "Highlighting | Elasticsearch Guide [8.15] | Elastic")