Elasticsearch大文件检索性能提升20倍实践（干货）_elasticsearch 查询优化

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

原因分析：卡顿、卡死都是堆内存设置不足导致。
根据之间总结的高性能配置建议，果断加堆内存，由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倍。

步骤5 小结

清醒认知，一切bug都是纸老虎。
多年开发经验让我深深认知到：

1,敢于暴露问题是开发者责任的体现。

这里包括所有技术问题，尤其是在测试人员、用户之前发现的问题。

2,出了bug，定位bug、根查bug是关键。

少瞎bb，少踢皮球。那些是市井“小市民”的专利，我们要敬而远之，也不要成为那样的人。
“出淤泥而不染”是程序员恪守的宝贵品格。

3,项目负责人要稳定军心。

你TM乱了，军心就焕然了。
不要板着脸，没有程序员亏欠你的，就事说事，对事不对人。

4,不同阶段说不同阶段的事，不马后炮。

到了上线阶段，说选型不合理、架构不合理，打谁的脸？
平时务必及时关注项目动态，提前关注技术难点和风险点，协调架构师等技术专家，和大家一起克服。
一切马后炮都是管理无能的体现！

5,拆解细化问题，并逐条列举排查思路是王道！

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！**

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取