Lucene4.3进阶开发之入乡随俗(三)
程序员文章站
2022-05-25 08:29:19
...
转载请务必注明，原创地址，谢谢配合!
http://qindongliang1922.iteye.com/blog/1995329
散仙在前2篇文章中，简单分析了Directory家族的功能以及作用，同时也对Directory家族中我们比较常用的几个子类，做了剖析和归纳，那么本篇文章，散仙就来介绍下与Directory家族经常进行交互的另一大家族IndexReader家族，另外需要说明的是，散仙现在介绍的一些内容都是基于最新版Lucene4.6.0的版本，不过标题名还是Lucene4.3的，为了统一命名，散仙在这里就不改了，因为Lucene最近的更新发布，实在是太活跃了，还是哪一句话，越活跃的东西，前途越光明，就像最近一年来Hadoop的兴起和迅猛发展，lucene也是如此。
好了，开篇又扯淡了几句，下面我们开始进入正题，在这之前，我们先来看下IndexReader家族的家谱图。
下面我们来回忆下，我们在使用lucene的过程中，经常使用到的一行代码：
看过如上代码，我们是不是有种很熟悉的味道，然后我们在对比IndexReader家族图，就大概明白这段代码的意思了。
IndexReader是一个抽象的接口实现，提供了一个接口用于访问索引文件，由此我们可以推断出，任何一个读取索引的操作，就必须用到一个IndexReader的实现类，来辅助完成，否则，我们是不能直接读取索引信息的。
继续看下去，我们会发现IndexReader接口下面有两大类型的Reader实现，一个是基于AtomicReader实现的原子类型，另一个是基于CompositeReader实现的复合类型，那么这两个直接子类，究竟有什么区别和联系呢？
实际上，它们之间的联系我们从上图中，就能清晰的看出来，它们都实现了相同的父接口，所以说从某种程度上来讲，它们之间是可以转换的，事实上也的确如此。在AtomicReader的子类里面提供了一个SlowCompositeReaderWrapper的包装类，来把一个CompositeReader的子类，模拟成一个原子Reader。
那么，CompositeReader和AtomicReader它们之间究竟有什么区别呢？ AtomicReader相对来说更细化，提供了具体层面访问索引文件内容的实现，而CompositeReader则在宏观的方向上，提供了读取索引文件，以及汇合多个索引的功能。
可以打这么一个比方，CompositeReader是一个类似半径为10的圆，而AtomicReader则是一个类似半径为5的圆，而我们的索引存储的数据就在圆心上，当然我们的这个假设是基于立体3维的圆，那么现在，我想要获取圆心上的数据，无论你从哪个方向，哪个位置切入，都必须的先经过大圆的范围，然后经过小圆的范围，最终我们才能获取圆心上存储的数据。所以我们说CompositeReader在宏观上起到了读取索引文件（可能是多份索引的读取（可以是单线程读，也可以是并行读）及合并）的作用，而AtomicReader则在微观的角度上，起到了读取索引文件内容的作用，通过两者组合，我们就可以完美的读取索引文件。
在IndexReader的旗下，又旗帜鲜明的分成了两个基类，这两个基类的下面的各个子类之间，既有区别也有联系，只有相互协作，才能高效的完成读取实现，当然这些lucene都给我们已经封装好了，我们可以在我们任何需要的时候，来调用他们来完成特定的工作，除此之外，我们也可以来自定义我们自己用的特定的reader，来完成某些不常见的功能，因为lucene给我们提供了一个非常方便，强大，而且易扩展的接口，由此可以看出lucene的设计架构充分利用接口和一些抽象类的组合，来使整体设计变更灵活和易扩展。
今天散仙就先分享到这里了，本篇文章的目的很简单，就是让大家在宏观上对IndexReader有一个整体认识和把握，方便我们以后在开发过程中能够做到有选择的，心里有底的，清晰的使用。
转载请务必注明，原创地址，谢谢配合!
http://qindongliang1922.iteye.com/blog/1995329
http://qindongliang1922.iteye.com/blog/1995329
散仙在前2篇文章中，简单分析了Directory家族的功能以及作用，同时也对Directory家族中我们比较常用的几个子类，做了剖析和归纳，那么本篇文章，散仙就来介绍下与Directory家族经常进行交互的另一大家族IndexReader家族，另外需要说明的是，散仙现在介绍的一些内容都是基于最新版Lucene4.6.0的版本，不过标题名还是Lucene4.3的，为了统一命名，散仙在这里就不改了，因为Lucene最近的更新发布，实在是太活跃了，还是哪一句话，越活跃的东西，前途越光明，就像最近一年来Hadoop的兴起和迅猛发展，lucene也是如此。
好了，开篇又扯淡了几句，下面我们开始进入正题，在这之前，我们先来看下IndexReader家族的家谱图。
下面我们来回忆下，我们在使用lucene的过程中，经常使用到的一行代码：
directory=FSDirectory.open(new File(indexReadPath));//打开索引目录 IndexReader reader=DirectoryReader.open(directory);//获取数据句柄
看过如上代码，我们是不是有种很熟悉的味道，然后我们在对比IndexReader家族图，就大概明白这段代码的意思了。
IndexReader是一个抽象的接口实现，提供了一个接口用于访问索引文件，由此我们可以推断出，任何一个读取索引的操作，就必须用到一个IndexReader的实现类，来辅助完成，否则，我们是不能直接读取索引信息的。
继续看下去，我们会发现IndexReader接口下面有两大类型的Reader实现，一个是基于AtomicReader实现的原子类型，另一个是基于CompositeReader实现的复合类型，那么这两个直接子类，究竟有什么区别和联系呢？
实际上，它们之间的联系我们从上图中，就能清晰的看出来，它们都实现了相同的父接口，所以说从某种程度上来讲，它们之间是可以转换的，事实上也的确如此。在AtomicReader的子类里面提供了一个SlowCompositeReaderWrapper的包装类，来把一个CompositeReader的子类，模拟成一个原子Reader。
那么，CompositeReader和AtomicReader它们之间究竟有什么区别呢？ AtomicReader相对来说更细化，提供了具体层面访问索引文件内容的实现，而CompositeReader则在宏观的方向上，提供了读取索引文件，以及汇合多个索引的功能。
可以打这么一个比方，CompositeReader是一个类似半径为10的圆，而AtomicReader则是一个类似半径为5的圆，而我们的索引存储的数据就在圆心上，当然我们的这个假设是基于立体3维的圆，那么现在，我想要获取圆心上的数据，无论你从哪个方向，哪个位置切入，都必须的先经过大圆的范围，然后经过小圆的范围，最终我们才能获取圆心上存储的数据。所以我们说CompositeReader在宏观上起到了读取索引文件（可能是多份索引的读取（可以是单线程读，也可以是并行读）及合并）的作用，而AtomicReader则在微观的角度上，起到了读取索引文件内容的作用，通过两者组合，我们就可以完美的读取索引文件。
在IndexReader的旗下，又旗帜鲜明的分成了两个基类，这两个基类的下面的各个子类之间，既有区别也有联系，只有相互协作，才能高效的完成读取实现，当然这些lucene都给我们已经封装好了，我们可以在我们任何需要的时候，来调用他们来完成特定的工作，除此之外，我们也可以来自定义我们自己用的特定的reader，来完成某些不常见的功能，因为lucene给我们提供了一个非常方便，强大，而且易扩展的接口，由此可以看出lucene的设计架构充分利用接口和一些抽象类的组合，来使整体设计变更灵活和易扩展。
今天散仙就先分享到这里了，本篇文章的目的很简单，就是让大家在宏观上对IndexReader有一个整体认识和把握，方便我们以后在开发过程中能够做到有选择的，心里有底的，清晰的使用。
转载请务必注明，原创地址，谢谢配合!
http://qindongliang1922.iteye.com/blog/1995329
下一篇： MySql数据类型