es使用与原理4|es使用与原理4 -- phrase match ，slop近似匹配，搜索推荐等等 es使用与原理4--phrasematch，slo

短语搜索和近似搜索

"match": { "content": "java spark" }

match query，只能搜索到包含java和spark的document，但是不知道java和spark是不是离的很近
包含java或包含spark，或包含java和spark的doc，都会被返回回来。我们其实并不知道哪个doc，java和spark距离的比较近。如果我们就是希望搜索java spark,中间不能插入任何其他的字符或者指定中间只能隔num个字符，那这个时候match去做全文检索，能搞定我们的需求吗？答案是，搞不定。
两个需求：
1、java spark，就靠在一起，中间不能插入任何其他字符，就要搜索出来这种doc
2、java spark，但是要求，java和spark两个单词靠的越近，doc的分数越高，排名越靠前
phrase match 就是短语匹配，将短语作为一个整体去查找。

GET /forum/article/_search { "query": { "match_phrase": { "content": "java spark" } } }

3、分词后的临时 position

GET _analyze { "text": "hello world, java spark", "analyzer": "standard" }//返回结果 { "tokens": [ { "token": "hello", "start_offset": 0, "end_offset": 5, "type": "", "position": 0 }, { "token": "world", "start_offset": 6, "end_offset": 11, "type": "", "position": 1 }, { "token": "java", "start_offset": 13, "end_offset": 17, "type": "", "position": 2 }, { "token": "spark", "start_offset": 18, "end_offset": 23, "type": "", "position": 3 } ] }

从结果中，我们可以看出 hello的临时位置是0，world, java spark 的位置依次是 1，2,3
4、短语搜索的原理(近似搜索的原理也是这样的)
hello world, java spark doc1
hi, spark java doc2
hello doc1(0)
wolrd doc1(1)
java doc1(2) doc2(2)
spark doc1(3) doc2(1)
java spark --> match phrase
java spark --> java和spark
java --> doc1(2) doc2(2)
spark --> doc1(3) doc2(1)
要找到每个term都在的一个共有的那些doc，就是要求一个doc，必须包含每个term，才能拿出来继续计算
doc1 --> java和spark --> spark position恰巧比java大1 --> java的position是2，spark的position是3，恰好满足条件，doc1符合条件
doc2 --> java和spark --> java position是2，spark position是1，spark position比java position小1，而不是大1 --> 光是position就不满足，那么doc2不匹配
类似的近似搜索原理也是这样的
近似匹配：slop参数实现近似匹配

GET /forum/article/_search { "query": { "match_phrase": { "content": { "query": "java spark", "slop":3 } } } }

GET /forum/article/_search { "query": { "match_phrase": { "content": { "query": "data spark", "slop": 5 } } } }

slop的含义是什么？搜索文本，中的几个term，要经过几次移动才能与一个document匹配，这个移动的次数，就是slop。简单的说就是 java 和 spark之间的距离或者java和spark交换后的距离+2(这里的2是交换所需要的步数),slop搜索下，关键词离的越近，relevance score就会越高。
混合使用match和近似匹配实现召回率与精准度的平衡比如你搜索一个java spark，含有java，或者含有是spark，或者同时含有，并且尽可能让包含java spark，或者是java和spark离的很近的doc，排在最前面，同时提供了召回率还兼顾了精准率。
直接用match_phrase短语搜索，会导致必须有term都在doc field中出现，而且距离在slop限定范围内，才能匹配上
此时可以用bool组合match query和match_phrase query一起，来实现上述效果

GET /forum/article/_search { "query": { "bool": { "must": { "match": { "title": { "query":"java spark" --> java或spark或java spark，java和spark靠前，但是没法区分java和spark的距离，也许java和spark靠的很近，但是没法排在最前面 } } }, "should": { "match_phrase": { --> 在slop以内，如果java spark能匹配上一个doc，那么就会对doc贡献自己的relevance score，如果java和spark靠的越近，那么就分数越高 "title": { "query": "java spark", "slop":50 } } } } } }

使用rescoring机制优化近似匹配搜索的性能 match --> 只要简单的匹配到了一个term，就可以理解将term对应的doc作为结果返回，扫描倒排索引，扫描到了就ok
phrase match --> 首先扫描到所有term的doc list; 找到包含所有term的doc list; 然后对每个doc都计算每个term的position，是否符合指定的范围; slop，需要进行复杂的运算，来判断能否通过slop移动，匹配一个doc
match query的性能比phrase match和proximity match（有slop）要高很多。因为后两者都要计算position的距离。
match query比phrase match的性能要高10倍，比proximity match的性能要高20倍。
默认情况下，match也许匹配了1000个doc，proximity match全都需要对每个doc进行一遍运算，判断能否slop移动匹配上，然后去贡献自己的分数
但是很多情况下，match出来也许1000个doc，其实用户大部分情况下是分页查询的，所以可能最多只会看前几页，比如一页是10条，最多也许就看5页，就是50条
proximity match只要对前50个doc进行slop移动去匹配，去贡献自己的分数即可，不需要对全部1000个doc都去进行计算和贡献分数
match：1000个doc，其实这时候每个doc都有一个分数了; proximity match，前50个doc，进行rescore，重打分，即可; 让前50个doc，term举例越近的，排在越前面

