Fork me on GitHub

AIQ 10023 号成员
  •  0 回帖  •  1.4K 浏览  •  4 年前
   

构造 IndexWriter 对象（三）

查看原文

系列文章：

构造 IndexWriter 对象（二）

构造 IndexWriter 对象（一）

构造一个 IndexWriter 对象的流程总体分为下面三个部分：

  • 设置索引目录 Directory
  • 设置 IndexWriter 的配置信息 IndexWriterConfig
  • 调用 IndexWriter 的构造函数

  大家可以查看文章构造 IndexWriter 对象（一）、构造 IndexWriter 对象（二）来了解前两部分的内容，我们接着继续介绍最后一个部分，即调用 IndexWriter 的构造函数。

  IndexWriter 类有且仅有一个有参构造函数，如下所示：

public IndexWriter(Directory d, IndexWriterConfig conf) throws IOException {
    ... ...
}

其中参数 d 以及 conf 正是分别由 设置索引目录Directory、设置IndexWriter的配置信息IndexWriterConfig 两部分获得。

调用 IndexWriter 的构造函数的流程图

图 1：

1-(2).png

获取索引目录的索引文件锁

图 2：

2-(1).png

  该流程为 Lucene 使用索引文件锁对索引文件所在的目录进行加锁，使得同一时间总是只有一个 IndexWriter 对象可以更改索引文件，即保证单进程内(single in-process)多个不同 IndexWriter 对象互斥更改（多线程持有相同引用的 IndexWriter 对象视为一个 IndexWriter 不会受制于 LockFactory，而是受制于对象锁（synchronized(IndexWriter)）、多进程内(multi-processes)多个对象互斥更改。

  更多关于索引文件锁的介绍可以看文章索引文件锁 LockFactory。

获取封装后的 Directory

图 3：

3.png

  该流程中我们需要对 Directory 通过 LockValidatingDirectoryWrapper 对象进行再次封装， 使得在对索引目录中的文件进行任意形式的具有"破坏性"（destructive）的文件系统操作（filesystem operation）前尽可能（best-effort）确保索引文件锁是有效的（valid）。

  索引目录中的"破坏性"的文件系统操作包含下面几个内容：

  • deleteFile(String name)方法：删除索引目录中的文件
  • createOutput(String name, IOContext context)方法：在索引目录中创建新的文件
  • copyFrom(Directory from, String src, String dest, IOContext context)方法：在索引目录中，将一个文件中的内容 src 复制到同一个索引目录中的另外一个不存在的文件 dest
  • rename(String source, String dest)方法：重命名索引目录中的文件
  • syncMetaData()方法：磁盘同步操作
  • sync(Collection names)方法：磁盘同步操作

获取 IndexCommit 对应的 StandardDirectoryReader

图 4：

4.png

  如果 IndexWriter 的配置信息 IndexWriterConfig 设置了 IndexCommit 配置，那么我们需要获得描述 IndexCommit 中包含的信息的对象，即 StandardDirectoryReader，生成 StandardDirectoryReader 的目的在后面的流程中会展开介绍，这里只要知道它的生成时机即可。

  IndexCommit 的介绍可以查看文章构造 IndexWriter 对象（一），而 StandardDirectoryReader 的介绍可以查看近实时搜索 NRT、SegmentReader 系列文章，这里不赘述。

根据不同的 OpenMode 执行对应的工作

图 5：

5.png

  从图 5 中可以看出，尽管 Lucene 提供了三种索引目录的打开模式，但实际上只有 CREATE 跟 APPEND 两种打开模式的逻辑，三种模式的介绍可以看文章构造 IndexWriter 对象（一），这里不赘述。

  在源码中，使用一个布尔值 indexExists 来描述图 5 中的流程点 索引目录中是否已经存在旧的索引？，如果存在，那么 indexExists 的值为 true，反之为 false。indexExists 在后面的流程中会被用到。

  下面我们分别介绍 执行CREATE模式下的工作、执行APPEND模式下的工作 这两个流程。

执行 CREATE 模式下的工作的流程图

图 6：

6.png

配置检查 1

图 7：

7.png

  该流程会检查用户是否正确设置了 IndexCommit 跟 OpenMode 两个配置，由于代码比较简单，故直接给出：

