elasticsearch 源代码分析之ScanScroll

原创
2014/10/27 16:57
阅读数 715

ScanScroll 的特点

  1. 优点

    1. 速度快

    2. 大数据量

  2. 缺点

    1. 不支持排序

    2. 不支持分页

    3. 不支持评分

    4. 不支持续查


使用场景

        看起来,缺点要比优点多很多,不过它很有用。如果说BULK是为了快速入库存在的,那SCAN就是为了快速出库而诞生的。ES的查询性能优越,但是分析能力弱。所以会有,比如把ES的数据拉到Hadoop集群去分析计算的需求,当然这个已经有现成的插件了,不出所料也是用的SCAN。如果SCAN遭遇BULK, 也就是ES到ES的话,它有另一个更熟悉的名字叫 复制表。

使用方法

def scanTest():
    searchRes = es.search(index="users",size=10,body={"query": {"match_all": {}}},search_type="scan",scroll="10s")
    while True:
        scrollRes=es.scroll(scroll_id=searchRes["_scroll_id"],scroll="10s",ignore=[400, 404])
        res_list = scrollRes["hits"]["hits"]
        if not len(res_list):
            break;
        for res in res_list:
            print res["_source"]["userName"]

原理流程

        整个流程比较清晰,先count一个总数,下面每次scroll,返回size*分片数的数据,直到遍历全部。SCAN是支持查询偏好preference的,可以指定分片,所以有人说的size*主分片数,是不准确的,这个很容易验证。

  • 第一阶段:Search

    • 用TotalHitCountCollector统计下总数,并且确定(节点,查询上下文ID),Base64编码成ScrollId返回

  • 第二阶段:SearchScroll

    • 根据ScrollId去每个节点,找到查询上下文ID执行XFilteredQuery,收集结果,合并返回


        第一阶段除了返回总数,还有一个很神秘的ScrollId,这个ScrollId长成这样,很像Base64编码过的。一定不是ID那么简单,了解一番,果不其然 ,主要有3个部分组成type,context,attributes

      1. type 分别是queryThenFetch,queryAndFetch,scan,我们这里讲的是scan

      2. attributes 只有一个元素,total_hits

      3. context 是个分片的元组,有2个元素,分片 = [节点ID,查询上下文ID]

        ScrollId 是个很容易会暴露秘密的东西,我们会发现ScrollId 依赖的节点ID和查询上下文ID都是变量,查询上下文ID,每次请求都要递增的。所以每次请求的ScrollId 都不一样,导致了如果在我们的SCAN过程意外终止,我们可能需要重新来过。

        每次SCAN,处理Scroll跳到下一页去,我们自己指定form是无效的。

//SearchService
private void processScroll(InternalScrollSearchRequest request, SearchContext context) {
        // process scroll
        context.from(context.from() + context.size());
        context.scroll(request.scroll());
        // ...
 }

//ScanContext
public TopDocs execute(SearchContext context) throws IOException {
        ScanCollector collector = new ScanCollector(readerStates, context.from(), context.size(), context.trackScores());
        Query query = new XFilteredQuery(context.query(), new ScanFilter(readerStates, collector));
        try {
            context.searcher().search(query, collector);
        } catch (ScanCollector.StopCollectingException e) {
            // all is well
        }
        return collector.topDocs();
}

        自定义的Filter,Collector,执行搜索,收集那一页的结果集

 //ScanContext
 public void collect(int doc) throws IOException {
            if (counter >= from) {
                docs.add(new ScoreDoc(docBase + doc, trackScores ? scorer.score() : 0f));
            }
            readerState.count++;
            counter++;
            if (counter >= to) {
                throw StopCollectingException;
            }
}


        根据以往数据库的认识,count操作总是很慢的,这让我很担心会延长整个查询的时间,后来我发现这种担心是多余的,对于全文检索count操作是很快速的。根据测试,17亿数据24个分片,平均每个分片的count时间在200ms到700ms之间,最糟糕的情况下总数也能在1秒内返回,这对于整个查询时间而言是可以接受的。


未完待续。。。怎么处理偏好,怎么合并结果集,不在这里讲,在6大查询类型里讲。这里主要想讲清楚 ,SCAN的特点。写到这里我思绪断掉了,好像讲清楚了,又觉得落下什么了。

展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部