我们在 elastic(1.6.2) 中存储了约 20M(酒店优惠)文档,重点是按多个字段(duration、start_date、adults、kids
)对文档进行分组,然后选择一个最便宜的从每个组中提供。我们必须按成本字段对这些结果进行排序。
为了避免子聚合,我们将目标字段值联合到一个名为 default_group_field
的集合中,方法是用点 (.
) 连接它们。
该字段的映射如下所示:
"default_group_field": {
"index": "not_analyzed",
"fielddata": {
"loading": "eager_global_ordinals"
},
"type": "string"
}
我们执行的查询如下所示:
{
"size": 0,
"aggs": {
"offers": {
"terms": {
"field": "default_group_field",
"size": 5,
"order": {
"min_sort_value": "asc"
}
},
"aggs": {
"min_sort_value": {
"min": {
"field": "cost"
}
},
"cheapest": {
"top_hits": {
"_source": {}
},
"sort": {
"cost": "asc"
},
"size": 1
}
}
}
}
},
"query": {
"filtered": {
"filter": {
"and": [
...
]
}
}
}
}
问题是这样的查询需要几秒钟(2-5 秒)才能加载。
但是,一旦我们在不使用聚合的情况下执行查询,我们就会在不到 100 毫秒的时间内获得适量的结果(比如 “total”: 490
)。
{
"took": 53,
"timed_out": false,
"_shards": {
"total": 6,
"successful": 6,
"failed": 0
},
"hits": {
"total": 490,
"max_score": 1,
"hits": [...
但是聚合需要 2 秒:
{
"took": 2158,
"timed_out": false,
"_shards": {
"total": 6,
"successful": 6,
"failed": 0
},
"hits": {
"total": 490,
"max_score": 0,
"hits": [
]
},...
处理中等数量的过滤文档并从每组中选择最便宜的文档似乎不应该花这么长时间。它可以在应用程序内部完成,这对我来说似乎是一个丑陋的 hack。
日志中满是这样的行:
[DEBUG][index.fielddata.plain] [Karen Page] [offers] Global-ordinals[default_group_field][2564761] 花费了 2453 毫秒
这就是我们更新映射以在索引更新时执行急切的 global_ordinals 重建的原因,但这并未对查询时间产生显着影响。
有没有什么方法可以加速这种聚合,或者有什么方法可以告诉 elastic 只对过滤后的文档进行聚合。
或者可能还有另一个来源导致如此长的查询执行?非常感谢任何想法!
最佳答案
再次感谢您的努力。
终于解决了主要问题,性能恢复正常。
简而言之,我们做了以下事情:
- 将 default_group_field
的映射更新为 Long
类型
- 压缩 default_group_field
值,使其匹配类型 Long
一些解释:
字符串字段的聚合需要对其进行一些工作。正如我们从日志中看到的那样,为具有很大差异的字段构建 Global Ordinals
非常昂贵。事实上,我们只对提到的字段进行聚合。尽管如此,使用 String
类型并不是很有效。
所以我们将映射更改为:
default_group_field: {
type: 'long',
index: 'not_analyzed'
}
这样我们就不会触及那些昂贵的操作。
在此之后,相同的查询时间减少到约 100 毫秒。它还降低了 CPU 使用率。
PS 1
我从 global ordinals 上的文档中获得了很多信息
PS 2
我仍然不知道如何使用 String
类型的字段来绕过这个问题。如果您有任何想法,请发表评论。
关于elasticsearch - 非常慢的 elasticsearch 术语聚合。如何提高?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37615092/