if (config.getIndexCommit() != null) {

    // 条件一    if (mode == OpenMode.CREATE) {        throw new IllegalArgumentException("cannot use IndexWriterConfig.setIndexCommit() with OpenMode.CREATE");    // 条件二    } else {        throw new IllegalArgumentException("cannot use IndexWriterConfig.setIndexCommit() when index has no commit");    }}

上面的代码描述的是在设置了配置 IndexCommit 之后对 OpenMode 进行配置检查，其中 config 指的是 IndexWriter 的配置信息 IndexWriterConfig 对象：

  • 条件一：如果用户设置的 OpenMode 为 CREATE，由于该模式的含义是生成新的索引或覆盖旧的索引，而设置 IndexCommit 的目的是读取已经有的索引信息，故这两种是相互冲突的逻辑，Lucene 通过抛出异常的方法来告知用户不能这么配置
  • 条件二：如果用户设置的 OpenMode 为 CREATE_OR_APPEND，由于通过图 5 中的流程点 索引目录中是否已经存在旧的索引？ 判断出 indexExists 的值为 false，即索引目录中没有任何的提交，但用户又配置了 IndexCommit，这说明用户配置的 IndexCommit 跟 IndexWriter 类的有参构造函数中的参数 d 必须为同一个索引目录

初始化一个新的 SegmentInfos 对象

图 8：

8.png

  该流程只是描述了生成 SegmentInfos 对象的时机点，没其他多余的内容。

  SegmentInfos 是什么：

同步 SegmentInfos 的部分信息

图 9：

9.png

  如果索引目录中已经存在旧的索引，那么 indexExists 的值为 true，那么我们先需要获得旧的索引中的最后一次提交 commit 中的 SegmentInfos 中的三个信息，即 version、counter、generation：

  • version：该值用来描述 SegmentInfos 发生改变的次数，即索引信息发生改变的次数
  • counter：它跟下划线“_”作为一个组合值，用来描述下一次生成（commit、flush 操作）的新段对应的索引文件的前缀值，下图中"_4"、"_5"的 4、5 即为 counter 值，该值为一个从 0 开始的递增值

图 10：

10.png

  • generation：用来描述执行提交操作后生成的 segments_N 文件的 N 值，图 10 中，generation 的值为 2

  上述三个信息在索引文件 segments_N 中的位置如下所示：

图 11：

11.png

  图 11 中，generation 的值通过索引文件 segments_N 的文件名来获得。

  接着将 version、counter、generation 同步到刚刚初始化的新的 SegmentInfos 对象中。

  为什么执行同步这三个信息的操作：

  • 使得新生成的索引文件不会跟旧的索引文件有一样的名字，即不会覆盖旧的索引文件，那么其他线程可以正常通过 IndexCommit 读取旧索引执行搜索。

设置回滚

图 12：

12.png

  该流程为回滚的初始化，初始化一个叫做 rollbackSegments 的链表，该链表的定义如下：

private List<SegmentCommitInfo> rollbackSegments;

  如果索引目录中存在旧的索引，那么另旧的索引对应的 SegmentInfos 对象中的 segments 对象赋值给回滚内容 rrollbackSegments，否则 rollbackSegments 为 null。在执行 commit()的过程中，rollbackSegments 会被更新为这次提交对应的 segments 对象。segments 对象即图 11 中所有 SegmentCommitInfo 在内存中的描述。

更新 SegmentInfos 的 version

图 13：

13.png

  由于 SegmentInfos 被同步了 version、counter、generation 三个信息，说明 SegmentInfos 发生了变化，那么需要通过更新 SegmentInfos 的 version 来描述这次的变化。

  为什么要记录 SegmentInfos 的变化：

  • 通过 version 判断 SegmentInfos 如果没有发生变化，那么在复用 StandardDirectoryReader 时可以极大的提高性能，至于为什么能提高性能，以及如何提高性能，在近实时搜索 NRT（一）的系列文章中已经介绍，不赘述

结语

  基于篇幅，剩余的内容将在下一篇文章中展开。


本文地址：https://www.6aiq.com/article/1586277004353
本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出