Elasticsearch:过滤搜索结果 – filter 及 post_filter
2022年8月25日 | by mebius
在 Elasticsearch 中,过滤搜索的结果是我们经常要做的事。在我刚开始接触 Elasticsearch,我就了解到有两种可以过滤搜索结果的方法。当时还不是很明白,为什么有的地方用 filter,而有的地方需要使用到 post filter。在今天的文章中,我来用一个鲜活的例子来进行展示。
总体说来,我们可以使用如下的两个方法来过滤搜索的结果:
- 使用带有 filter 子句的布尔查询。 搜索请求将布尔过滤器应用于搜索命中和聚合。
- 使用搜索 API 的 post_filter 参数。 搜索请求仅将 post filters 应用于搜索命中,而不是聚合。 你可以使用 post filters 根据更广泛的结果集计算聚合,然后进一步缩小结果。讲得通俗一点:在已经计算聚合之后,post filter 将应用于搜索请求最后的搜索命中。从这里的描述中,我们可以看出来,post filters 的使用和 aggregation 相关。
你还可以在 post filter 之后重新对命中进行评分,以提高相关性并重新排序结果。
Post filter
当你使用 post_filter 参数过滤搜索结果时,会在计算聚合后过滤搜索命中。 Post filter 对聚合结果没有影响。
例如,你销售的衬衫具有以下属性:
PUT shirts
{
"mappings": {
"properties": {
"brand": { "type": "keyword"},
"color": { "type": "keyword"},
"model": { "type": "keyword"}
}
}
}
我们使用如下的命令来摄入 3 个文档:
PUT shirts/_doc/1?refresh
{
"brand": "gucci",
"color": "red",
"model": "slim"
}
PUT shirts/_doc/2?refresh
{
"brand": "polo",
"color": "red",
"model": "large"
}
PUT shirts/_doc/3?refresh
{
"brand": "polo",
"color": "blue",
"model": "medium"
}
假想你有一个用户,他想买一个 red 的衣服。通常你会使用如下的 bool query:
GET shirts/_search?filter_path=**.hits
{
"query": {
"bool": {
"filter": [
{
"term": {
"color": "red"
}
}
]
}
}
}
上面显示的结果为:
{
"hits" : {
"hits" : [
{
"_index" : "shirts",
"_id" : "1",
"_score" : 0.0,
"_source" : {
"brand" : "gucci",
"color" : "red",
"model" : "slim"
}
},
{
"_index" : "shirts",
"_id" : "2",
"tgcode_score" : 0.0,
"_source" : {
"brand" : "polo",
"color" : "red",
"model" : "large"
}
}
]
}
}
显然搜索的结果显示了所有 red 的衣服。但是,你还想使用分面导航来显示用户可以单击的其他选项列表(比如大小尺寸)。 也许你有一个 model字段,允许用户将搜索结果限制为红色 Gucci T 恤或 Polo 的衣服。这可以通过 terms aggregation 来完成:
GET shirts/_search
{
"query": {
"bool": {
"filter": [
{
"term": {
"color": "red"
}
}
]
}
},
"aggs": {
"models": {
"terms": {
"field": "model"
}
}
}
}
在上面,我们通过 terms 聚合来显示各个尺寸(model)的文档数。最多的将排在前面。上面命令显示的结果为:
{
"took" : 0,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : 0.0,
"hits" : [
{
"_index" : "shirts",
"_id" : "1",
"_score" : 0.0,
"_source" : {
"brand" : "gucci",
"color" : "red",
"model" : "slim"
}
},
{
"_index" : "shirts",
"_id" : "2",
"_score" : 0.0,
"_source" : {
"brand" : "polo",
"color" : "red",
"model" : "large"
}
}
]
},
"aggregations" : {
"models" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "large",
"doc_count" : 1
},
{
"key" : "slim",
"doc_count" : 1
}
]
}
}
}
在上面,我们可以看出颜色为 red 的衣服,各个 model 的统计情况:large 及 slim个一件。显然这个是我们想要的结果。我们注意到的一点是 tgcodeaggregation 是基于前面的 boolean filter 所过滤后的数据集来进行统计的。其统计结果都是是红色的衣服。
但也许你还想告诉用户有多少 polo衬衫可供选择而不是所有的品牌。我们可以使用如下的搜索:
GET shirts/_search
{
"query": {
"bool": {
"filter": [
{
"term": {
"color": "red"
}
}
]
}
},
"aggs": {
"models": {
"terms": {
"field": "model"
}
}
},
"post_filter": {
"term": {
"brand": "polo"
}
}
}
在上面,我们使用 filter 把 red 的文档搜索出来,然后使用 terms aggregatiion 来对所有 red 的文档进行 model 的统计。我们接下来使用 post_filter 来对我们的搜索结果再次过滤。在这里需要注意的是:post_filter 的使用不会对 aggs 的结果产生任何的影响。如同上面写的顺序一样,post_filter 是在最后面运行的。上面的命令产生的结果是:
{
"took" : 0,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 0.0,
"hits" : [
{
"_index" : "shirts",
"_id" : "2",
"_score" : 0.0,
"_source" : {
"brand" : "polo",
"color" : "red",
"model" : "large"
}
}
]
},
"aggregations" : {
"models" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "large",
"doc_count" : 1
},
{
"key" : "slim",
"doc_count" : 1
}
]
}
}
}
如上所示,我们最终得到的搜索结果是 color:red 并且 brand:polo 的搜索结果,但是 aggregations 的结果是针对 color:red 而的出来的。我们可以看到上面的 slim 统计结果是来自 gucci 品牌的而不是 polo。
更为复杂的查询是这样的:
GET shirts/_search
{
"query": {
"bool": {
"filter": {
"term": { "brand": "polo" }
}
}
},
"aggs": {
"colors": {
"terms": { "field": "color" }
},
"color_red": {
"filter": {
"term": { "color": "red" }
},
"aggs": {
"models": {
"terms": { "field": "model" }
}
}
}
},
"post_filter": {
"term": { "color": "red" }
}
}
在上面,我们首先使用的 filter 来过滤数据集。只有 brand:polo 的文档才可以进行聚合。aggs 里含有两个 aggregations。一个是按照 colors 来进行的分类,另外一个是先过滤 red 颜色的 polo,然后再按照 model 进行分类。在最后,我们使用 post_fitler 来过滤结果。最终的搜索结果(位于 hits 里)是 brand:polo 并且 color:red:
{
"took" : 0,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 0.0,
"hits" : [
{
"_index" : "shirts",
"_id" : "2",
"_score" : 0.0,
"_source" : {
"brand" : "polo",
"color" : "red",
"model" : "large"
}
}
]
},
"aggregations" : {
"color_red" : {
"doc_count" : 1,
"models" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "large",
"doc_count" : 1
}
]
}
},
"colors" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [
{
"key" : "blue",
"doc_count" : 1
},
{
"key" : "red",
"doc_count" : 1
}
]
}
}
}
重新评分过滤的搜索结果
重新评分有助于提高精度,方法是仅对查询和 post_filter 阶段返回的顶部(例如 100 – 500 个)文档进行重新排序,使用另外的(通常成本更高)算法,而不是将成本高昂的算法应用于索引中的所有文档。
在每个分片返回结果以由处理整个搜索请求的节点排序之前,在每个分片上执行重新评分(rescore)请求。
目前 rescore API 只有一种实现:query rescorer,它使用查询来调整评分。 将来,可能会提供替代的记分器,例如,成对的记分器。
注tgcode意:如果 rescore 查询提供了显式 sort(除 _score 降序排列),则会引发错误。
注意:当向你的用户公开分页时,你不应在逐步浏览每个页面时更改 window_size(通过传递不同的值),因为这会改变热门点击,导致结果在用户浏览页面时发生混乱的变化。
query rescorer
查询 rescorer 仅对 query 和 post_filter 阶段返回的 Top-K 结果执行第二次查询。 将在每个分片上检查的文档数可以由 window_size 参数控制,默认为 10。
默认情况下,原始查询和重新评分查询的分数线性组合以生成每个文档的最终 _score。 原始查询和重新评分查询的相对重要性可以分别通过 query_weight 和 rescore_query_weight 来控制。 两者都默认为 1。
例如:
POST /_search
{
"query" : {
"match" : {
"message" : {
"operator" : "or",
"query" : "the quick brown"
}
}
},
"rescore" : {
"window_size" : 50,
"query" : {
"rescore_query" : {
"match_phrase" : {
"message" : {
"query" : "the quick brown",
"slop" : 2
}
}
},
"query_weight" : 0.7,
"rescore_query_weight" : 1.2
}
}
}
分数的组合方式可以通过 score_mode 来控制:
Score mode | 描述 |
---|---|
total | 添加原始分数和重新评分查询分数。 默认。 |
multiply | 将原始分数乘以重新评分查询分数。 对 function query 重新评分很有用。 |
avg | 平均原始分数和重新评分查询分数。 |
max | 取原始分数和重新分数查询分数的最大值。 |
min | 取原始分数和重新评分查询分数的最小值。 |
多次重新评分
也可以按顺序执行多个重新评分:
POST /_search
{
"query" : {
"match" : {
"message" : {
"operator" : "or",
"query" : "the quick brown"
}
}
},
"rescore" : [ {
"window_size" : 100,
"query" : {
"rescore_query" : {
"match_phrase" : {
"message" : {
"query" : "the quick brown",
"slop" : 2
}
}
},
"query_weight" : 0.7,
"rescore_query_weight" : 1.2
}
}, {
"window_size" : 10,
"query" : {
"score_mode": "multiply",
"rescore_query" : {
"function_score" : {
"script_score": {
"script": {
"source": "Math.log10(doc.count.value + 2)"
}
}
}
}
}
} ]
}
第一个得到查询的结果,然后第二个得到第一个的结果,依此类推。第二个重新评分将 “看到” 第一个重新评分完成的排序,因此可以在第一个重新评分上使用一个大窗口来 将文档拉入较小的窗口以进行第二次重新评分。
性能考虑
仅当你需要区分过滤器搜索结果和聚合时才使用 post_filter。 有时人们会使用 post_filter 进行常规搜索。post_filter 的性质意味着它在查询之后运行,因此过滤(例如缓存)的任何性能优势都完全丧失了。post_filter 应该仅与聚合结合使用,并且仅在你需要差分过滤时使用。
仅在需要时使用 post_filter
post_filter 参数有一个别名 filter。 这是为了向后兼容,因为在 ElasticSearch 的早期版本中,post_filter 曾经被命名为过滤器。 改名是有原因的。 虽然在创建只应过滤结果的请求时使用 post_filter 代替查询参数当然是可能且更方便的,但在性能方面不如使用查询参数好。 因此,即使你在调试时不需要使用 post_filter,也可以随意使用它,但仅在实际需要针对生产集群时使用它。
不要使用 post_filter ,除非你确实需要它来进行聚合。
参考:
【1】Filter search results | Elasticsearch Guide [8.2] | Elastic