构造对象七
本文承接 构造 IndexWriter 对象(六),继续介绍调用 IndexWriter 的构造函数的流程。
调用 IndexWriter 的构造函数的流程图
图 1:
生成对象 IndexFileDeleter
在文章 构造 IndexWriter 对象(六) 中,我们简单介绍了 IndexFileDeleter 作用,即用来删除索引目录中的索引文件,本文根据 IndexFileDeleter 的构造函数的实现来介绍关于计数引用、删除无效(Invalid)索引文件的内容。
IndexFileDeleter 的构造函数流程图
图 2:
SegmentInfos
图 3:
构造 IndexFileDeleter 最重要的一个对象就是 SegmentInfos,它是在图 1 的 生成对象IndexFileDeleter
流程点之前通过用户配置的 IndexCommit 或者索引目录中的旧索引生成的 SegmentInfos 对象(见 构造 IndexWriter 对象(三)、 构造 IndexWriter 对象(四)、 构造 IndexWriter 对象(五) 中关于生成 SegmentInfos 的介绍),并作为 IndexFileDeleter 的构造函数的参数之一。
是否能获得索引文件 segments_N 的文件名?
图 4:
构造 IndexWriter 对象里面调用 IndexFileDeleter 的构造函数时,总是能通过 SegmentInfos 获得一个 segments_N 的文件名,并且通过下面的方法来获得 segments_N 的文件名,那么当前流程点的判断结果总是为 true,由于该方法可能会返回 null,所以在这里会有一个判断。
SegmentInfos.getSegmentsFileName()#### 判断索引文件是否满足要求
图 5:
接着就是从索引目录依次取出索引文件,然后判断是否满足某个要求。
需要满足什么要求:
先给出该要求对应的代码:
if (!fileName.endsWith("write.lock") && (m.matches() || fileName.startsWith(IndexFileNames.SEGMENTS) || fileName.startsWith(IndexFileNames.PENDING_SEGMENTS)){
... ...
}
其中 fileName 就是待处理的索引文件的文件名、m.matches()描述的是 fileName 是否满足下面的正则表达式
[a-z0-9]+(. )?\.. 上述的代码进行拆分后即需要满足下面三个字要求之一:
- 子要求一:!fileName.endsWith(“write.lock”) && (m.matches()
- writer.lock 即索引目录的 索引文件锁,用来同步不同的 IndexWriter 对象,只允许一个 IndexWriter 可以操作同一个索引目录,占用了索引文件锁的 IndexWriter 可以通过调用 Inde.close()方法来释放该锁,wrtier.lock 不满足要求
- m.matches()则是根据正则表达式来匹配命名方式为下图中的文件名,满足正则表达式即满足要求:
图 6:
- 子要求二:fileName.startsWith(IndexFileNames.SEGMENTS)
- 满足以"segment"开头的文件名即满足子要求二,比如 segments_N 文件
- 子要求三:fileName.startsWith(IndexFileNames.PENDING_SEGMENTS)
- 满足以“pending_segments”开头的文件名即满足子要求三,比如执行 commit()操作时,在两阶段提交之第一阶段会生成该命名方式的文件,详细见文件 文档提交之 commit(二)
初始化索引文件的计数引用
图 7:
如果索引文件满足上文中的要求,那么我们初始化这些索引文件的计数引用。
Lucene 中如何实现对索引文件的计数引用:
通过一个 HashMap 对象 refCounts 以及一个 RefCount 类实现,他们的定义如下所示:
final private static class RefCount {
final String fileName; // 索引文件名
int count; // 计数值
public int IncRef() {
// 增加计数
}
public int DecRef() {
// 减少计数
}
}
// key 为索引文件名,value 为 RefCount 对象
private Map<String, RefCount> refCounts = new HashMap<>();
如果我们要增加某个索引文件的计数引用,那么根据 refCounts 找到该文件对应的 RefCount 对象,接着通过对象的 IncRef()方法来增加计数。
上述的 RefCount 类的具体内容可以查看这个链接: https://github.com/LuXugang/Lucene-7.5.0/blob/master/solr-7.5.0/lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java 。
索引文件是否为 segments_N?
图 8:
如果是 segments_N 文件,那么需要对该文件进行额外的处理,判断方法同上文中的子要求二。
处理索引目录中所有的 segments_N
图 9:
索引目录中可能存在多个 segments_N 文件,那么这些文件都需要被处理,其中只有一个 segments_N 对应的 SegmentInfos 为构造 IndexFileDeleter 对象的参数,即图 2 中 SegmentInfos
流程点的 segmentInfos。
为什么索引目录中会存在多个 segments_N 文件:
原因主要取决于上一个 IndexWriter 对象使用了哪种索引删除策略 IndexDeletionPolicy(见 文档提交之 commit(二) 关于 IndexDeletionPolicy 的介绍),比如使用了索引删除策略 NoDeletionPolicy,那么每次提交都会保留,又比如使用了默认的索引删除策略 KeepOnlyLastCommitDeletionPolicy,那么只会保留最后一次提交。
图 10:
在图 10 中,使用不同的索引删除策略对相同的数据进行索引,在执行了 4 次 commit 提交后,对于 NODeletetionPolicy 来说,它会保留所有的提交,而对于 KeepOnlyLastCommitDeletionPolicy,当生成 segments_2 时,会删除 segments_1,生成 segments_3 时,会删除 segments_2,以此类推,即只保留最后一次提交。
为什么要根据每一个 segments_N 对应的 SegmentInfos 生成 CommitPoint,并且添加到 CommitPoint 集合 commits 中:
- 原因是我们需要根据正在构造的 IndexWriter 对象中的索引删除策略来处理这些提交,而 CommitPoint 对象为索引删除策略作用的对象。
- 这里将所有的 CommitPoint 添加到 c
- 原文作者:知识铺
- 原文链接:https://geek.zshipu.com/post/%E4%BA%92%E8%81%94%E7%BD%91/%E6%9E%84%E9%80%A0%E5%AF%B9%E8%B1%A1%E4%B8%83/
- 版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可,非商业转载请注明出处(作者,原文链接),商业转载请联系作者获得授权。
- 免责声明:本页面内容均来源于站内编辑发布,部分信息来源互联网,并不意味着本站赞同其观点或者证实其内容的真实性,如涉及版权等问题,请立即联系客服进行更改或删除,保证您的合法权益。转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。也可以邮件至 sblig@126.com