全文搜索包括两个最重要的方面：
1. 查询与结果的相关性，并根据相关性对结果进行排名。
2. 分析，将数据转化为有区别的、规范化的的过程。
所有的查询都或多或少的会进行相关度计算，但不是所有的查询都会有分析阶段，文本查询可以分为两个部分：
1. 基于词项的查询，如 term 或 fuzzy 这样的查询是没有分析阶段的。他们对单个词项进行 *** 作。
2. 基于全文的查询，比如match， 它们会先了解字段映射的信息，判断字段是否被分词，是否是日期还是数字等， 再根据映射信息，构建要查询的词项列表，根据列表进行查询。
匹配查询 match 是个核心查询。无论需要查询什么字段， match 查询都应该会是首选的查询方式。使用方式如下：
es执行上列步骤的过程如下：
如果一次只能搜索一个词语，那么全文搜索会不太灵活，幸运的是 match 也支持多词查询 。
以上查询其实先后执行了两次 term 查询，使用 bool 进行包含，然后将结果进行合并返回。
以上查询其实会导致出现不相关的结果，我们只想搜索包含words1 和 words2 的文档，而不是 or 的结果。match 查询还可以接受 operator *** 作符作为输入参数，默认情况下该 *** 作符是 or 。
这种 *** 作还是有些不妥，在 and 和 or 中间选择太过绝对，如果用户给出了5个词项，我们想只要满足其中4 个 就表示匹配，match 也提供了 minimum_should_match 参数，他是一个最小匹配参数，我们可以控制满足的词项超过改值则表示匹配，最好是使用百分比，因为你也不知道用户提供了多少个词项。该参数的设置非常灵活，完整的信息参考文档，请看 https://www.elastic.co/guide/en/elasticsearch/reference/5.6/query-dsl-minimum-should-match.html#query-dsl-minimum-should-match
如果我们使用 bool 查询黑色、大屏、手机，其中should 语句匹配得越多表示文档的相关度越高，但是我们想要手机所占的权重比较大，内容包括手机的文档排名靠前，可以使用 boost 设置相对权重，注意是相对权重，默认是1。
在说相关度被破坏的原因之前，我们先看看es对于相关度是如何计算的
es 的相似度算法被定义为检索词频率/反向文档频率， TF/IDF ，包括以下内容：
有时，我们索引了一些文档，然后检索发现有些相关度较低的返回排名靠前？
出现上述原因的情况是因为es由于性能原因，不会计算所有索引该文档的节点的IDF,比如我们索引了10个文档， 其中6个文档中包含 foo ，而由于es是分布式的，一个索引会被分为多个分片，有可能分片一包含的5 个文档，有 4 个包含foo, 而另外一个在分片二中，所以会导致结果有差异。
在实际应用中，不会出现该问题，因为本局和全局的IDF差异会随着文档数量的增加逐渐降低。如果想要自己处理该问题，可以在搜索请求之后增加 ?search_type=dfs_query_then_fetch ,他会使得es先计算各个分片的 IDF, 然后在求出全局的 IDF, 生产环境中不要使用。因为只要有足够的数据就可以使得差异减少。
关于ES的搜索，小白暂且简单的归纳如下:
新增文档时涉及分词、构建索引
查询时涉及分词、查询索引、相关度评分
那么接下来，小白就从分词、索引、相关度评分三个方面开始瞎掰了...
分词是指将文本转换成一系列单词（term or token）的过程，也可以叫做文本分析，在es里面称为Analysis。
分词机制：
Character Filter：对原始文本进行处理，例如 去除html标签、替换字符等
Tokenizer：将原始文本进行分词，例如 小白最帅 =>小白，最，帅
Token Filters：分词后的关键字进行加工，例如 转小写、删除语气词、近义词和同义词等
在进行Tokenizer之前对对原始文本进行处理，例如 去除html标签、替换字符等
不过进行处理后，会影响后续Tokenizer解析的position和offset
HTML Strip => 去除html标签和转换html实体
Mapping => 字符串替换 *** 作
Pattern Replace => 正则匹配替换
将原始文本进行分词，例如 小白最帅 =>小白，最，帅
Elasticsearch自带的分词器：
【分词器（Analyzer）】 【特点】
standard（es默认） 支持多语言，按词切分并做小写处理
simple 按照非字母切分，小写处理
whitespace 按照空格来切分
stop 去除语气助词，如the、an、的、这等
keyword 不分词
pattern 正则分词，默认\w+,即非字词符号做分割符
language 常见语言的分词器（30+）
常见中文分词器：
【名称】 【介绍】 【特点】
IK 实现中英文单词切分 自定义词库
https://github.com/medcl/elasticsearch-analysis-ik
Jieba python流行分词系统，支持分词和词性标注 支持繁体、自定义、并行分词
http://github.com/sing1ee/elasticsearch-jieba-plugin
Hanlp 由一系列模型于算法组成的java工具包 普及自然语言处理在生产中应用
https://github.com/hankcs/HanLP
THULAC 清华大学中文词法分析工具包 具有中文分词和词性标注功能
https://github.com/microbun/elasticsearch-thulac-plugin
分词后的关键字进行加工，例如 转小写、删除语气词、近义词和同义词等
lowercase => 将所有term转换为小写
stop => 删除stop words
ngram => 和Edge NGram连词分割
synonym => 添加近义词的term
提到ES中的索引，就算没用过，估计也听过，就是倒排索引，当然ES中不可能不涉及正排索引。
通俗地来讲，正排索引是通过key找value，倒排索引则是通过value找key。举个例子，如果要查找图书馆中名为【水浒传】的书籍时，提前建立正排索引会提高查询效率；如果要查找图书馆中所有包含词语【英雄】的书籍时，提前建立倒排索引会提高查询效率，而正排索引需要遍历所有的书籍内容。
记录文档id到文档内容or单词的关联关系，比如：
【DocId】 【content】
1 => 小白最帅（小白、最、帅）
2 => 小黑最帅（小黑、最、帅）
3 => 拳打小白（拳打、小白）
备注：IK分词器中提供了两个分词算法 ik_smart 和 ik_max_word
其中 ik_smart 为最少切分，ik_max_word为最细粒度划分
本小节分词采用的是 ik_smart
记录单词到文档id的关联关系，包含：
1、Term DicTionary（单词词典）：记录所有文档的单词，一般比较大
2、Posting List（倒排链表）：记录单词倒排列表的关联信息
以第1节中文档【小白最帅】和【拳打小白】中的【小白】为例：
Term DicTionary：小白
Posting List：
【DocId】 【TF】 【Position】 【Offset】
1 1 0 <0-2>
3 1 1 <2-4>
DocId：文档id，指向文档的原始信息
TF：单词频率，记录该词在文档中出现的次数，用于后续相关性评分
Position：位置，记录文档中字段分词后，单词所在的位置，从0开始
Offset：偏移量，记录单词在文档中开始和结束位置，用于高亮显示等，从0开始
不是很恰当的说，索引的建立，标志着key的创建，再让key和value之间建立联系，就可以让原本直接查找value，变成了先去查找key，再直接定位到对应的value，属于典型的空间换时间或者说是先栽树、再乘凉。
下面这个数据结构图，不管是java开发还是大数据开发，估计都看烂了。。。
备注：每个文档字段都有自己的倒排索引
相关性描述的是“语句”与“某个文档”匹配的程度。ES 会对每个匹配查询的结果进⾏计算，得出_score，_score 的评分越高，相关度就越高，那这个计算就需要一个算法。在ES5之前默认的算法是TF/IDF，ES5之后默认采用的是BM25，BM25是对TF/IDF的改进，所以这里小白直接以BM25为主来叨叨。
在进行相关度计算之前，会先有一个过程叫Boolean Model，之后再使用TFNORM/IDF算法。
简单来说，Boolean Model就是根据查询条件，对文档进行一个快速的筛选，不涉及相关度计算。
即词频长度(Term Frequency Norm)，单个term在文档中出现的频率，并结合字段长度，出现次数越高，字段长度越低，分越高
计算公式：
tfNorm(t in d) = (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength))
freq：term出现频率
k1 ：这个参数控制着词频结果在词频饱和度中的上升速度 。 默认值为1.2。值越小饱和度变化越快，值越大饱和度变化越慢
b ：这个参数控制着字段长归一值所起的作用 ， 0.0会禁用归一化，1.0会启用完全归一化。默认值为0.75
fieldLength：字段长度
avgFieldLength：平均字段长度
即逆向文档频率(inversed document frequency)，单个term在所有文档里出现的频率，出现次数越高，分越低。
计算公式：
idf(t) = log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5))
docCount ：索引中文档数量
docFreq ：包含该词的文档数
此公式将出现频率较高的词的得分降低。比如，“的”、“了”等词语在各文档中出现频率较高，但是并没有太大的参考意义，所以降低其得分。
然后，将上面两个算法的得分相乘，则是一个term的最终得分。
单个term：_score(单) = idf(t) * tfNorm(t in d)
多个term：_score(多) = 多个_score(单)的和
最后，我们在Kibana中通过explain查询语句来看一哈【所用索引和数据为下一节中的内容】：
ES(五) ElasticSearch+Kibana+IK 安装—ES集群 ES(七) Demo-商品搜索
Logstash从kafka集群Topic获取数据，解析出其字段，然后写入到ES中，logstash.conf配置如下：
结果有626条，而且HOSTNAME都是timeline11.server.163.org：
HOSTNAME条件设置为timeline111.server.163.org，期望匹配结果为空。
实际结果还是有626条，感觉加的过滤条件不生效。
网上针对这个问题的分析
[ https://stackoverflow.com/questions/23150670/elasticsearch-match-vs-term-query]
修改请求体之后：
结果是符合预期的：
如果使用ES的搜索过程中，发现加了过滤条件不生效，可以尝试以下方法：
1）条件字段是否有keyword,有的话，使用xxx.keyword
attention
ES中的查询 *** 作分为2种：查询（query）和过滤（filter）。查询即是之前提到的query查询，它（查询）默认会计算每个返回文档的得分，然后根据得分排序。而过滤（filter）只会筛选出符合的文档，并不计算得分，且它可以缓存文档。所以，单从性能考虑，过滤比查询更快。
使用过滤语句得到的结果集 -- 一个简单的文档列表，快速匹配运算并存入内存是十分方便的， 每个文档仅需要1个字节。这些缓存的过滤结果集与后续请求的结合使用是非常高效的。
查询语句不仅要查找相匹配的文档，还需要计算每个文档的相关性，所以一般来说查询语句要比 过滤语句更耗时，并且查询结果也不可缓存。详细介绍可以参考：
https://doc.yonyoucloud.com/doc/mastering-elasticsearch/chapter-2/27_README.html
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）