Elasticsearch大文件检索性能提升20倍实践

桃扇骨 2023-06-25 02:21 10阅读 0赞

### **1、大文件是多大？** ###

ES建立索引完成全文检索的前提是将待检索的信息导入Elaticsearch。

项目中，有时候需要将一些扫描件、PDF文档、Word、Excel、PPT等文档内容导入Elasticsearch。

比如：将《深入理解Elasticsearch》这边书导入ES，而这边书的全文内容被识别后的大小可能为3MB——5MB以上的字节。

存入ES后是一个content字段，对这个content执行全文检索&高亮显示，就存在检索效率低的问题，会耗时30S以上的时间。

这点，作为习惯了搜索引擎极速体验的用户，是不能忍的。

本文，详细记录了大文件的全文检索性能问题排查及**提升**实践方式。

### **2、问题描述** ###

从检索症状来看：

1）翻页到1000+页（每页10条数据）以上，响应时间会比较长。

2）当遇到某些文件的时候（事后分析得知是大文件），响应时间尤其长，超过30S以上返回高亮结果。

### **3、问题排查与定位** ###

**步骤1： 限定返回记录条数。不提供直接访问末页的入口。**

baidu，360，搜狗等搜索引擎都不提供访问末页的请求方式。都是基于如下的请求方式：   
通过点击上一下、下一页逐页访问。

![format_png][]

这个从用户的角度也很好理解，搜索引擎返回的前面都是相关度最高的，也是用户最关心的信息。

Elasticsearch的默认支持的数据条数是10000条，可以通过post请求修改。

最终，本步骤将支持ES最大返回值10000条数据，每页10条，也就是共显示1000页数据。

**步骤2,from size机制问题 ，大于设定页就会慢。**

【from + size机制】：当Elasticsearch响应请求时，它必须确定docs的顺序，排列响应结果。如果请求的页数较少（假设每页10个docs）, Elasticsearch不会有什么问题，但是如果页数较大时，比如请求第100页，Elasticsearch不得不取出第1页到第100页的所有docs，再去除第1页到第99页的docs，得到第100页的docs。

【scroll机制】：相对于from和size的分页来说，使用scroll可以模拟一个传统数据的游标，记录当前读取的文档信息位置。这个分页的用法，不是为了实时查询数据，而是为了一次性查询大量的数据（甚至是全部的数据）。

因为这个scroll相当于维护了一份当前索引段的快照信息，这个快照信息是你执行这个scroll查询时的快照。在这个查询后的任何新索引进来的数据，都不会在这个快照中查询到。但是它相对于from和size，不是查询所有数据然后剔除不要的部分，而是记录一个读取的位置，保证下一次快速继续读取。

from+size方式以及scroll方式优缺点对比：

1）对于from+size方式：当结果足够大的时候，会大大加大内存和CPU的消耗。但，该方式使用非常方便。

2）对于scroll方式： 当结果足够大的时候， scroll 性能更佳。但是不灵活和 scroll\_id 难管理问题存在。

【from网络】个人测试：当 结果足够大的时候 产生 scroll\_id 性能也不低。如果只是一页页按照顺序，scroll是极好的，但是如果是无规则的翻页，那也是性能消耗极大的。

经过两种机制对比，加之步骤1，限定了分页数，最大1000页。并且用户支持主页翻页的方式，暂定还是采用from+size方式。

如果后面步骤有问题，再考虑换成scorll机制。

**步骤3, 查看ES打印日志。**

当出现卡顿、卡死等性能低、用户体验差问题时，查看ES的日志。   
分析日志如下：   
![format_png 1][]  
原因分析：卡顿、卡死都是堆内存不足导致。   
根据之间总结的高性能配置建议，果断加堆内存，由16GB增加到最大值31GB。   
堆内存使用比率可以通过：**cerebro **工具检测性能。

**步骤4：类似逆向解析dsl，排查查询慢在哪？**

1） 打印出DSL，可以通过接口： searchSourceBuilder.toString()。

2) 新增profile参数，查看到底哪里慢了。

profile API的目的是：将ES高层的ES请求拉平展开，直观的让你看到请求做了什么，每个细分点花了多少时间。   
给你改善性能提供相关支撑工作。   
使用举例如下：

