Hello,World

ES7,date类型的range速度较慢

Elasticsearch | 作者 suisuimu | 发布于2020年10月27日 | 阅读数:3212

背景:我们的集群单个索引没有副本的情况下一天的数据量有60G,有三亿多条数据,设置了6个分片。一般会查询三天左右的数据。会基于@timestamp进行range范围过滤以及排序。
GET kublog-app/_search?timeout=50s
{
"profile": "true",
"query": {
"bool": {
"filter": [
{
"range": {
"@timestamp": {
"gte": "1603468800000",
"lte": "1603641600000"
}
}
}
],
"must": [
{
"query_string": {
"default_field": "log",
"query": "info AND service"
}
},
{
"term": {
"kubernetes.labels.app": {
"value": "XXXXX"
}
}
}
]
}
},
"from": 1000,
"size": 20,
"sort": [
{
"@timestamp": {
"order": "desc"
}
}
]
}

第一次查询时,速度非常慢,经常timeout,大约要40秒以上,使用profile分析,发现时间主要是在sort和range上。

然后发现通过在index的时候就进行排序(ES6以后的新特性),可以较好的解决这个问题,sort的问题解决了,但是range的时候仍然很慢。
问题1:index sorting说是直接使用@timestamp字段进行排序存储的,这样进行range的时候不应该很快吗?
问题2:底层range的原理到底是怎样的,和存储的顺序有关系吗?
问题3:有没有建议的其他解决方案?
非常感谢,求大神帮助!
 
已邀请:

locatelli

赞同来自: suisuimu

对date类型进行time range query的时候,内部的处理逻辑可能会有需要对整个shard进行exists()操作的情况,这个操作在7.9以前的版本里会比较慢,因为它不但要查询还要cache查询的结果,而cache这个过程相比较查询本身会慢得多。在7.9及以后的版本里取消了cache这一步,所以理论上会快很多。
 
但是,上面说的只是相对慢的情况,如果这个查询本身整体慢,那么就要看是否有其它方面影响了速度https://www.elastic.co/guide/e ... .html

要回复问题请先登录注册