麦田一葱 wordpress海口网站关键词优化

目录

高亮查询使用介绍

高亮参数

三种分析器

可能存在的查询问题

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在高亮时候的逻辑如下：

1. 分析高亮查询语法，提取表达式中的高亮词集合

2. 从磁盘上读取该文档字段下的词向量集合

3. 遍历词向量集合，提取自表达式中出现的词向量

4. 根据提取到目标词向量读取词频信息，根据词频获取每个位置信息、偏移量

5. 通过相似度算法获取得分较高的前n组高亮信息

6. 读取字段内容（多字段用空格隔开），根据提取的词向量直接定位截取高亮字段

由此可见，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

[Highlighting | Elasticsearch Guide [8.15] | Elastic] Highlighting | Elasticsearch Guide [8.15] | Elastic