collapse 在es的性能 elasticsearch type类型

admin2024-05-30  20

Search的面临的问题:

elasticsearch从出现的那天起就为分布式而生,分布式是把双刃剑,分布式强大的可扩展性和高效的性能再给elasticsearch带来强大高效的处理能力的同时,也带来了分布式常规需要解决的问题,即数据都需要在各个节点或者实例分散计算(分布式典型的移动计算而非移动数据的思想),这种特点在某些场景下可能会带来一些相对麻烦的处理。

elasticsearch的search分两步:

1、将search请求发送到各个节点的各个分片,在每个分片上进行计算,这个过程被称为Scatter(类似于mapreduce的map)

2、将第一步的结果汇集到一个节点上进行汇集,再整体进行一次计算,得到最终结果,这个过程被称为Gather(类似于mapreduce的reduce)

下面通过一个栗子来说明:

如果计算所有数据Sum,那没有任何问题,每个节点Sum后,汇集到一个节点进行最终的Sum得到最终的记过,水到渠成;

但是如果是TOP N的情况可能就会麻烦很多,有两种方法可以实现TOP N

1、和上面Sum的方式一样,先取到每个节点的TOP N,然后将所有数据在一个节点汇集后,再做一次TOP N得到最终结果;这种方式对应下面的QUERY_AND_FETCH方式,好处是仅需要访问一次实际数据节点即可以得到最后的结果,缺点是IO会是最终分片数目的几倍,倍数取决于shard个数 

2、在每个节点获得到TOP N相关的元数据信息(最小能描述TOP N的数据,而非完整数据),在一个节点汇集后,计算出最终需要的TOP N信息,再去对应的节点去取最终的结果;这种方式对应下面的QUERY_THEN_FETCH方式,好处是能减少IO的开销和浪费,缺点是需要访问实际数据节点两次才能拿到最终的结果

由于elasticsearch无法确定两者的优劣,而且不同的场景有着不同的选择,于是elasticsearch将选择权交给了用户,让用户自己根据实际情况来决定。

 

Search Type定义

search type,顾名思义就是elasticsearch进行search时设置的search类型,从elasticsearch诞生至今一共有四种search type:

DFS_QUERY_THEN_FETCH,QUERY_THEN_FETCH,DFS_QUERY_AND_FETCH,QUERY_AND_FETCH

其中DFS_QUERY_AND_FETCH,QUERY_AND_FETCH两种类型在5.3版本之前的Search Request中会被用到,5.3版本到6.X版本只支持DFS_QUERY_THEN_FETCH,QUERY_THEN_FETCH,DFS_QUERY_AND_FETCH被废弃,QUERY_AND_FETCH过期,其中默认的search type为QUERY_THEN_FETCH,到7.X版本,再次废弃了QUERY_AND_FETCH,对应的源码被封装在了elasticsearch包里面的枚举类SearchType中,源码如下(6.6.2版本):

package org.elasticsearch.action.search;

/**
 * Search type represent the manner at which the search operation is executed.
 *
 *
 */
public enum SearchType {
    /**
     * Same as {@link #QUERY_THEN_FETCH}, except for an initial scatter phase which goes and computes the distributed
     * term frequencies for more accurate scoring.
     */
    DFS_QUERY_THEN_FETCH((byte) 0),
    /**
     * The query is executed against all shards, but only enough information is returned (not the document content).
     * The results are then sorted and ranked, and based on it, only the relevant shards are asked for the actual
     * document content. The return number of hits is exactly as specified in size, since they are the only ones that
     * are fetched. This is very handy when the index has a lot of shards (not replicas, shard id groups).
     */
    QUERY_THEN_FETCH((byte) 1),
    // 2 used to be DFS_QUERY_AND_FETCH

    /**
     * Only used for pre 5.3 request where this type is still needed
     */
    @Deprecated
    QUERY_AND_FETCH((byte) 3);

    /**
     * The default search type ({@link #QUERY_THEN_FETCH}.
     */
    public static final SearchType DEFAULT = QUERY_THEN_FETCH;

