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. 行胜于言，去做就是了