第一小节 Lucene 常见查询的使用

  从本篇文章开始介绍 Lucene 查询阶段的内容,由于 Lucene 提供了几十种不同方式的查询,但其核心的查询逻辑是一致的,该系列的文章通过 Query 的其中的一个子类 BooleanQuery,同时也是作者在实际业务中最常使用的,来介绍 Lucene 的查询原理。

查询方式

  下文中先介绍几种常用的查询方式的简单应用:

  • TermQuery
  • BooleanQuery
  • WildcardQuery
  • PrefixQuery
  • FuzzyQuery
  • RegexpQuery
  • PhraseQuery
  • TermRangeQuery
  • PointRangeQuery

TermQuery

图 1:

  图 1 中的 TermQuery 描述的是,我们想要找出包含**域名(FieldName)为“content”,域值(FieldValue)中包含“a”的域(Field)**的文档。

  该查询方式的 demo 见: https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo/src/main/java/lucene/query/TermQueryTest.java

BooleanQuery

图 2:

  BooleanQuery 为组合查询,图 2 中给出了最简单的多个 TermQuery 的组合(允许其他查询方式的组合),上图中描述的是,我们期望的文档必须至少(根据 BooleanClause.Occur.SHOULD)满足两个 TermQuery 中的一个,如果都满足,那么打分更高。

  该查询方式的 demo 见: https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo/src/main/java/lucene/query/BooleanQueryTest.java

WildcardQuery

  该查询方式为通配符查询,支持两种通配符:

1
2
3
4
5
6
    // 星号通配符 *
    public static final char WILDCARD_STRING = '*';
    // 问号通配符 ?
    public static final char WILDCARD_CHAR = '?';
    // 转义符号(escape character)
    public static final char WILDCARD_ESCAPE = '\\';

  星号通配符描述的是匹配零个或多个字符,问号通配符描述的是匹配一个字符,转义符号用来对星号跟问号进行转移,表示这两个作为字符使用,而不是通配符。

图 3:

  问号通配符的查询:

图 4:

  图 4 中的查询会匹配 文档 3,文档 1

  星号通配符的查询:

图 5:

  图 4 中的查询会匹配 文档 0、文档 1、文档 2、文档 3

  转义符号的使用:

图 6:

  图 4 中的查询会匹配 文档 3

  该查询方式的 demo 见: https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo/src/main/java/lucene/query/WildcardQueryTest.java

PrefixQuery

  该查询方式为前缀查询:

图 7:

  图 7 中的 PrefixQuery 描述的是,我们想要找出包含 域名为“content”,域值的前缀值为"go"的域 的文档。

  以图 3 为例子,图 7 的查询会匹配 文档 0、文档 1

  该查询方式的 demo 见: https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo/src/main/java/lucene/query/PrefixQueryTest.java

FuzzyQuery

  该查询方式为模糊查询,使用编辑距离来实现模糊匹配, 下面的查询都是以图 3 作为例子

图 8:

  图 8 中的各个参数介绍如下:

  • maxEdits:编辑距离的最大编辑值
  • prefixLength:模糊匹配到的 term 的至少跟图 8 中的域值"god"有两个相同的前缀值,即 term 的前缀要以"go"开头
  • maxExpansions:在 maxEidts 跟 prefixLength 条件下,可能匹配到很多个 term,但是只允许处理最多 20 个 term
  • transpositions:该值在本篇文档中不做介绍,需要了解 确定型有穷自动机 的知识

  图 8 中的查询会匹配 文档 0、文档 1

图 9:

  图 9 中的方法最终会调用图 8 的构造方法,即 maxExpansions 跟 transpositions 的值会使用默认值:

  • maxExpansions:默认值为 50
  • transpositions:默认值为 true

  图 9 中的查询会匹配 文档 0、文档 1

图 10:

  图 10 中的方法最终会调用图 8 的构造方法,即 prefixLength、maxExpansions 跟 transpositions 的值会使用默认值:

  • prefixLength:默认值为 0
  • maxExpansions:默认值为 50
  • transpositions:默认值为 true

  图 10 中的查询会匹配 文档 0、文档 1、文档 2、文档 3

图 11:

  图 11 中的方法最终会调用图 8 的构造方法,即 maxEdits、maxEprefixLength、maxExpansions 跟 transpositions 的值会使用默认值:

  • maxEdits:默认值为 2
  • prefixLength:默认值为 0
  • maxExpansions:默认值为 50
  • transpositions:默认值为 true

  图 10 中的查询会匹配 文档 0、文档 1、文档 2、文档 3

  该查询方式的 demo 见: https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo/src/main/java/lucene/query/FuzzyQueryTest.java

RegexpQuery

  该查询方式为正则表达式查询,使用正则表达式来匹配域的域值:

