Elasticsearch系列---近似匹配
概要
前面的match查询只能告诉我们，搜索的文档里有这些关键词，但无法告知词语之间的顺序，而不同的词语顺序表达的意思可能完全相反。我们想要的，是跟我们期望搜索的语义要相似，这就需要短语匹配和近似匹配来控制了。
短语搜索
短语搜索即把一小段话完完整整地进行搜索，必须保证被搜索的文档内有一模一样的才行，如下：
GET /music/children/_search
{
"query": {
"match_phrase": {
"content": "in the morning"
}
}
}
Elasticsearch对短语搜索必须要满足如下要求：
- in the morning 三个单词必须要全部出现
- the的位置比in大1
- morning的位置比the大1
任何一个不成立，则搜索不到匹配的结果。意思上是说，短语搜索除了关注关键词是否出现，还关心被搜索文档中这几个关键词的位置，我们可以用调度命令看一下词条的位置：
GET /_analyze
{
"analyzer":"standard",
"text": "in the morning"
}
响应结果：
{
"tokens": [
{
"token": "in",
"start_offset": 0,
"end_offset": 2,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "the",
"start_offset": 3,
"end_offset": 6,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "morning",
"start_offset": 7,
"end_offset": 14,
"type": "<ALPHANUM>",
"position": 2
}
]
}
留意一下tokens显示的position信息，position连续说明这三个词紧靠在一起，搜索文档时，也只有命中这三个词的文档，position按次序连接才能匹配得上。
近似匹配
近似匹配是在短语匹配的基础上，短语匹配有些严格，要求位置必须按照搜索字符串来，近似匹配则有一些变通，允许短语之间的位置有变化，变化的程度由参数slop决定。
例如：
GET /music/children/_search
{
"query": {
"match_phrase": {
"content": {
"query": "you me",
"slop": 1
}
}
}
}
slop含义
- query string搜索文本中的几个term，要经过n次移动才能与一个document匹配，这个移动的次数，就是slop。
- slop表示移动的最大次数，离得越近的，分数就会越高。
- term之间交换位置也行的，但是slop得大一些。
我们以字符串"you make me happy"举例，画个移动表格：
| pos 1 | pos 2 | pos 3 | pos 4 | |
|---|---|---|---|---|
| DOC | you | make | me | happy |
| query | you | me | ||
| slop 1 | you | -> | me |
me只需要移动一步，就能匹配上，所以slop 1能查询到结果。
演示样例有限，我们把搜索串改成"me you"，模拟颠倒次序的slop，但slop至少要是3才行：
GET /music/children/_search
{
"query": {
"match_phrase": {
"content": {
"query": "me you",
"slop": 3
}
}
}
}
为什么是3，我们以字符串"you make me happy"再画个移动表格
| pos 1 | pos 2 | pos 3 | pos 4 | |
|---|---|---|---|---|
| DOC | you | make | me | happy |
| query | you | me | ||
| slop 1 | me/you | <- | ||
| slop 2 | you -> | me | ||
| slop 3 | you | -> | me |
注意slop 1时，me和you共占用同一个位置，二者交换一下顺序，就需要slop为2。
近似匹配，就是使用了slop参数的短语匹配。
数组类型的slop
我们music索引中的tags字段，设计时是数组类型的，如果我们对这个字段进行近似匹配，结果会是怎么样：
_id为1的文档数据，tags是这样的：
"tags": ["enlighten","gymbo","friend"]
按照slop的偏移量，slop为1应该是可以匹配上
GET /music/children/_search
{
"query": {
"match_phrase": {
"tags": {
"query": "enlighten friend",
"slop": 1
}
}
}
}
结果竟然是空，怎么回事呢？我们分析一下该field的tokens信息：
GET /music/_analyze
{
"field": "tags",
"text": ["enlighten","gymbo","friend"]
}
响应
{
"tokens": [
{
"token": "enlighten",
"start_offset": 0,
"end_offset": 9,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "gymbo",
"start_offset": 10,
"end_offset": 15,
"type": "<ALPHANUM>",
"position": 101
},
{
"token": "friend",
"start_offset": 16,
"end_offset": 22,
"type": "<ALPHANUM>",
"position": 202
}
]
}
注意一下position的值，数组元素之间，position间隔都是100。
6.x的版本，position_increment_gap参数值默认是100，表示元素之间，步长为100，毕竟没有人近似查询时会关系slop大于100的结果。之前老版本这个值默认是1，出现了很多意外的问题，6.x后算是对此问题的修复。
召回率与精准度的平衡
召回率：假设有100个doc，你搜索一段文本，能返回多个doc，与总doc的比例，就是召回率，recall。
精准度：你搜索一段文本love me，能不能尽可能让包含这两个关键字的doc，或者离得近的doc先返回，排在前面，就是精准度，precision。
这二者看似有些矛盾，想要召回率高，精准度可能就低，反过来也是如此，精准度越是高的，召回率就越低，如何找一个平衡点？
我们一般的原则是优先满足召回率，同时兼顾精准度。比如match和match_phrase同时使用：
GET /music/children/_search
{
"query": {
"bool": {
"must": [
{
"match": {
"content": "you gymbo"
}
}
],
"should": [
{
"match_phrase": {
"content": {
"query": "loves gymbo",
"slop": 2
}
}
}
]
}
}
}
我们可以看到加了match_phrase条件后，_id为3的_score由0.39556286上升到0.65997654。
rescoring优化性能
match查询和短语搜索(近似搜索)区别
match查询：只要简单的匹配到了一个term，就可以理解将term对应的doc作为结果返回，扫描倒排索引，扫描到了就表示有结果匹配了。
短语搜索(phrase match)：先扫描所有term的doc list，找到包含所有term的doc list，然后对每个doc都计算每个term的position，是否符合指定的范围。
近似搜索(proxmity match)：slop需要进行复杂的运算，来判断能否通过slop移动，匹配一个doc
match query性能要高一些，比phrase match高10倍，比proximity match高20倍。不过Elasticsearch内搜索的效率基本控制在几毫秒内，10、20倍不过也百十来毫秒，哪怕是繁忙的ES集群，也不过一两百毫秒，实际上完全可用。
如何优化proximity match？
一个查询可能会匹配成千上万的结果，但我们的用户很可能只对结果的前几页感兴趣，所以优化的思路就是proximity只要符合match条件的前几十个文档进行评分，而不是全部数据，速度自然能大大加快。
resocre重打分: proximity match，前20个doc进行rescore即可。
语法示例：
GET /music/children/_search
{
"query": {
"match": {
"content": "gymbo you"
}
},
"rescore": {
"window_size": 20,
"query": {
"rescore_query": {
"match_phrase": {
"content": {
"query": "gymbo you",
"slop": 1
}
}
}
}
}
}
- match 查询决定哪些文档将包含在最终结果集中，并通过TF/IDF排序。
- window_size 是每一分片进行重新评分的顶部文档数量，例子中取20个。
小结
本篇主要介绍近似匹配的常规玩法，以及rescoring优化性能的思路。
专注Java高并发、分布式架构，更多技术干货分享与心得，请关注公众号：Java架构社区
可以扫左边二维码添加好友，邀请你加入Java架构社区微信群共同探讨技术