GET /forum/article/_search { "query": { "match": { "content": "java spark" } }, "rescore": { "window_size": 50, "query": { "rescore_query": { "match_phrase": { "content": { "query": "java spark", "slop": 50 } } } } } }

前缀搜索、通配符搜索、正则搜索 1、前缀搜索
C3D0-KD345
C3K5-DFG65
C4I8-UI365
C3 --> 上面这两个都搜索出来 --> 根据字符串的前缀去搜索
不用帖子的案例背景，因为比较简单，直接用自己手动建的新索引，给大家演示一下就可以了

PUT my_index { "mappings": { "my_type": { "properties": { "title": { "type": "keyword" } } } } }GET my_index/my_type/_search { "query": { "prefix": { "title": { "value": "C3" } } } }

2、前缀搜索的原理
prefix query不计算relevance score，与prefix filter唯一的区别就是，filter会cache bitset
扫描整个倒排索引，举例说明
前缀越短，要处理的doc越多，性能越差，尽可能用长前缀搜索
前缀搜索，它是怎么执行的？性能为什么差呢？
match
C3-D0-KD345
C3-K5-DFG65
C4-I8-UI365
全文检索
每个字符串都需要被分词
c3 doc1,doc2
d0
kd345
k5
dfg65
c4
i8
ui365
c3 --> 扫描倒排索引 --> 一旦扫描到c3，就可以停了，因为带c3的就2个doc，已经找到了 --> 没有必要继续去搜索其他的term了
match性能往往是很高的
如果前缀搜索那么 (前缀搜索是不分词的)
C3-D0-KD345
C3-K5-DFG65
C4-I8-UI365
c3 --> 先扫描到了C3-D0-KD345，很棒，找到了一个前缀带c3的字符串 --> 还是要继续搜索的，因为后面还有一个C3-K5-DFG65，也许还有其他很多的前缀带c3的字符串 --> 你扫描到了一个前缀匹配的term，
不能停，必须继续搜索 --> 直到扫描完整个的倒排索引，才能结束，所以prefix性能很差
3、通配符搜索
跟前缀搜索类似，功能更加强大
C3D0-KD345
C3K5-DFG65
C4I8-UI365
5字符-D任意个字符5
5?-*5：通配符去表达更加复杂的模糊搜索的语义

GET my_index/my_type/_search { "query": { "wildcard": { "title": { "value": "C?K*5" } } } }

?：任意字符
*：0个或任意多个字符
性能一样差，必须扫描整个倒排索引，才ok
4、正则搜索

GET /my_index/my_type/_search { "query": { "regexp": { "title": "C[0-9].+" } } }

C[0-9].+
[0-9]：指定范围内的数字
[a-z]：指定范围内的字母
.：一个字符
+：前面的正则表达式可以出现一次或多次
wildcard和regexp，与prefix原理一致，都会扫描整个索引，性能很差
match_phrase_prefix实现search-time搜索推荐输入 hello w ，会联想到hello world，hello we，hello win，hello wind 等等
原理跟match_phrase类似，唯一的区别，就是把最后一个term作为前缀去搜索。
hello就是去进行match，搜索对应的doc
w，会作为前缀，去扫描整个倒排索引，找到所有w开头的doc
然后找到所有doc中，即包含hello，又包含w开头的字符的doc
根据你的slop去计算，看在slop范围内，能不能让hello w，正好跟doc中的hello和w开头的单词的position相匹配
也可以指定slop，但是只有最后一个term会作为前缀
max_expansions：指定prefix最多匹配多少个term，超过这个数量就不继续匹配了，限定性能
默认情况下，前缀要扫描所有的倒排索引中的term，去查找w打头的单词，但是这样性能太差。可以用max_expansions限定，w前缀最多匹配多少个term，就不再继续搜索倒排索引了。
尽量不要用，因为，最后一个前缀始终要去扫描大量的索引，性能可能会很差，可以使用ngram来实现
通过ngram分词机制实现index-time搜索推荐什么是ngram
quick，5种长度下的ngram
ngram length=1，q u i c k
ngram length=2，qu ui ic ck
ngram length=3，qui uic ick
ngram length=4，quic uick
ngram length=5，quick
【es使用与原理4|es使用与原理4 -- phrase match ，slop近似匹配，搜索推荐等等】什么是edge ngram
quick，首字母后进行ngram
q
qu
qui
quic
quick
-----------------------------------搜索推荐未完。。。。。。。。。