近实时搜索NRT(五)

  本文承接近实时搜索NRT(四),继续依次介绍每一个流程点,阅读本文章需要看过文档的增删改文档提交之flush的系列文章。

openIfChange方法的流程图

  其中openIfChange的方法一&&方法二、方法三&&方法四的逻辑需要用图1、图2两个流程图展现:

图1:

点击查看大图

图2:

点击查看大图

从IndexWriter中获取StandardDirectoryReader

图3:

  如果oldReader是通过open方法(见近实时搜索NRT(一)近实时搜索NRT(四))中的方法三或者方法四获得,那么oldReader就持有IndexWriter对象(见近实时搜索NRT(三)),当调用了openIfChange的方法一,该方法就会执行图3中的流程,这种方法属于NRT。

  图3的流程描述了这么一个过程:根据oldReader中持有的IndexWriter判断索引是否发生变化,即流程点根据IndexWriter判断索引是否发生变化?,发生变化则需要重新生成StandardDirectoryReader,如果生成了新的StandardDirectoryReader,那么需要再次跟oldReader作比较,即流程点新旧StandardDirectoryReader是否一致?,如果不相同,那么返回这个新的StandardDirectoryReader,否则返回null。

  根据IndexWriter判断索引是否发生变化需要判断下面四个条件,依次同时满足视为没有发生变化

  需要满足条件二、条件三、条件四正是说明了我们重新获得StandardDirectoryReader中包含了未提交(commit操作)的索引信息,所以这种方法属于NRT(见近实时搜索NRT(一)文章中对NRT的定义)。

  为什么需要同时满足上面的四个条件(重要):

  生成了新的StandardDirectoryReader后,为什么还要跟oldReader比较是否一致(相同)

  为什么已经在流程点根据IndexWriter判断索引是否发生变化?已经判断出索引信息发生变化,还会出现新的StandardDirectoryReader跟oldReader包含相同的索引信息(重要)

结语

  至此我们介绍完了图1中的所有流程,由于图2中的流程点与图1中的流程点是重复的,所以不对图2的流程展开介绍,那么Lucene提供的性能更高获得StandardDirectoryReader对象的openIfChange()方法就都介绍结束了。

  在下一篇文章中,我们将会继续DirectoryReader的其他子类(见近实时搜索NRT(一)的图1)。

点击下载附件