图 12:

  图 12 中的 RegexpQuery 描述的是,我们想要找出包含**域名(FieldName)为“content”,域值(FieldValue)中包含以"g"开头,以"d"结尾,中间包含零个或多个"o"的域(Field)**的文档。

  图 12 中的查询会匹配 文档 0、文档 1、文档 2

  该查询方式的 demo 见: https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo/src/main/java/lucene/query/RegexpQueryTest.java

PhraseQuery

图 13:

  该查询方式为短语查询:

图 14:

  图 14 中,我们定义了两个 Term,域值分别为"quick"、“fox”,期望获得的这样文档:文档中必须包含这两个 term,同时两个 term 之间的相对位置为 2 (3 - 1),并且允许编辑距离最大为 1,编辑距离用来 调整 两个 term 的相对位置(必须满足)。

  故根据图 13 的例子,图 14 中的查询会匹配 文档 0、文档 1、文档 2

图 15:

  图 15 中,我们另编辑距离为 0,那么改查询只会匹配 文档 0、文档 1

图 16:

  图 16 中,我们另编辑距离为 4,此时查询会匹配 文档 0、文档 1、文档 2、文档 3

  这里简单说下短语查询的匹配逻辑:

  • 步骤一:找出同时包含"quick"跟"fox"的文档
  • 步骤二:计算"quick"跟"fox"之间的相对位置能否在经过编辑距离调整后达到查询的条件

  该查询方式的 demo 见: https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo/src/main/java/lucene/query/PhraseQueryTest.java

TermRangeQuery

图 17:

  该查询方式为范围查询:

图 18:

  图 18 中的查询会匹配 文档 1、文档 2、文档 3

  在后面的文章中会详细介绍 TermRangeQuery,对这个查询方法感兴趣的同学可以先看 Automaton,它通过确定型有穷自动机的机制来找到查询条件范围内的所有 term。

  该查询方式的 demo 见: https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo/src/main/java/lucene/query/TermRangeQueryTest.java

PointRangeQuery

图 19:

  该查询方式为域值是数值类型的范围查询(多维度查询):

图 20:

  PointRangeQuery 用来实现多维度查询,在图 19 中,文档 0 中域名为"coordinate",域值为"2, 8"的 IntPoint 域,可以把该域的域值看做是直角坐标系中一个 x 轴值为 2,y 轴值为 8 的一个坐标点。

  故文档 1 中域名为"coordinate"的域,它的域值的个数描述的是维度的维数值。

  在图 20 中,lowValue 描述的是 x 轴的值在[1, 5]的区间,upValue 描述的 y 轴的值在[4, 7]的区间,我们期望找出由 lowValue 和 upValue 组成的一个矩形内的点对应的文档。

图 21:

  图 21 中红框描述的是 lowValue 跟 upValue 组成的矩形。

  故图 20 中的查询会匹配 文档 1

  在后面的文章中会详细介绍 PointRangeQuery 的查询过程,对这个查询方法感兴趣的同学可以先看 Bkd-Tree 以及 索引文件之 dim&&dii,这两篇文章介绍了在索引阶段如何存储数值类型的索引信息。

  该查询方式的 demo 见: https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo/src/main/java/lucene/query/PointRangeQueryTest.java

第二小节

  在第一小节的文章中,我们介绍了几种常用查询方式的使用方法,从本篇文章开始,通过 BooleanQuery 来介绍查询原理。

查询原理流程图

图 1:

执行 IndexSearcher 的 search()方法

  根据用户提供的不同参数 IndexSearcher 类提供了多种 search( )方法:

  • 分页参数:当用户提供了上一次查询的 ScoreDoc 对象就可以实现分页查询的功能,该内容的实现方式已经在 Collector(二) 中介绍,不赘述
  • 排序参数:用户通过提供 Sort 参数使得查询结果按照自定义的规则进行排序,默认使用 TopFieldCollector 对满足查询条件的结果进行排序。
  • Collector 参数:用户通过提供 Collector 收集器来自定义处理那些满足查询条件的文档的方法,如果不提供,那么默认使用 TopFieldCollector 或者 TopScoreDocCollector,如果用户提供了 Sort 参数,那么使用前者,反之使用后者
  • TopN 参数:用户通过提供该参数用来描述期望获得的查询结果的最大个数

  至于使用上述不同的参数对应哪些不同的 search( )就不详细展开了,感兴趣的同学可以结合上述的参数介绍及源码中的几个 search( ) 方法,相信很容易能理解。

