威廉希尔亚洲威廉希尔亚洲


威廉希尔博

Elastic Stack-Elasticsearch使用介绍(三)

一、前言

    上一篇说了这篇要讲解Search机制,但是在这个之前我们要明白下文件是怎么存储的,我们先来讲文件的存储然后再来探究机制;

二、文档存储

    之前说过文档是存储在分片上的,这里要思考一个问题:文档是通过什么方式去分配到分片上的?我们来思考如下几种方式:

    1.通过文档与分片取模实现,这样做的好处在于可以将文档平均分配到所以的分片上;

    2.随机分配当然也可以,这种可能造成分配不均,照成空间浪费;

    3.轮询这种是最不可取的,采用这种你需要建立文档与分片的映射关系,这样会导致成本太大;

    经过一轮强烈的思考,我们选择方案1,没错你想对了,这里Elasticsearch也和我们思考的是一样的,我们来揭露下他分配的公式:

    shard_num = hash(_routing)%num_primary_shards

    routing是一个关键参数,默认是文档id,可以自行指定;

    number_of_primary_shard 主分片数;

    之前我们介绍过节点的类型,接下来我们来介绍下,当文档创建时候的流程:

    假设的情况:1个主节点和2个数据节点,1个副本:

    文档的创建:

    1.客户端向节点发起创建文档的请求;

    2.通过routing计算文档存储的分片,查询集群确认分片在数据节点1上,然后转发文档到数据节点1;

    3.数据节点1接收到请求创建文档,同时发送请求到该住分片的副本;

    4.主分片的副本接收到请求则开始创建文档;

    5.副本分片文档完成以后发送成功的通知给主分片;

    6.当主分片接收到创建完成的信息以后,发送给节点创建成功的通知;

    7.节点返回结果给客户端;

三、Search机制

    搜索的类型其实有2种:Query Then Ferch和DFS Query Then Ferch,当我们明白如何存储文件的是时候,再去理解这两种查询方式会很简单;

    Query Then Ferch

    Search在执行的时候分为两个步骤运作Query(查询)和Fetch(获取),基本流程如下:

    1.将查询分配到每个分片;

    2.找到所有匹配的文档,并在当前的分片的文档使用Term/Document Frequency信息进行打分;

    3.构建结果的优先级队列(排序,分页等);

    4.将结果的查询到的数据返回给请求节点。请注意,实际文档尚未发送,只是分数;

    5.将所有分片的分数在请求节点上合并和排序,根据查询条件选择文档;

    6.最后从筛选出的文档所在的各个分片中检索实际的文档;

    7.结果将返回给客户端;

    DFS Query Then Ferch

    DFS是在进行真正的查询之前, 先把各个分片的词频率和文档频率收集一下, 然后进行词搜索的时候, 各分片依据全局的词频率和文档频率进行搜索和排名,基本流程如下:

    1.提前查询每个shard,询问Term和Document frequency;

    2.将查询分配到每个分片;

    3.找到所有匹配到的文档,并且在所有分片的文档使用Term/Document Frequency信息进行打分;

    4.构建结果的优先级队列(排序,分页等);

    5.将结果的查询到的数据返回给请求节点。请注意,实际文档尚未发送,只是分数;

    6.来自所有分片的分数合并起来,并在请求节点上进行排序,文档被按照查询要求进行选择;

    7.最终,实际文档从他们各自所在的独立的分片上检索出来;

    8.结果被返回给客户端;

    总结下,根据上面的两种查询方式来看的DFS查询得分明显会更接近真实的得分,但是DFS 在拿到所有文档后再从新完整的计算一次相关性算分,耗费更多的cpu和内存,执行性能也比较低下,一般不建议使用。使用方式如下:

    

   另外要是当文档数据不多的时候可以考虑使用一个分片;

   这个地方我们在做一些深入的思考:我们搜索的时候是通过倒排索引,但是倒排索引一旦建立是不能修改的,这样做有那些好处坏处?

   好处:

   1.不用考虑并发写入文件的问题,杜绝锁机制带来的性能问题;

   2.文件不再更改,可以充分利用文件系统缓存,只需载入一次,只要内容足够,对该文件的读取都会从内存中读取,性能高;

   坏处:

   写入新文档时,必须重新构建倒排索引文件,然后替换老文件后,新文档才能被检索,导致文档实时性差;

   问题:

   对于新插入文档的时候写入倒排索引,导致倒排索引重建的问题,假如根据新文档来重新构建倒排索引文件,然后生成一个新的倒排索引文件,再把用户的原查询切掉,切换到新的倒排索引。这样开销会很大,会导致实时性非常差。

  

 Elasticsearch如何解决文件搜索的实时性问题:

 

   新文档直接生成新的倒排索引文件,查询的时候同时查询所有的倒排文件,然后做结果的汇总计算即可,ES是是通过Lucene构建的,Lucene就是通过这种方案处理的,我们介绍下Luncene构建文档的时候的结构:

   1.Luncene中单个倒排索引称为Segment,合在一起称为Index,这个Index与Elasticsearch概念是不相同的,Elasticsearch中的每个Shard对应一个Lucene Index;

   2.Lucene会有个专门文件来记录所有的Segment信息,称为Commit Point,用来维护Segment的信息;

   

   

    Segment写入磁盘的时候过程中也是比较慢的,Elasticsearch提供一个Refresh机制,是通过文件缓存的机制实现的,接下我们介绍这个过程:

    1.在refresh之前的文档会先存储在一个Buffer里面,refresh时将Buffer中的所有文档清空,并生成Segment;

    2.Elasticsearch默认每1秒执行一次refresh,因此文档的实时性被提高到1秒,这也是Elasticsearch称为近实时(Near Real Time)的原因;

    Segment写入磁盘前如果发生了宕机,那么其中的文档就无法恢复了,怎么处理这个问题?

    Elasticsearch引入translog(事务日志)机制,translog的写入也可以设置,默认是request,每次请求都会写入磁盘(fsync),这样就保证所有数据不会丢,但写入性能会受影响;如果改成async,则按照配置触发trangslog写入磁盘,注意这里说的只是trangslog本身的写盘。Elasticsearch启动时会检查translog文件,并从中恢复数据;

    还有一种机制flush机制,负责将内存中的segment写入磁盘和删除旧的translog文件;

    

    新增的时候搞定了,那删除和更新怎么办?

    删除的时候,Lucene专门维护一个.del文件,记录所有已经删除的文档,del文件上记录的是文档在Lucene内部的id,查询结果返回前过滤掉.del中的所有文档;

    更新就简单了,先删除然后再创建;

    随着Segment增加,查询一次会涉及很多,查询速度会变慢,Elasticsearch会定时在后台进行Segment Merge的操作,减少Segment的数量,通过force_merge api可以手动强制做Segment Merge的操作;

    另外可以参考下这篇文段合并;

四、下节预告

   本来还想说下聚合、排序方面的查询,但是看篇幅也差不多了,留点时间出去浪,最近不光要撒狗粮,也要撒知识,国庆节期间准备完成Elastic Stack系列,下面接下来还会有4-5篇左右,欢迎大家加群438836709,欢迎大家关注我公众号!

   

欢迎阅读本文章: 张宝松

威廉希尔代理

威廉希尔博