搜索引擎进行信息检索的优化策略方法(2021-09-161.什么是大文本？具体是什么？)
优采云 发布时间: 2022-04-18 22:29搜索引擎进行信息检索的优化策略方法(2021-09-161.什么是大文本？具体是什么？)
2021-09-161.什么是大文本？究竟是什么？
首先要明白，ElasticSearch建立索引完成全文检索的前提是将要检索的信息导入ElasticSearch。而一些信息对应的文本内容会很大，可能达到1MB~3MB字节左右。该内容被认为是大文本。一般我们将这些内容存储在一个名为 content 的字段中，然后对 Content 字段进行处理。全文搜索&高亮，会出现搜索效率低的问题，更耗时可能达到30s左右。
这对于一个习惯了搜索引擎极速体验的用户来说，是不能容忍的。
2. 问题描述
从检索症状：
1. 翻页到1000+页（每页10条数据），响应时间会更长
2. 遇到一些大文件时，响应时间特别长，高亮结果会返回30s以上
3. 故障排除与优化1. 限制返回记录数。不提供对最后一页的直接访问
百度、360、搜狗等搜索引擎不提供访问最后一页的请求方式。它们都是基于单击上一页和下一页的逐页访问的。其实这从用户的角度也很好理解。搜索引擎返回的以前的数据是最相关的，也是用户最关心的信息。ElasticSearch默认支持的数据条数为10000条，所以最好将最大条数设置为10000条或小于该值。
2. from/size 对应慢问题
[从+尺寸机制]
当 ElasticSearch 响应请求时，它必须确定文档的顺序并安排相应的结果。如果请求的页数很少，ElasticSearch 是没有问题的，但是如果页数很大，比如请求第 100 页，ElasticSearch 必须从第 1 到第 100 页获取所有文档，然后删除第 1 到第 100 页。文档在第 99 页，获取文档在第 100 页。
【滚动机制】
与from+size机制分页相比，使用滚动可以模拟一个传统的数据游标，记录当前读取的文档信息的位置。这种分页的使用并不是为了实时查询数据，而是一次查询大量数据甚至全部数据。
因为这个滚动相当于维护了当前索引段的快照，所以快照信息就是执行滚动查询时的快照。此查询后从新索引传入的任何数据都不会在此快照中查询。但是，相比from+size机制，它并不是查询所有数据然后去掉不需要的部分，而是记录一个读位置，保证下一次快速读。
from+size方式和scroll方式的优缺点对比：
1. from + size 方法：当结果足够大时，会大大增加内存和CPU消耗。但是这种方法使用起来非常方便。
2. 对于滚动模式：当结果足够大时，滚动性能更好。但存在scroll_id不灵活、管理困难的问题。滚动的使用必须逐页按顺序使用。如果是不规则翻页，其性能消耗也是巨大的。
以上两种翻页机制需要根据实际场景合理选择。
3. 查看内存状态
当出现卡住、卡住等性能低下、用户体验差的情况时，需要及时查看ElasticSearch日志，检查是内存不足还是新老代参数设置不合理造成的。
之前因为机器内存不足，设置为16GB。通过日志发现堆内存不足会导致老年代Full GC，造成停顿。堆内存果断地从 16GB 增加到最大 31GB。
4. DSL逆向分析排查慢查询
1. 打印出对应的查询DSL，可以通过接口访问：searchSourceBuilder.toString();
2. 使用profile参数看看什么是慢的
profile API的目的是在ES的高层对ES请求进行扁平化和扩展，让你可以直观的看到请求做了什么，每个segment花费了多少时间，为你提供提升性能的相关支持.
3. 尝试更改全文搜索接口api，更改query_string匹配查询，相应速度会有一定提升
4. 删除部分查询条件，在基本数据不变的情况下查看查询速度是否更快。
验证发现不返回content字段时，速度会快很多；取消高亮字段处理时，速度会更快。至此，初步断定与高亮有关。
5. 重点排查和优化
通过论坛推荐使用：fast-vector-highlighter 进行大文件高亮。
根据官网介绍，ElasticSearch高亮的方式有以下三种：
方法一：传统的素色高亮法
官网明确支持这种方式。这种方法匹配起来很慢。如果存在性能问题，请考虑其他突出显示方法。
方法二：发帖高亮方法
要支持发帖的高亮方式，需要在映射下添加如下信息：
"type": "text",
"index_options" : "offsets"
添加完成后，发帖高亮方式将替代传统高亮方式。
发布高亮方法的特点：
1.速度快，无需重新分析高亮文件。文档越大，性能越高。
2.比 fvh 突出显示需要更少的磁盘空间。
3.将文本文件拆分成句子并突出显示。它适用于自然语言，但不适用于 html。
4. 将文档视为整个语料库，并使用 BM25 算法对该语料库中的文档进行评分。
应用实例：
{
"mappings": {
"doc" : {
"properties": {
"comment" : {
"type": "text",
"index_options" : "offsets"
}
}
}
}
}
方法三：fast-vector-highlighter 缩写为fvh高亮方法
如果在映射的文本类型字段下添加以下信息：
"type": "text",
"term_vector" : "with_positions_offsets"
fvh 突出显示方法将取代传统的普通突出显示方法。
fvh高亮方法的特点如下：
1. 特别适用于 doc 大于 > 1MB 时的 fvh 高亮。
2.自定义boundary_scanner的扫描方式。
3.设置 term_vector --> with_positions_offsets 会增加索引的大小。
4.可以组合多个字段返回一个结果，详见matched_fields。
5.为不同的匹配类型分配不同的权重，例如：短语匹配高于术语匹配。
应用实例：
{
"mappings": {
"doc" : {
"properties": {
"comment" : {
"type": "text",
"term_vector" : "with_positions_offsets"
}
}
}
}
}
最终选择：fvh 高亮方法。
第一：新建索引，根据fvh方法为内容字段重新设置映射；
二：通过以下方式同步索引数据：
POST /_reindex {"source":{"index":"test_index"}, "dest":{"index":"test_index_new"}}
实际结果表明，原来检索>40s的同一个大文件，现在2s内返回结果。没有改行代码，只修改了映射，效率提升了近20倍。
4. 总结
你需要发自内心地意识到，所有的虫子都是纸老虎。当你遇到问题时，你不能乱来。您可以一次拆卸并解决问题。有几点要记住：
1. 敢于承担暴露的问题是开发者责任的体现
2. 有bug，关键是耐心定位bug，跟踪bug
3. 拆解细化问题，一一列出排查思路，才是王道
4. 行动胜于雄辩，去做就行
分类：
技术要点：
相关文章：