重写 Query

  每一种 Query 都需要重写(rewrite)才能使得较为友好的接口层面(API level)的 Query 完善 成一个"最终的(final)“Query,如果这个 Query 已经是"最终的”,就不需要重写,这个最终的 Query 在源码注释中被称为 primitive query。

  图 2 中定义了一个 TermQuery(接口层面(API level)的 Query),它**显示的(explicit)**描述了满足查询条件的文档必须包含一个域名(FieldName)为"content",域值(FIeldValue)中包含"a"的 term(对域值分词后的每一个结果称为 term)的域,我们称这种 TermQuery 是"最终"的 Query。在 TermQuery 中,我们能显示的知道,查询的 term 为"a"。

图 2:

  图 3 中定义了一个 PrefixQuery(前缀查询,见第一小节),它描述了满足条件的文档必须包含一个域名为"content",域值中包含前缀为"go"的 term 的域,相比较 TermQuery,这个查询没有 显示的 在用户使用的接口层面(API level)描述我们要查询具体哪个 term,我们称之为这不是一个“最终”的 Query,故需要通过重写 Query 来完善成一个新的 Query,先找到以"go"为前缀的所有 term 集合,然后根据这些 term 重新生成一个 Query 对象,具体过程在下文中展开。

图 3:

注意的是上述的介绍只是描述了重写 Query 的其中一个目的。

  根据第一小节中介绍的 9 种 Query,我们分别来讲解这些 Query 的重写过程。

TermQuery

  TermQuery 不需要重写。

PointRangeQuery

  数值类型的查询,它没有重写的必要。

BooleanQuery

  BooleanQuery 的重写过程在 BooleanQuery 的文章中介绍,不赘述。

