6 Elasticsearch 篇之深入了解 Search 的运行机制

文章目录

    • Query-Then-Fetch
      • Search的运行机制-Query阶段
      • Search的运行机制-Fetch阶段
      • Search的运行机制-相关性算分问题
      • sorting-doc-values-fielddata
      • Fileddata vs DocValues
      • docvalue_fields
    • 分页与遍历-fromsize
    • 分页与遍历-scroll
    • 分页与遍历-search_after

Query-Then-Fetch

Search的运行机制
◆Search执行的时候实际分两个步骤运作的

  • Query阶段
  • Fetch阶段

◆在es里被称为Query-Then-Fetch机制

Search的运行机制-Query阶段

  1. node3在接收到用户的search请求后,会先进行Query阶段(此时是CoordinatingNode角色)
  2. node3在6个主副分片中随机选择3个分片,发送search request
  3. 被选中的3个分片会分别执行查询并排序,返回from+size个文档Id和排序值
  4. node3整合3个分片返回的from+size个文档Id ,根据排序值排序后选取from到from+size的文档Id
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第1张图片

Search的运行机制-Fetch阶段

node3根据Query阶段获取的文档Id列表去对应的shard上获取文档详情数据

  1. node3向相关的分片发送multi-get请求
  2. 3个分片返回文档详细数据
  3. node3拼接返回的结果并返回给客户
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第2张图片

Search的运行机制-相关性算分问题

·相关性算分在shard与shard间是相互独立的,也就意味着同一个Term的IDF等值在不同shard上是不同的。文档的相关性算分和它所处的shard相关

·在文档数量不多时,会导致相关性算分严重不准的情况发生

·解决思路有两个:

  • 一是设置分片数为1个,从根本上排除问题,在文档数量不多的时候可以考虑该方。案,比如百万到千万级别的文档数量
  • 二是使用DFS Query-then-Fetch查询方式.DFS Query-then-Fetch是在拿到所有文档后再重新完整的计算一次相关性算分,耗费更多的cpu和内存,执行性能也比较低下,一般不建议使用。使用方式如下:
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第3张图片

sorting-doc-values-fielddata

es默认会采用相关性算分排序,用户可以通过设定sorting参数来自行设定排序规则
6 Elasticsearch 篇之深入了解 Search 的运行机制_第4张图片
6 Elasticsearch 篇之深入了解 Search 的运行机制_第5张图片
按照字符串排序比较特殊,因为es有text和keyword两种类型,针对text类型排序,如下所示:
6 Elasticsearch 篇之深入了解 Search 的运行机制_第6张图片
针对keyword类型排序,可以返回预期结果
6 Elasticsearch 篇之深入了解 Search 的运行机制_第7张图片
排序的过程实质是对字段原始内容排序的过程,这个过程中倒排索引无法发挥作用,需要用到正排索引,也就是通过文档Id和字段可以快速得到字段原始内容。

.es对此提供了2种实现方式:

  • fielddata默认禁用
  • doc values默认启用,除了text类型
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第8张图片

Fileddata vs DocValues

6 Elasticsearch 篇之深入了解 Search 的运行机制_第9张图片
. Fielddata默认是关闭的,可以通过如下api开启:

  • 此时字符串是按照分词后的term排序,往往结果很难符合预期
  • 一般是在对分词做聚合分析的时候开启,
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第10张图片
    Doc Values默认是启用的,可以在创建索引的时候关闭:-如果后面要再开启doc values ,需要做reindex操作
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第11张图片

docvalue_fields

可以通过该字段获取fielddata或者doc values中存储的内容
6 Elasticsearch 篇之深入了解 Search 的运行机制_第12张图片

分页与遍历-fromsize

es提供了3种方式来解决分页与遍历的问题:

  • from/size
  • scroll
  • search_after

from/size
最常用的分页方案

  • from指明开始位置
  • size指明获取总数
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第13张图片
    深度分页是一个经典的问题:在数据分片存储的情况下如何获取前1000个文档?
  • 获取从990-1000的文档时,会在每个分片上都先获取1000个文档,然后再由.Coordinating Node聚合所有分片的结果后再排序选取前1000个文档
  • 页数越深,处理文档越多,占用内存越多,耗时越长,尽量避免深度分页, es通过 index.max_result_window限定最多到10000条数据
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第14张图片
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第15张图片

分页与遍历-scroll

·遍历文档集的api ,以快照的方式来避免深度分页的问题

  • 不能用来做实时搜索,因为数据不是实时的
  • 尽量不要使用复杂的sort条件,使用_doc最高效
  • 使用稍嫌复杂

第一步需要发起1个scroll search ,如下所示:

  • es在收到该请求后会根据查询条件创建文档Id合集的快照
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第16张图片

第二步调用scroll search的api ,获取文档集合,如下所示:

  • 不断迭代调用直到返回hits.hits数组为空时停止
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第17张图片
    过多的scroll调用会占用大量内存,可以通过clear api删除过多的scroll快照:
    6 Elasticsearch 篇之深入了解 Search 的运行机制_第18张图片

分页与遍历-search_after

·避免深度分页的性能问题,提供实时的下一页文档获取功能

  • 缺点是不能使用from参数,即不能指定页数
  • 只能下一页,不能上一页
  • 使用简单

.第一步为正常的搜索,但要指定sort值,并保证值唯一
·第二步为使用上一步最后一个文档的sort值进行查询
6 Elasticsearch 篇之深入了解 Search 的运行机制_第19张图片
如何避免深度分页问题?
通过唯一排序值定位将每次要处理的文档数都控制在size内
6 Elasticsearch 篇之深入了解 Search 的运行机制_第20张图片
应用场景
6 Elasticsearch 篇之深入了解 Search 的运行机制_第21张图片
https://www.elastic.co/guide/en/elasticsearch/reference/current/search.html search api官方文档
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html 写查询语句官网

你可能感兴趣的:(Elastic学习笔记)