企业🤖AI Agent构建引擎,智能编排和调试,一键部署,支持私有化部署方案 广告
translate by [williamzhao](https://github.com/williamzhao) ## 查询与过滤 前面我们讲到的是关于结构化查询语句,事实上我们可以使用两种结构化语句: 结构化查询(Query DSL)和结构化过滤(Filter DSL)。 查询与过滤语句非常相似,但是它们由于使用目的不同而稍有差异。 一条过滤语句会询问每个文档的字段值是否包含着特定值: * `created` 的日期范围是否在 `2013` 到 `2014` ? * `status` 字段中是否包含单词 "published" ? * `lat_lon` 字段中的地理位置与目标点相距是否不超过10km ? 一条查询语句与过滤语句相似,但问法不同: 查询语句会询问每个文档的字段值与特定值的匹配程度如何? 查询语句的典型用法是为了找到文档: * 查找与 `full text search` 这个词语最佳匹配的文档 * 查找包含单词 `run` ,但是也包含`runs`, `running`, `jog` 或 `sprint`的文档 * 同时包含着 `quick`, `brown` 和 `fox` --- 单词间离得越近,该文档的相关性越高 * 标识着 `lucene`, `search` 或 `java` --- 标识词越多,该文档的相关性越高 一条查询语句会计算每个文档与查询语句的相关性,会给出一个相关性评分 `_score`,并且 按照相关性对匹配到的文档进行排序。 这种评分方式非常适用于一个没有完全配置结果的全文本搜索。 ## 性能差异 使用过滤语句得到的结果集 -- 一个简单的文档列表,快速匹配运算并存入内存是十分方便的, 每个文档仅需要1个字节。这些缓存的过滤结果集与后续请求的结合使用是非常高效的。 查询语句不仅要查找相匹配的文档,还需要计算每个文档的相关性,所以一般来说查询语句要比 过滤语句更耗时,并且查询结果也不可缓存。 幸亏有了倒排索引,一个只匹配少量文档的简单查询语句在百万级文档中的查询效率会与一条经过缓存 的过滤语句旗鼓相当,甚至略占上风。 但是一般情况下,一条经过缓存的过滤查询要远胜一条查询语句的执行效率。 过滤语句的目的就是缩小匹配的文档结果集,所以需要仔细检查过滤条件。 ## 什么情况下使用 原则上来说,使用查询语句做全文本搜索或其他需要进行相关性评分的时候,剩下的全部用过滤语句