GET /_search 
    {
    	"profile": true,
    	"query": {
    		"match": {
    			"message": "message number"
    		}
    	}
    }

3） 换了全文接口api ，query\_string改成match query满足要求且速度有提升。

4）删除某些查询条件，在基础数据不变的条件下，查看查询速度是否快了（返回时间短了）。

验证发现，当不返回content字段（\_source控制）时，速度会变快。

当取消高亮字段处理，速度会更快。0.5秒之内返回结果。

至此，初步断定和高亮处理有关系。

**步骤5：高亮问题排查及优化。**

通过论坛中网友的建议来看，都推荐对于大文件高亮使用： fast-vector-highlighter。

查询官网文档得知：   
Elasticsearch高亮分为三种方式：

***方式1：传统plain高亮方式。***

官网明确支持，该方式匹配慢，如果出现性能问题，请考虑其他高亮方式。

***方式2： postings 高亮方式。***

支持postings高亮方式，需要在mapping下添加如下信息：

"type": "text",
    "index_options" : "offsets"

添加完毕后，posting高亮方式将取代传统的高亮方式。

posting高亮方式的特点：   
1）速度快，不需要对高亮的文档再分析。文档越大，获得越高 性能 。   
2）比fvh高亮方式需要的磁盘空间少。   
3）将text文件分割成语句并对其高亮处理。对于自然语言发挥作用明显，但对于html则不然。   
4）将文档视为整个语料库，并 使用BM25算法 为该语料库中的文档打分。   
使用举例：

PUT /example
    {
    	"mappings": {
    		"doc": {
    			"properties": {
    				"comment": {
    					"type": "text",
    					"index_options": "offsets"
    				}
    			}
    		}
    	}
    }

***方式3： fast-vector-highlighter 简称fvh高亮方式。***

如果在mapping中的text类型字段下添加了如下信息：

"type": "text",
    "term_vector" : "with_positions_offsets"

fvh高亮方式将取代传统的plain高亮方式  
fvh高亮方式的特点如下：   
1）当文件**>1MB**(大文件）时候，尤其适合fvh高亮方式。   
2）自定义为 boundary\_scanner的扫描方式。   
3) 设定了 term\_vector to with\_positions\_offsets会增加索引的大小。   
4）能联合多字段匹配返回一个结果，详见matched\_fields。   
5）对于不同的匹配类型分配不同的权重，如：pharse匹配比term匹配高。   
举例：

PUT /example
    {
    	"mappings": {
    		"doc": {
    			"properties": {
    				"comment": {
    					"type": "text",
    					"term_vector": "with_positions_offsets"
    				}
    			}
    		}
    	}
    }

最终选型：**fvh高亮方式**。首先：新建了索引，按照fvh的方式对content字段新设置了mapping；其次通过如下方式进行索引数据同步：

POST /_reindex
    {
    	"source": {
    		"index": "test_index"
    	},
    	"dest": {
    		"index": "test_index_new"
    	}
    }

实践结果表明，同样的大文件，原本检索>40S，现在2S之内返回结果。   
没有改一行代码，只修改了mapping，效率提升了近20倍。

文章来源：[Elasticsearch大文件检索性能提升20倍实践（干货）][Elasticsearch_20]

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy9tamw4R0Nwc0w5Wm1ER1NzbEpPVFZmSnZnZk03dzFYd29IUVVqN05oY0hKSmQ2YlhXTzFxekpzazhHRW04SVhpYzVEdElLYnczUVk4aWFPS1V0SnRtTHp3LzY0MA?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cDovL21tYml6LnFwaWMuY24vbW1iaXpfcG5nL21qbDhHQ3BzTDlabURHU3NsSk9UVmZKdmdmTTd3MVh3QUZJTFNJcFhVNnZ6Wkg4SURIcUxyWTlSNGNlZFU3MTY0aWFTamtQQUd5aWFPVDNPQWFxZWliWkJ3LzY0MA?x-oss-process=image/format,png
[Elasticsearch_20]: http://mp.weixin.qq.com/s?__biz=MzI2NDY1MTA3OQ==&mid=2247483695&idx=2&sn=d662a6b680c8071dd8577854c081a3d7&chksm=eaa82907dddfa01176f7a295ad63289f47b73278b09cbbb5360a220a45ff0108dd9ec7d215d9&scene=21#wechat_redirect