es搜索数据
es搜索数据流程
es读写流程示意图
image.png
analysis：主要负责词法分析及语言处理，也就是我们常说的分词，通过该模块可最终形成存储或者搜索的最小单元 Term。
index 模块：主要负责索引的创建工作。
store 模块：主要负责索引的读写，主要是对文件的一些操作，其主要目的是抽象出和平台文件系统无关的存储。
queryParser 模块：主要负责语法分析，把我们的查询语句生成 Lucene 底层可以识别的条件。
search 模块：主要负责对索引的搜索工作。
similarity 模块：主要负责相关性打分和排序的实现。
分布式搜索示意图
image.png
1. 客户端发送一个 search（搜索） 请求给 Node 3 , Node 3 创建了一个长度为 from+size 的空优先级队列。
2. Node 3 转发这个搜索请求到索引中每个分片的原本或副本。搜索请求可以被每个分片的原本或任意副本处理。
3. 每个分片在本地执行这个查询并且结果将结果到一个大小为 from+size 的有序本地优先队列里去。
4. 每个分片返回document的ID和它优先队列里的所有document的排序值给协调节点 Node 3 。 Node 3 把这些值合并到自己的优先队列里产生全局排序结果。
es的几种搜索类型
- QUERY_THEN_FETCH(默认的方式)
第一步，先向所有的shard发出请求，各分片只返回排序和排名相关的信息（注意，不包括文档document)，然后按照各分片返回的分数进行重新排序和排名，取前size个文档。然后进行第二步，去相关的shard取document。这种方式返回的document与用户要求的size是相等的。
- QUERY_AND_FEATCH
向索引的所有分片（shard）都发出查询请求，各分片返回的时候把元素文档（document）和计算后的排名信息一起返回。这种搜索方式是最快的。因为相比下面的几种搜索方式，这种查询方法只需要去shard查询一次。但是各个shard返回的结果的数量之和可能是用户要求的size的n倍。
es读取优化的切入点
-
为文件系统预留足够的内存
- es的查询会优先使用cache,如果命中缓存则可有效减少磁盘读取。
-
升级硬件
- 升级磁盘为SSD磁盘
-
预索引
- 其实是针对特定的查询，例如查询时可能涉及一些聚合的计算，可以在索引的时候预先将聚合的结果存储进去。
-
优化日期检索
- 使用日期检索时，使用now的查询不能使用到缓存，因为匹配的范围一直在变化，可切换到使用完整的日期，例如改用 now/m，四舍五入到分钟。
-
合并分段
- 对不再更新的索引使用force merge,将多个分段合并为一个分段，提高查询效率。
-
预热文件系统(文件缓存需足够大)
- 提高es重启之后的查询速度
put /my_index { "settings": { "index.store.preload": ["nvd","dvd"] } } -
batched_reduce_size
- 默认情况下，协调节点等待所有分片结果全部拿到之后才进行聚合操作，该参数可以等待对应的节点数返回数据时先处理一部分。
-
限制搜索请求的分片数
- action.search.shard_count 限制请求分片数，主要是减少协调节点的压力。默认es拒绝超过1000个分片的查询请求。
- 分片数设置： 一般分片数数的设置应保证每个分片的大小不超过JVM的最大堆内存(一般不超过32G)；一般分片数量不超过节点数的3倍。
-
ARS自适应脚本选择
- cluster.routing.use_adaptive_replica_selection:true
- 为了充分利用集群资源，协调节点会将搜索请求轮询转发到分片的每个副本上，但是当某个节点因为 gc、io带宽等原因处于忙碌状态时，由于这一个节点，可能导致查询时间过长，ARS是对分片的副本进行排序，以确定转发请求的最佳副本，避免请求落到忙碌的节点上。
-
字段映射
- 对于int/long类型的文本，如果是用做标识符，也推荐使用keyword的字段类型。 例：buyer_id
避免大结果集和深翻
例如，要查询从 from 开始的 size 条数据，则需要在每个分片中查询打分排名在前面的 from+size 条数据。
协同节点将收集到的n×(from+size)条数据聚合，再进行一次排序，然后从 from+size 开始返回 size 条数据。
当 from、size 或者 n 中有一个值很大的时候，需要参加排序的数量也会增长，这样的查询会消耗很多 CPU 资源，从而导致效率的降低。
* scroll
```
例如，我们需要查询 1～100 页的数据，每页 100 条数据。
如果使用 Search 查询：每次都需要在每个分片上查询得分最高的 from+100 条数据，然后协同节点把收集到的 n×(from+100)条数据聚合起来再进行一次排序。
每次返回 from+1 开始的 100 条数据，并且要重复执行 100 次。
如果使用 Scroll 查询：在各个分片上查询 10000 条数据，协同节点聚合 n×10000 条数据进行合并、排序，并将排名前 10000 的结果快照起来。这样做的好处是减少了查询和排序的次数。
```
* 缺点是每次查询时需要指定scroll_id
curl -XGET 'localhost:9200/twitter/tweet/_search?scroll=1m&pretty' -H 'Content-Type: application/json' -d'
{
"size": 100,
"query": {
"match" : {
"title" : "elasticsearch"
}
}
}'
curl -XGET 'localhost:9200/_search/scroll?pretty' -H 'Content-Type: application/json' -d'
{
"scroll" : "1m",
"scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
}
'
