网站建设小说毕业设计,网站如何做微信支付,wordpress下载资源站主题,自己有域名如何做网站一、match系列查询
前面讲到的query中的查询#xff0c;都是精准查询。可以理解成跟在关系型数据库中的查询类似。match系列的查询#xff0c;是全文检索的查询。会通过分词进行评分#xff0c;匹配#xff0c;再返回搜索结果。
1.1 match 查询
query: {都是精准查询。可以理解成跟在关系型数据库中的查询类似。match系列的查询是全文检索的查询。会通过分词进行评分匹配再返回搜索结果。
1.1 match 查询
query: {match: {elk: Elasticsearch LogStash Kibana}
}查询字符串是“Elasticsearch LogStash Kibana”被分析器分词之后产生三个小写的单词elasticsearch logstash kibana然后根据分析的结果构造一个布尔查询默认情况下引擎内部执行的查询逻辑是只要 elk 字段值中包含有任意一个关键字 elasticsearch 或 logStash 或 kibana那么返回该文档。 匹配查询的行为受到两个参数的控制 operator表示单个字段如何匹配查询条件的分词 minimum_should_match表示字段匹配的数量。 通过调整 operator 和 minimum_should_match 属性值控制匹配查询的逻 辑条件进而控制引擎返回的结果。默认情况下 operator 的值是 or在构造查询时设置分词之间的逻辑运算符如果设置为 and那么只有分词的每个词都匹配的文档才能返回。 对于 minimum_should_match 属性值默认值是 1如果设置其值为 2,表示分词必须匹配查询条件的数量为 2这意味着只要文档的 elk 字段包含任意两个关键字就满足查询条件但是如果文档中只有 1 个关键字,这个文档就不满足条件。 例如:
POST indexname/_search{query: {match: {message: {query: firefox chrome,operator: and}}}
}
或者:
POST indexname/_search{query: {match: {message: {query: firefox chrome,minimum_should_match: 2}}}
}只会返回文档中message字段同时包含firefox和chrome的文档而只包含其中之一的不会返回。
1.2 multi_match 查询
多个字段上执行匹配相同的查询叫做multi_match查询。比如
POST indexname/_search{query: {multi_match: {query: AT,fields: [DestCountry,OriginCountry]}}
}请求将同时检索文档中 DestCountry 和 OriginCountry 这两个字段只要有一个字段包含 AT 词项该文档就满足查询条件。
1.3 match_phrase 查询
当你希望寻找邻近的单词时match_phrase 查询可以帮你达到目的。比如 假设我们要找到 title 字段包含这么一段文本“quick brown fox”的文档然后我们用
GET indexname/_search{query: {match_phrase: {title: quick brown fox}}
}match_phrase 查询首先解析查询字符串来产生一个词条列表。然后会搜索所有的词条但只保留包含了所有搜索词条的文档并且词条的位置要邻接。 但是对于
GET /my_index/my_type/_search{query: {match_phrase: {title: quick fox}}
}这个查询查询不会匹配我们的任何文档因为没有文档含有邻接在一起的 quick 和 fox 词条。也就是说匹配的文档必须满足 1、quick、brown 和 fox 必须全部出现在 title 字段中。 2、brown 的位置必须比 quick 的位置大 1。 3、fox 的位置必须比 quick 的位置大 2。
如果以上的任何一个条件没有被满足那么文档就不能被匹配。 精确短语(Exact-phrase)匹配也许太过于严格了。也许我们希望含有quick brown fox的文档也能够匹配quick fox查询即使位置并不是完全相等的。 我们可以在短语匹配使用 slop 参数来引入一些灵活性
GET /my_index/my_type/_search{query: {match_phrase: {title: {query: quick fox,slop: 1}}}
}match_phrase_prefix 查询 被称为基于前缀的短语匹配比如
{match_phrase_prefix: {brand: johnnie walker bl}
}这种查询的行为与 match_phrase 查询一致不同的是它将查询字符串的最 后一个词作为前缀使用换句话说可以将之前的例子看成如下这样 johnnie跟着 walker跟着以 bl 开始的词。 或者可以干脆理解为 “johnnie walker bl*”。 与 match_phrase 一样它也可以接受 slop 参数参照 slop 让相对词 序位置不那么严格。 prefix 查询存在严重的资源消耗问题短语查询的这种方式也同样如此。前 缀 a 可能会匹配成千上万的词这不仅会消耗很多系统资源而且结果的用处也不大。 可以通过设置 max_expansions 参数来限制前缀扩展的影响一个合理的值是 50 这也是系统默认的值
{match_phrase_prefix: {brand: {query: johnnie walker bl,max_expansions: 50}}
}二、模糊查询、纠错与提示器
2.1 编辑距离算法
在 Elasticsearch 基于全文的查询中除了与短语相关的查询以外其余查询都包含有一个名为 fuzziness 的参数用于支持模糊查询。Elasticsearch 支持的模糊查询与 SQL 语言中模糊查询还不一样SQL 的模糊查询使用“% keyword%的形式效果是查询字段值中包含 keyword 的记录。
Elaticsearch 支持的模糊查询比这个要强大得多它可以根据一个拼写错误的词项匹配正确的结果例如根据firefix 匹配 firefox。在自然语言处理领域两个词项之间的差异通常称为距离或编辑距离距离的大小用于说明两个词项之间差异的大小。
编辑距离的算法有多种在 Elasticsearch 中主要使用 Levenshtein 和 NGram两种。其他与此相关的算法也都是在这两种算法基础上进行的改造基本思想都是一致的。所以理解这两个算法的核心思想是学习这部分内容的关键。
Levenshtein 与 NGram Levenshein算法是前苏联数学家 Vladimir Levenshein在1965 年开发的一套算法 这个算法可以对两个字符申的差异程度做量化。量化结果是一一个正整数反映的是一个字符申变成另一个字符申最少需要多少次的处理。由于 Levenshtein算法是最为普遍接受的编辑距离算法所以在很多文献中如果没有特殊说明编辑距离算法就是指 Levenshtein 算法。
在 Levenshtein 算法中定义了三种字符操作即替换、插人和删除后来又 由其他科学家补充了一个换位操作。在转换过程中每执行次操作编辑距离就加1 编辑距离越大越能说明两个字符串之间的差距大。
比如从 firefix 到 firefox 需要将“i替换成“o” 所以编辑距离为 1;而从 fax 到 fair 则需要将“x”替换为“i并在结尾处插人“r”所以编辑距离为 2。显然 在编辑距离相同的情况下单词越长错误与正确就越接近。比如编辑距离同样为2 的情况下从 fax 到 fair 与从 elascsearxh 到 elasticsearch,后者elastesearsh 是由拼写错误引起的可能性就更大此。所以编辑距离这种量化标准一般还需要与单词长度结合起来 明虑在一些极端情况下编辑距离还应该设置为 0比如像 at、on 这类长度只有 2 的短单词。
NGram 一般是指 N 个连续的字符具体的字符个数被定义为 NGram 的 size。size 为 1 的 NGram 称为 Unigram, size 为 2 时称为 Bigram,而 size 为 3 时则称为Trigram。如果 NGram 处理的单元不是字符而是单词一般称之为 Shingle。使用NGram 计算编辑距离的基本思路是让字符串分解为 NGram然后比较分解后共有 NGram 的数量。假设有 a、b 两个字符申则 NGram 距离的具体运算公式为: ngram( a )ngram(b) -2 * ngram(a)∩ngram( b) ngram(a)和 ngram(b)代表 a、b 两个字符串 NGram 的数量; ngram(a) ∩ ngram(b)则是两者共有 NGram 的数量。 例如按 Bigram 处理 firefix 和 firefox 两个单词分别为“fi,ir,re, ef, fi,ix”和“fiir, re, ef, fi, ox。 那么两个字符申的 Bigram 个数都为 6而共有 Bigram 为 4则最终 NGram 距离为 66-2x44。 在应用上Levenshtein 算法更多地应用于对单个词项的模糊查询上而 NGram 则应用于多词项匹配中。Elasticseareh 同时应用了两种算法。
2.2 模糊查询
返回包含与搜索字词相似的字词文档为了找到相似的术语fuzzy 查询将 在指定的编辑距离内创建一组搜索词的所有可能的变体或扩展。查询然后返回每个扩展的完全匹配。 比如
get indexname/_search{query: {fuzzy: {message: {value: firefix,fuzziness: 1}}}
}我们想找到文档中 message 字段包含 firefox而查询条件中给出的是 firefix因为两者的编辑距离为 1所以包含 firefox 的文档依然可以找到但是如果使用 firefit因为编辑距离为 2则不会找到任何文档。
相关的参数有 value: 必填项希望在 field 中找到的术语。 fuzziness: 选填项匹配允许的最大编辑距离可以被设置为“0” “1”“2”或“auto”。“auto”是推荐的选项它会根据查询词的长度定义距离。 max_expansions: 选填项创建的最大变体项默认为 50。应该避免使用较大的值尤其是当 prefix_length 参数值为 0 时如果过多会影响查找性能。 prefix_length: 选填项创建扩展时保留不变的开始字符数。默认为 0。 transpositions: 选填项指示编辑是否包括两个相邻字符串的转置ab→ba。默认为 true。
2.3 纠错与提示器
纠错是在用户提交了错误的词项时给出正确词项的提示而输人提示则是在 用户输人关键字时给出智能提示甚至可以将用户未输人完的内容自动补全。大多数互联网搜索引擎都同时支持纠错和提示的功能比如在用户提交了错误的搜索关键字时会提示:“ 你是不是想查找…”.而在用户输人搜索关键字时还能自动弹出提示框将用户可能要输人的内容全都列出来供用户选择。
Elasticsearch 也同时支持纠错与提示功能由于这两个功能从实现的角度来说并没有本质区别所以它们都由一种被称为提示器或建议器( Suggester)的特殊检索实现。由于输人提示需要在用户输人的同时给出提示词所以这种功能要求速度必须快否则就失去了提示的意义。在实现上输人提示是由单独的提示器完成。而在使用上提示器则是通过检索接口_ search 的一个参数设置例如:
POST indexname/_search?filter_pathsuggest{suggest: {msg-suggest: {text: firefit chrom,term: {field: message}}}
}在示例中search 接口的 suggest 参数中定义了一个提示 msg- suggest,并通过 text 参数给出需要提示的内容。另一个参数 term 实际上是一种提示器的名称它会分析 text 参数中的字符串并提取词项再根据 Levenshtein 算法找到满足编辑距离的提示词项。所以在返回结果中会包含一个 suguggest 字段其中列举了依照 term 提示器找到的提示词项:
2.3 提示器
Elaticearch 提供了三种提示器它们在本质上都是基于编辑距离算法。下面就来看看这此提示器如何使用。 term 提示器 这种提示器默认使用的算法是称为 internal 的编辑距离算法。intermal 算法本质上就是 Levenshtein 算法但根据 Elasticsearch 索引特征做了一些优化而效率更高可以通过 string distance 参数更改算法。 term 提示器使用的编辑距离可通过 max edits 参数设置默认值为 2。
phrase 提示器 terms 会将需要提示的文本拆分成词项然后对每一个词项做单独的提示 而 phrase 提示器则会使用整个文本内容做提示。所以在 phrase 提示器的返回结果中不会看到一个词项一个词项的提示而是针对整个短语的提示。但从使用的角度来看几乎是一样的例如:
POST indexname/_search{suggest: {msg-suggest: {text: firefix with chrime,phrase: {field: message}}}
} 但不要被 phrase 提示器返回结果欺骗这个提示器在执行时也会对需要提 示的文本内容做词项分析然后再通过 NGram 算法计算整个短语的编辑距离。所以本质上来说phrase 提示是基于 term 提示器的提示器同时使用了Levenshtein 和 NGram 算法。
completion 提示器 completion 提示器一般应用于输人提示和自动补全也就是在用户输人的同时给出提示或补全未输入内容。这就要求 completion 提示器必须在用户输人结束前快速地给出提示所以这个提示器在性能上做了优化以达到快速检索的目的。 首先要求提示词产生的字段为 completion 类型这是一种专门为completion提示器而设计的字段类型它会在内存中创建特殊的数据结构以满足快速生成提示词的要求。例如在示例中创建了 aricles 索引并向其中添加了 1 份文档:
PUT articles{mappings: {properties: {author: {type: keyword},content: {type: text},suggestions: {type: completion}}}
}POST articles/_doc/{author: taylor,content: an introduction of elastic stack and elasticsearch,suggestions: {input: [elastic stack,elasticsearch],weight: 10}
}POST articles/_doc/{author: taylor,content: an introduction of elastic stack and elasticsearch,suggestions: [{input: elasticsearch,weight: 30},{input: elastic stack,weight: 1}]
}在向 completion 类型的字段添加内容时可以使用两个参数input 参数设置 字段实际保存的提示词;而 weight 参数则设置了这些提示词的权重权重越高它在返回的提示词中越靠前。在示例 5-29 中给出了两种设置提示词权重的方式第一种是将一组提示词的权重设置为统一值另一种则是分开设置它们的权重值。需要注意的是completion 类型字段保存的提示词是不会分析词项的。 completion 提示器专门用于输人提示或补全它根据用户已经输人的内容提示完整词项,所以在 completion 提示器中没有 text 参数而是使用 prefix 参数。例如:
POST articles/_search{_source: suggest,suggest: {article_suggestion: {prefix: ela,completion: {field: suggestions}}}
}总结一下term 和 phrase 提示器主要用于纠错term 提示器用于对单个词项的纠错而 phrase 提示器则主要针对短语做纠错。completion 提示器是专门用于输人提示和自动补全的提示器在使用上依赖前缀产生提示并且速度更快。
