ElasticStack系列之十七 & 大文本搜索性能提升方案

Posted 2020-10-10 星火燎原智勇

1. 什么是大文本？具体是什么？

　　首先需要理解，ElasticSearch 建立索引完成全文检索的前提是将待检索的信息导入到 ElasticSearch 中。而有的信息对应的正文内容会非常的打，可能达到 1MB ~ 3MB 左右字节，这个内容就认为是大文本，一般我们都将该内容存储到名为 content 字段中，进而对这个 Content 字段进行全文检索&高亮显示，就会存在检索效率低下的问题，更有甚者耗时可能达到 30s 左右。

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

2. 问题描述

　　从检索症状来看：

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

　　2. 当遇到某些大文件的时候，相应时间尤其长，超过 30s 以上返回高亮结果

3. 问题排查与优化

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

　　从百度、360、搜狗等搜索引擎都不提供访问末页的请求方式，都是基于点击上一页、下一页来逐页访问。其实这个从用户的角度也很好理解，搜索引擎返回的前面的数据都是最相关的，也是用户最关心的信息。ElasticSearch 的默认支持的数据条数是 10000 条，所以最好最大条数也定位 10000 条或者比这个数值更小。

　　2. from/size 相应慢问题

　　[from + size 机制]

　　　　当 ElasticSearch 相应请求时，它必须确定 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 难管理问题存在。使用 scroll 必须是按照顺序一页一页进行翻阅，如果是无规则的翻页，它的性能消耗也是极大的。

　　以上两种翻页机制需要根据实际场景进行合理的选择。

　　3. 查看内存情况

　　当出现 卡顿、卡死等性能低、用户体验差情况时，需要及时查看 ElasticSearch 的日志，查一下是否是因为对内存不足导致的，还是因为设置的新、老代参数不合理导致的。

　　之前是因为机器内存不足，设置了 16GB，通过日志发现堆内存不够会对老年代进行 Full GC 导致停顿，果断增加堆内存，由 16GB 增加到最大值 31GB。

　　4. 逆向解析 DSL，排查查询慢原因

　　1. 打印出相应的查询 DSL，可以通过接口：searchSourceBuilder.toString();

　　2. 使用 profile 参数，查看到底哪里慢

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

　　3. 尝试换全文搜索接口 api，将 query_string 改为 match query，对应的速度会有一定的提升

　　4. 删除某些查询条件，在基础数据不变的条件下，查看查询速度是否快了。

　　　　验证发现，当不返回 content 字段，速度会变快很多；当取消高亮字段处理，速度会更快。至此初步断定和高亮处理有关系。

　　5. 高亮问题排查及优化

　　通过论坛发现，对于大文件高亮都推荐使用：fast-vector-highlighter。

　　根据官网介绍，ElasticSearch 高亮一共有三种方式，分别如下：

　　方式一：传统 plain 高亮方式

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

　　方式二：postings 高亮方式

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

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

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

　　posting高亮方式的特点：

　　　　1. 速度快，不需要对高亮的文档再分析。文档越大，获得越高性能。

　　　　2. 比fvh高亮方式需要的磁盘空间少。

　　　　3. 将 text 文件分割成语句并对其高亮处理。对于自然语言发挥作用明显，但对于 html 则不然。

　　　　4. 将文档视为整个语料库，并使用BM25算法为该语料库中的文档打分。

　　应用举例：

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

　　方式三：fast-vector-highlighter 简称 fvh 高亮方式　　

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

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

　　fvh高亮方式将取代传统的plain高亮方式。

　　fvh 高亮方式的特点如下：

　　　　1. 当 doc 大于 > 1MB 的时候，尤其适合 fvh 高亮方式。

　　　　2. 自定义为 boundary_scanner的扫描方式。

　　　　3. 设定了 term_vector --> with_positions_offsets 会增加索引的大小。

　　　　4. 能联合多字段匹配返回一个结果，详见 matched_fields。

　　　　5. 对于不同的匹配类型分配不同的权重，如：pharse 匹配比 term 匹配高。

　　应用举例：

　　{
 　　 "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 倍。

4. 总结

　　需要从心底里认识到，一切 bug 都是纸老虎，遇到问题自己不能乱，一点点抽丝剥茧去将难题拆解并解决，有几点需要记住：

　　1. 敢于承担暴露的问题是开发者责任的体现

　　2. 出了 bug，要耐心定位 bug、追踪 bug 是关键

　　3. 拆解细化问题，并逐条列举排查思路是王道

　　4. 行胜于言，去做就是了