PhraseQuery

  PhraseQuery 的重写会生成以下两种新的 Query:

  • TermQuery:图 4 中的 PhraseQuery,它只有一个域名为“content”,域值为"quick"的 term,这种 PhraseQuery 可以被重写为 TermQuery,TermQuery 是所有的查询性能最好的查询方式(性能好到 Lucene 认为这种查询方式都不需要使用缓存机制,见 LRUQueryCache,可见这次的重写是一个完善的过程

图 4:

  • PhraseQuery:图 5 中的 PhraseQuery 跟图 6 中的 PhraseQuery,他们的查询结果实际是一致的,因为对于图 5 的 PhraseQuery,它会在重写 PhraseQuery 后变成图 6 中的 PhraseQuery,也就是这种查询方式只关心 term 之间的相对位置,对于图 5 中的 PhraseQuery,在重写的过程中,“quick"的 position 参数会被改为 0,“fox"的 position 参数会被改为 2,由于本篇文章只是描述 PhraseQuery 的重写过程,对于为什么要做出这样的重写逻辑,在后面的文章中会展开介绍

图 5:

图 6:

FuzzyQuery、WildcardQuery、PrefixQuery、RegexpQuery、TermRangeQuery

  这几种 Query 的重写逻辑是一致的,在重写的过程中,找到所有的 term,每一个生成对应的 TermQuery,并用 BooleanQuery 封装。

  他们的差异在于不同的 Query 还会对 BooleanQuery 进行再次封装,不过这不是我们本篇文章关心的。

  下面用一个例子来说明上面的描述:

图 7:

图 8:

  图 8 中我们使用 TermRangeQuery 对图 7 中的内容进行查询。

图 9:

  图 9 中我们使用 BooleanQuery 对图 7 中的内容进行查询。

  图 8 中 TermRangeQuery 在重写的过程中,会先找到"bc” ~ “gc"之间的所有 term(查找方式见 Automaton),这些 term 即"bcd”、“ga”、“gc”,然后将他们生成对应的 TermQuery,并用 BooleanQuery 进行封装,所以图 8 中的 TermRangeQuery 相当于图 9 中的 BooleanQuery。

  不得不提的是,TermRangeQuery 最终重写后的 Query 对象不仅仅如此,生成 BooleanQuery 只是其中最重要,最关键的一步,本篇文章中我们只需要了解到这个程度即可,因为在后面的文章会详细介绍 TermRangeQuery。

  所有的 Query 在查询的过程中都会执行该流程点,但不是重写 Query 唯一执行的地方,在构建 Weight 的过程中,可能还会执行重写 Query 的操作。

生成 Weight

  不同的 Query 生成 Weight 的逻辑各不相同,由于无法介绍所有的情况,故挑选了最最常用的一个查询 BooleanQuery 来作介绍。

图 10:

图 11:

  图 10 跟图 11 分别是索引阶段跟查询阶段的内容,我们在查询阶段定义了一个 BooleanQuery,封装了 3 个 TermQuery,该查询条件描述的是:我们期望获得的文档中至少包含三个 term,“h”、“f”、“a"中的一个。

BooleanWeight

  对于上述的例子中,该 BooleanQuery 生成的 Weight 对象如下所示:

图 12:

  BooleanQuery 生成的 Weight 对象即 BooleanWeight 对象,它由三个 TermWeight 对象组合而成,TermWeight 即图 11 中封装的三个 TermQuery 对应生成的 Weight 对象。

TermWeight

  图 13 中列出了 TermWeight 中至少包含的几个关键对象:

图 13:

Similarity

  Similarity 描述的是当前查询使用的文档打分规则,当前 Lucene7.5.0 中默认使用 BM25Similarity。用户可以使用自定义的打分规则,可以在构造 IndexSearcher 后,执行 IndexSearcher 的 search()方法前,调用 IndexSearcher.setSimilarity(Similarity) 的方法设置。Lucene 的文档打分规则在后面的文章中会展开介绍。

SimWeight

图 14:

  图 14 中描述的是 SimWeight 中包含的几个重要的信息,这些信息在后面的流程中用来作为文档打分的参数,由于 SimWeight 是一个抽象类,在使用 BM25Similarity 的情况下,SimWeight 类的具体实现是 BM25Stats 类。

  我们以下图中红框标识的 TermQuery 为例子来介绍 SimWeight 中的各个信息

图 15:

field

  该值描述的是 TermQuery 中的域名,在图 15 中,field 的值即“content”。

idf

  idf 即逆文档频率因子,它的计算公式如下:

1
    (float) Math.log(1 + (docCount - docFreq + 0.5D)/(docFreq + 0.5D))
  • docCount:该值描述是包含域名为“content”的域的文档的数量,从图 10 中可以看出,文档 0~文档 9 都包含,故 docCount 的值为 10
  • docFreq:该值描述的是包含域值"h"的文档的数量,从图 10 中可以看出,只有文档 0、文档 8 包含,故 docFreq 的值为 2
  • 0.5D:平滑值
boost

  该值描述的是查询权值(即图 17 中打分公式的第三部分),boost 值越高,通过该查询获得的文档的打分会更高。

  默认情况下 boost 的值为 1,如果我们期望查询返回的文档尽量是通过某个查询获得的,那么我们就可以在查询(搜索)阶段指定这个查询的权重,如下图所示:

图 16:

  相比较图 15,在图 16 中,我们使用 BoostQuery 封装了 TermQuery,并显示的指定这个查询的 boost 值为 100。

  图 16 中的查询条件表达了这么一个意愿:我们更期待在执行搜索后,能获得包含"h"的文档。

avgdl

  avgdl(average document length,即图 17 中打分公式第二部分中参数 K 中的 avgdl 变量)描述的是平均每篇文档(一个段中的文档)的长度,并且使用域名为"content"的 term 的个数来描述平均每篇文档的长度。

  例如图 7 中的文档 3,在使用空格分词器(WhitespaceAnalyzer)的情况下,域名为"content”,域值为"a c e"的域,在分词后,文档 3 中就包含了 3 个域名为"content"的 term,这三个 term 分别是"a”、“c”、“e”。

  avgdl 的计算公式如下:

1
    (float) (sumTotalTermFreq / (double) docCount)
  • sumTotalTermFreq:域名为"content"的 term 的总数,图 7 中,文档 0 中有 1 个、文档 1 中有 1 个,文档 2 中有 2 个,文档 3 中有 3 个,文档 4 中有 1 个,文档 5 中有 2 个,文档 6 中有 3 个,文档 7 中有 1 个,文档 8 中有 8 个,文档 9 中有 6 个,故 sumTotalTermFreq 的值为(1 + 1 + 2 + 3 + 1 + 2 + 3 + 1 + 8 + 6)= 28
  • docCount:同 idf 中的 docCount,不赘述,该值为 10
cache

  cache 是一个数组,数组中的元素会作为 BM25Similarity 打分公式中的一个参数 K(图 17 打分公式第二部分的参数 K),具体 cache 的含义会在介绍 BM25Similarity 的文章中展开,在这里我们只需要了解 cache 这个数组是在生成 Weight 时生成的。

weight

  该值计算公式如下:

1
    idf * boost

  图 17 是 BM25Similarity 的打分公式,它由三部分组成,在 Lucene 的实现中,第一部分即 idf,第三部分即 boost, 至此我们发现,在生成 Weight 的阶段,除了文档号跟 term 在文档中的词频这两个参数,我们已经获得了计算文档分数的其他条件,至于为什么需要文档号,不是本篇文章关系的部分,再介绍打分公式的文章中会展开介绍,另外 idf 跟 boost 即 SimWeight 中的信息,不赘述。

图 17:

图 17 源自于 « 这就是搜索引擎 »,作者:张俊林。

TermContext

图 18:

  图 18 中描述的是 TermContext 中包含的几个重要的信息, 其中红框标注表示生成 Weight 阶段需要用到的值,这些信息通过读取索引文件 [.tip、tim](https://zshipu.com/t?url=https%3A%2F%2Fwww.amazingkoala.com.cn%2FLu