我也不明白你在问什么。可能是你对渗滤器不是很了解？
这是我刚刚尝试的一个示例。
假设你有一个索引——我们称之为test——你想在其中索引一些文档。该索引具有以下映射（只是我的测试设置中的一个随机测试索引）：
{
"settings": {
"analysis": {
"filter": {
"email": {
"type": "pattern_capture",
"preserve_original": true,
"patterns": [
"([^@]+)",
"(\\p{L}+)",
"(\\d+)",
"@(.+)",
"([^-@]+)"
]
}
},
"analyzer": {
"email": {
"tokenizer": "uax_url_email",
"filter": [
"email",
"lowercase",
"unique"
]
}
}
}
},
"mappings": {
"properties": {
"code": {
"type": "long"
},
"date": {
"type": "date"
},
"part": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"val": {
"type": "long"
},
"email": {
"type": "text",
"analyzer": "email"
}
}
}
}
您注意到它有一个自定义的email 分析器，可以将foo@bar.com 之类的内容拆分为以下标记：foo@bar.com、foo、bar.com、bar、com。
正如文档所述，您可以创建一个单独的过滤器索引，该索引将仅保存您的过滤器查询，而不是文档本身。而且，即使 percolator 索引不包含文档本身，它也应该保存应该保存文档的索引的映射（在我们的例子中是test）。
这是渗透器索引（我称之为percolator_index）的映射，它还具有用于拆分email 字段的特殊分析器：
{
"settings": {
"analysis": {
"filter": {
"email": {
"type": "pattern_capture",
"preserve_original": true,
"patterns": [
"([^@]+)",
"(\\p{L}+)",
"(\\d+)",
"@(.+)",
"([^-@]+)"
]
}
},
"analyzer": {
"email": {
"tokenizer": "uax_url_email",
"filter": [
"email",
"lowercase",
"unique"
]
}
}
}
},
"mappings": {
"properties": {
"query": {
"type": "percolator"
},
"code": {
"type": "long"
},
"date": {
"type": "date"
},
"part": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}
},
"val": {
"type": "long"
},
"email": {
"type": "text",
"analyzer": "email"
}
}
}
}
它的映射和设置与我原来的索引几乎相同，唯一的区别是在映射中添加了percolator 类型的附加query 字段。
你感兴趣的查询-simple_query_string-应该进入percolator_index内的一个文档。像这样：
PUT /percolator_index/_doc/1?refresh
{
"query": {
"simple_query_string" : {
"query" : "month foo@bar.com",
"fields": ["part", "email"]
}
}
}
为了让它更有趣，我在其中添加了email 字段，以便在查询中专门搜索（默认情况下，所有这些都被搜索）。
现在，我们的目标是根据您的 percolator 索引中的 simple_query_string 查询来测试最终应该进入 test 索引的文档。例如：
GET /percolator_index/_search
{
"query": {
"percolate": {
"field": "query",
"document": {
"date":"2004-07-31T11:57:52.000Z","part":"month","code":109,"val":0,"email":"foo@bar.com"
}
}
}
}
document 下的内容显然是您未来（尚不存在）的文档。这将与上面定义的simple_query_string 匹配，并会产生匹配：
{
"hits": {
"total": {
"value": 1,
"relation": "eq"
},
"max_score": 0.39324823,
"hits": [
{
"_index": "percolator_index",
"_type": "_doc",
"_id": "1",
"_score": 0.39324823,
"_source": {
"query": {
"simple_query_string": {
"query": "month foo@bar.com",
"fields": [
"part",
"email"
]
}
}
},
"fields": {
"_percolator_document_slot": [
0
]
}
}
]
}
}
如果我改为渗透此文档会怎样：
{
"query": {
"percolate": {
"field": "query",
"document": {
"date":"2004-07-31T11:57:52.000Z","part":"month","code":109,"val":0,"email":"foo"
}
}
}
}
（注意邮箱只有foo）
结果如下：
{
"hits": {
"total": {
"value": 1,
"relation": "eq"
},
"max_score": 0.26152915,
"hits": [
{
"_index": "percolator_index",
"_type": "_doc",
"_id": "1",
"_score": 0.26152915,
"_source": {
"query": {
"simple_query_string": {
"query": "month foo@bar.com",
"fields": [
"part",
"email"
]
}
}
},
"fields": {
"_percolator_document_slot": [
0
]
}
}
]
}
}
请注意，分数略低于第一个渗透文档。这可能是这样的，因为foo（我的电子邮件）仅匹配我分析的foo@bar.com 中的一个术语，而foo@bar.com 会匹配所有这些术语（因此给出更好的分数）
但不确定您在说什么分析仪。我认为上面的示例涵盖了我认为可能有点令人困惑的唯一“分析器”问题/未知。