浏览 2009 次
锁定老帖子 主题:Lucene4.3进阶开发之入乡随俗(三)
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2013-12-25
散仙在前2篇文章中,简单分析了Directory家族的功能以及作用,同时也对Directory家族中我们比较常用的几个子类,做了剖析和归纳,那么本篇文章,散仙就来介绍下与Directory家族经常进行交互的另一大家族IndexReader家族,另外需要说明的是,散仙现在介绍的一些内容都是基于最新版Lucene4.6.0的版本,不过标题名还是Lucene4.3的,为了统一命名,散仙在这里就不改了,因为Lucene最近的更新发布,实在是太活跃了,还是哪一句话,越活跃的东西,前途越光明,就像最近一年来Hadoop的兴起和迅猛发展,lucene也是如此。
好了,开篇又扯淡了几句,下面我们开始进入正题,在这之前,我们先来看下IndexReader家族的家谱图。 下面我们来回忆下,我们在使用lucene的过程中,经常使用到的一行代码: <pre name="code" class="java">directory=FSDirectory.open(new File(indexReadPath));//打开索引目录 IndexReader reader=DirectoryReader.open(directory);//获取数据句柄</pre> 看过如上代码,我们是不是有种很熟悉的味道,然后我们在对比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有一个整体认识和把握,方便我们以后在开发过程中能够做到有选择的,心底有底的,清晰的使用。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |