技术库 > Java

Elasticsearch 查询建议suggester

技术库:tec.5lulu.com

索引时输入即搜索

from:tec.5lulu.com

设置索引时输入即搜索的第一步是需要定义好分析链, 我们已在 配置分析器 中讨论过,这里会对这些步骤再次说明。

1 准备索引

第一步需要配置一个自定义的edge_ngramtoken 过滤器,称为autocomplete_filter:

{
    "filter": {
        "autocomplete_filter": {
            "type":     "edge_ngram",
            "min_gram": 1,
            "max_gram": 20
        }
    }
}


这个配置的意思是:对于这个 token 过滤器接收的任意词项,过滤器会为之生成一个最小固定值为 1 ,最大为 20 的 n-gram 。

然后会在一个自定义分析器autocomplete中使用上面这个 token 过滤器:

{
    "analyzer": {
        "autocomplete": {
            "type":      "custom",
            "tokenizer": "standard",
            "filter": [
                "lowercase",
                "autocomplete_filter" ①
            ]
        }
    }
}


自定义的 edge-ngram token 过滤器。

这个分析器使用standard分词器将字符串拆分为独立的词,并且将它们都变成小写形式,然后为每个词生成一个边界 n-gram,这要感谢autocomplete_filter起的作用。

创建索引、实例化 token 过滤器和分析器的完整示例如下:

PUT /my_index
{
    "settings": {
        "number_of_shards": 1, ①
        "analysis": {
            "filter": {
                "autocomplete_filter": { ②
                    "type":     "edge_ngram",
                    "min_gram": 1,
                    "max_gram": 20
                }
            },
            "analyzer": {
                "autocomplete": {
                    "type":      "custom",
                    "tokenizer": "standard",
                    "filter": [
                        "lowercase",
                        "autocomplete_filter" ③
                    ]
                }
            }
        }
    }
} 

参考 被破坏的相关度 。

首先自定义 token 过滤器。

然后在分析器中使用它。

可以拿analyzeAPI 测试这个新的分析器确保它行为正确:

GET /my_index/_analyze?analyzer=autocomplete
quick brown

结果表明分析器能正确工作,并返回以下词:

  • q
  • qu
  • qui
  • quic
  • quick
  • b
  • br
  • bro
  • brow
  • brown

可以用update-mappingAPI 将这个分析器应用到具体字段:

PUT /my_index/_mapping/my_type
{
    "my_type": {
        "properties": {
            "name": {
                "type":     "string",
                "analyzer": "autocomplete"
            }
        }
    }
}


拷贝为 cURL在 Sense 中查看 

现在创建一些测试文档:

POST /my_index/my_type/_bulk
{ "index": { "_id": 1            }}
{ "name": "Brown foxes"    }
{ "index": { "_id": 2            }}
{ "name": "Yellow furballs" }


拷贝为 cURL在 Sense 中查看 

2 查询字段

如果使用简单match查询测试查询 “brown fo” :

GET /my_index/my_type/_search
{
    "query": {
        "match": {
            "name": "brown fo"
        }
    }
} 

可以看到两个文档同时 都能 匹配,尽管Yellow furballs这个文档并不包含brown和fo: 

{

  "hits": [
     {
        "_id": "1",
        "_score": 1.5753809,
        "_source": {
           "name": "Brown foxes"
        }
     },
     {
        "_id": "2",
        "_score": 0.012520773,
        "_source": {
           "name": "Yellow furballs"
        }
     }
  ]
}


如往常一样,validate-queryAPI 总能提供一些线索:

GET /my_index/my_type/_validate/query?explain
{
    "query": {
        "match": {
            "name": "brown fo"
        }
    }
}


explanation表明查询会查找边界 n-grams 里的每个词:

name:b name:br name:bro name:brow name:brown name:f name:fo

name:f条件可以满足第二个文档,因为furballs是以f、fu、fur形式索引的。回过头看这并不令人惊讶,相同的autocomplete分析器同时被应用于索引时和搜索时,这在大多数情况下是正确的,只有在少数场景下才需要改变这种行为。

我们需要保证倒排索引表中包含边界 n-grams 的每个词,但是我们只想匹配用户输入的完整词组(brown和fo), 可以通过在索引时使用autocomplete分析器,并在搜索时使用standard标准分析器来实现这种想法,只要改变查询使用的搜索分析器analyzer参数即可:

GET /my_index/my_type/_search
{
    "query": {
        "match": {
            "name": {
                "query":    "brown fo",
                "analyzer": "standard" ①
            }
        }
    }
}


覆盖了name字段analyzer的设置。

换种方式,我们可以在映射中,为name字段分别指定index_analyzer和search_analyzer。因为我们只想改变search_analyzer,这里只要更新现有的映射而不用对数据重新创建索引:

PUT /my_index/my_type/_mapping
{
    "my_type": {
        "properties": {
            "name": {
                "type":            "string",
                "index_analyzer":  "autocomplete", ①
                "search_analyzer": "standard" ②
            }
        }
    }
}


在索引时,使用autocomplete分析器生成边界 n-grams 的每个词。

在搜索时,使用standard分析器只搜索用户输入的词。

如果再次请求validate-queryAPI ,当前的解释为:

name:brown name:fo

再次执行查询就能正确返回Brown foxes这个文档。

因为大多数工作是在索引时完成的,所有的查询只要查找brown和fo这两个词,这比使用match_phrase_prefix查找所有以fo开始的词的方式要高效许多。

3 边界 n-grams 与邮编

边界 n-gram 的方式可以用来查询结构化的数据, 比如 本章之前示例 中的邮编(postcode)。当然postcode字段需要analyzed而不是not_analyzed,不过可以用keyword分词器来处理它,就好像他们是not_analyzed的一样。

keyword分词器是一个非操作型分词器,这个分词器不做任何事情,它接收的任何字符串都会被原样发出,因此它可以用来处理not_analyzed的字段值,但这也需要其他的一些分析转换,如将字母转换成小写。

下面示例使用keyword分词器将邮编转换成 token 流,这样就能使用边界 n-gram token 过滤器:

{
    "analysis": {
        "filter": {
            "postcode_filter": {
                "type":     "edge_ngram",
                "min_gram": 1,
                "max_gram": 8
            }
        },
        "analyzer": {
            "postcode_index": { ①
                "tokenizer": "keyword",
                "filter":    [ "postcode_filter" ]
            },
            "postcode_search": { ②
                "tokenizer": "keyword"
            }
        }
    }
}


postcode_index分析器使用postcode_filter将邮编转换成边界 n-gram 形式。

postcode_search分析器可以将搜索词看成not_analyzed未分析的。

Elasticsearch 查询建议suggester


本文链接 http://tec.5lulu.com/detail/110dtn2ehyg02852b.html

我来评分 :6.1
0

转载注明:转自5lulu技术库

本站遵循:署名-非商业性使用-禁止演绎 3.0 共享协议

www.5lulu.com