背景:我们的集群单个索引没有副本的情况下一天的数据量有60G,有三亿多条数据,设置了6个分片。一般会查询三天左右的数据。会基于@timestamp进行range范围过滤以及排序。
第一次查询时,速度非常慢,经常timeout,大约要40秒以上,使用profile分析,发现时间主要是在sort和range上。
然后发现通过在index的时候就进行排序(ES6以后的新特性),可以较好的解决这个问题,sort的问题解决了,但是range的时候仍然很慢。
问题1:index sorting说是直接使用@timestamp字段进行排序存储的,这样进行range的时候不应该很快吗?
问题2:底层range的原理到底是怎样的,和存储的顺序有关系吗?
问题3:有没有建议的其他解决方案?
非常感谢,求大神帮助!
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:有没有建议的其他解决方案?
非常感谢,求大神帮助!
1 个回复
locatelli
赞同来自: suisuimu
但是,上面说的只是相对慢的情况,如果这个查询本身整体慢,那么就要看是否有其它方面影响了速度https://www.elastic.co/guide/e ... .html