es实战之查询大量数据

Posted 匠心数据

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了es实战之查询大量数据相关的知识,希望对你有一定的参考价值。

背景

项目中已提供海量日志数据的多维实时查询,客户提出新需求:将数据导出。

将数据导出分两步:

  1. 查询大量数据
  2. 将数据生成文件并下载

本文主要探讨第一步,在es中查询大量数据或者说查询大数据集。

es支持的查询数量

es默认支持的查询数量或者说查询深度是10,000。

可以动态修改max_result_window这个参数的设置,默认为10,000。

PUT xz-logs/_settings?preserve_existing=true
{
  "index.max_result_window" : "10000000"
}

es search api

from + size

GET /_search
{
    "from" : 0, "size" : 10,
    "query" : {
        "term" : { "user" : "kimchy" }
    }
}

当Elasticsearch响应请求时,它必须确定docs的顺序,全局排序响应结果。
如果请求的页数较少时,假设每页10个docs——即pageSize=10, 此时Elasticsearch不会有什么问题。

但若取的页数较大时(深分页),如请求第20页,Elasticsearch不得不取出所有分片上的第1页到第20页的所有docs,假设你有16个分片,则需要在coordinate node 汇总到 shards* (from+size)条记录,即需要 16*(20+10)记录后做一次全局排序,再最终取出 from后的size条结果作为最终的响应。

所以:当索引非常非常大(千万或亿),是无法安装 from + size 做深分页的,分页越深则越容易OOM,即便不OOM,也是很消耗CPU和内存资源的。

scroll

scroll类似于数据库中的游标。

游标查询允许我们 先做查询初始化,然后再批量地拉取结果。 这有点儿像传统数据库中的 cursor 。

游标查询会取某个时间点的快照数据。 查询初始化之后索引上的任何变化会被它忽略。 它通过保存旧的数据文件来实现这个特性,结果就像保留初始化时的索引 视图 一样。

深度分页的代价根源是结果集全局排序,如果去掉全局排序的特性的话查询结果的成本就会很低。 游标查询用字段 _doc 来排序。 这个指令让 Elasticsearch 仅仅从还有结果的分片返回下一批结果。

第一次查询

GET /old_index/_search?scroll=1m 
{
    "query": { "match_all": {}},
    "sort" : ["_doc"], 
    "size":  1000
}

第二次查询

GET /_search/scroll
{
    "scroll": "1m", 
    "scroll_id" : "cXVlcnlUaGVuRmV0Y2g7NTsxMDk5NDpkUmpiR2FjOFNhNnlCM1ZDMWpWYnRROzEwOTk1OmRSamJHYWM4U2E2eUIzVkMxalZidFE7MTA5OTM6ZFJqYkdhYzhTYTZ5QjNWQzFqVmJ0UTsxMTE5MDpBVUtwN2lxc1FLZV8yRGVjWlI2QUVBOzEwOTk2OmRSamJHYWM4U2E2eUIzVkMxalZidFE7MDs="
}

Scanning Scroll API

如果只对查询结果感兴趣而不关心结果的顺序,可以使用更高效的scanning scroll。使用方法非常简单,只需在查询语句后加上“search_type=scan”即可。

search after(5.0新特性)

search_after is not a solution to jump freely to a random page but rather to scroll many queries in parallel. It is very similar to the scroll API but unlike it, the search_after parameter is stateless, it is always resolved against the latest version of the searcher. For this reason the sort order may change during a walk depending on the updates and deletes of your index.

search_after类似于scroll,不同之处是:search_after是无状态的,它总是针对最新版本的搜索器进行解析。由于更新或者删除索引,搜索的排序结果可能会发生变化。

bulk

bulk是将多个请求合并成一个请求,如下所示:

POST _bulk
{ "index" : { "_index" : "test", "_type" : "_doc", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_type" : "_doc", "_id" : "2" } }
{ "create" : { "_index" : "test", "_type" : "_doc", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_type" : "_doc", "_index" : "test"} }
{ "doc" : {"field2" : "value2"} }

其他

插件: elasticsearch-dataformat

实际使用过程中,该插件不好用。如果带查询条件,数据无法导出。查看其依赖的jar包,估计其调用poi来生成csv文件, 估计速度快不了。

这种插件做demo可以,实际生成中,不太敢使用,因为不可控因素太多。

总结

综上所述,最后采用scroll api来解决es查询大量数据的问题。不过数据量大一点,查询时间就比较长,在本人的集群中,查询10w条,需要将近1分钟的时间。(附本人集群:3个节点。每个节点配置为cpu 8核,heap size 16G,每个索引有5个分片、1个副本。数据量每天4500w)

以上是关于es实战之查询大量数据的主要内容,如果未能解决你的问题,请参考以下文章

ES实战Search的滚动查询(Scroll)

译ECMAScript 2016, 2017, 2018 新特性之必读篇

es实战-分片分配失败解决方案

《ElasticSearch6.x实战教程》之简单搜索Java客户端(上)

ES实战Term查询未命中问题

ES实战Term查询未命中问题