    /**
     * Non-deprecated types
     */
    public static final SearchType [] CURRENTLY_SUPPORTED = {QUERY_THEN_FETCH, DFS_QUERY_THEN_FETCH};

    private byte id;

    SearchType(byte id) {
        this.id = id;
    }

    /**
     * The internal id of the type.
     */
    public byte id() {
        return this.id;
    }

    /**
     * Constructs search type based on the internal id.
     */
    public static SearchType fromId(byte id) {
        if (id == 0) {
            return DFS_QUERY_THEN_FETCH;
        } else if (id == 1
            || id == 3) { // TODO this bwc layer can be removed once this is back-ported to 5.3 QUERY_AND_FETCH is removed now
            return QUERY_THEN_FETCH;
        } else {
            throw new IllegalArgumentException("No search type for [" + id + "]");
        }
    }

    /**
     * The a string representation search type to execute, defaults to {@link SearchType#DEFAULT}. Can be
     * one of "dfs_query_then_fetch"/"dfsQueryThenFetch", "dfs_query_and_fetch"/"dfsQueryAndFetch",
     * "query_then_fetch"/"queryThenFetch" and "query_and_fetch"/"queryAndFetch".
     */
    public static SearchType fromString(String searchType) {
        if (searchType == null) {
            return SearchType.DEFAULT;
        }
        if ("dfs_query_then_fetch".equals(searchType)) {
            return SearchType.DFS_QUERY_THEN_FETCH;
        } else if ("query_then_fetch".equals(searchType)) {
            return SearchType.QUERY_THEN_FETCH;
        } else {
            throw new IllegalArgumentException("No search type for [" + searchType + "]");
        }
    }
    
}

按照源码的注释,可以得到如下的解释:

1、query and fetch

向索引的所有分片(shard)都发出查询请求,各分片返回的时候把元素文档(document)和计算后的排名信息一起返回。这种搜索方式是最快的。因为相比下面的几种搜索方式,这种查询方法只需要去shard查询一次。但是各个shard返回的结果的数量之和可能是用户要求的size的n倍。

2、query then fetch(默认的搜索方式)

如果你搜索时,没有指定搜索方式,就是使用的这种搜索方式。这种搜索方式,大概分两个步骤,第一步,先向所有的shard发出请求,各分片只返回”足够“(预估是排序、排名以及分值相关)的信息(注意,不包括文档document),然后按照各分片返回的分数进行重新排序和排名,取前size个文档。然后进行第二步,去相关的shard取document。这种方式返回的document与用户要求的size是相等的。

3、DFS query and fetch

这种方式比第一种方式多了一个initial scatter phrase步骤,有这一步,可以使distributed term frequencies for more accurate scoring达到更好的效果

4、DFS query then fetch

这种方式比第二种方式多了一个initial scatter phrase步骤

Search Type总结

存在即是合理,这说明在不同的场景下,不同的search type都会有自己发挥的空间,简单来说:

1、如果search命中的shard较少,那么QUERY_AND_FETCH的效率理论上应该会比较好;反之,如果search命中的shard较多,那么QUERY_THEN_FETCH的效率理论上应该会比较好,两者的差别就在IO的消耗以及多一次查询两者之间的差值。这个临界值需要根据实际的集群以及数据情况进行测试

2、按照当前新版本SearchType的演进来看,显而易见的是,elasticsearch在经过优化后,两次查询带来的消耗明显已经优于IO的消耗了,继而SearchType的默认值也就变成了QUERY_THEN_FETCH,而QUERY_AND_FETCH在新版本中已经被废弃了,这场效率之争在现在版本看来还是QUERY_THEN_FETCH取得了阶段性的胜利

3、对于DFS相关的方式,笔者建议除非是对全文匹配的精确度有着极高的要求,否则其他对全文匹配精确度要求不高甚至不care全文匹配的场景,直接使用DEFAULT即可

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明原文出处。如若内容造成侵权/违法违规/事实不符,请联系SD编程学习网:675289112@qq.com进行投诉反馈,一经查实,立即删除!