短语搜索和近似搜索
"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
什么是edge ngram
quick，首字母后进行ngram
q
qu
qui
quic
quick
-----------------------------------搜索推荐 未完。。。。。。。。。