Lucene.Net 2.3.1开发介绍 —— 三、索引(七)

原文:Lucene.Net 2.3.1开发介绍 —— 三、索引(七)

5、IndexWriter

索引这部分最后讲的是IndexWriter。如果说前面提到的都是数据的结构,那么IndexWriter就是业务的封装。无论述Document,Field还是看不见的Segment,Term都是对数据存储逻辑的抽象,IndexWriter包装了操作的过程。

当然,这里不会讨论IndexWriter的每个细节,这里主要介绍IndexWriter的常用法和实际使用中遇到的部署问题。

5.1 IndexWriter的常用方法

IndexWriter的用法很简单,前文有例子。在《接触Lucene.Net 》一文中代码2.1.1就是最简单的用法。可以看到IndexWriter的构造函数很重要,AddDocument方法也很重要,有这两个方法,就可以建立索引了。其它的方法都是对建立索引的过程或者结果进行了优化,或者是提供了一些索引中或者索引后的数据。比如,常用的Optimize方法,就是对索引进行优化,使得搜索能够效率更高。还有一些常用的方法(按字母排序):

(1)、AddIndexes方法是合并不同部分索引的,这个方法很有用,比如,用5个线程在5个目录下建立索引,然后用这个方法把5个索引合并为一个,这样就能提高索引的效率;
(2)、Close方法是最后使用的方法,除了能够去除对文件的锁定外,还能起到Flush方法的作用。这个方法非常重要,在IndexWriter实例建立后,无论出现什么样的问题,哪怕程序崩溃,都一定要显式调用该方法。要不然索引会处于锁定状态,无法解除;
(3)、DeleteDocuments是用来删除索引的,这里只能指定Term删除,使用价值不是太高;

(4)、Flush方法是把缓冲数据写入的一个方法,在不想关闭索引但是要清空缓冲区的时候使用;

(5)、Optimize方法是优化索引的方法,如果索引数据很大,则调用这个方法会耗费很长时间。另外就是,如果索引文件这个时候被读取,并不能达到删除废弃文件的目的。

(6)、SetMaxBufferedDocs方法是规定缓冲区能够缓冲Document的个数,因为写硬盘要比写内存慢很多,这个值设置得越大,暂时存储到内存的Document就会越多;

(7)、SetMaxFieldLength方法设置Field的最大长度;

(8)、UpdateDocument用来更新索引,但是实际上并不是真正的更新,而是先删除,再添加,如果不进行优化,那么至少会增加两个文件,一个记录了增加的一个记录了删除的。

5.2 索引的部署

索引的部署根据索引的大小而趋向复杂,我认为至少是平方增长。复杂度增长的原因在于,索引大小的增长,将会引入更多需要考虑的因素。比如,索引的重建,索引优化时间,多索引部署等,而分布式部署基本上是目前最复杂的部署方案。

一般来说,应该一个索引存储,只应该由一个IndexWriter来控制。一个存储不应该超过2G,即使是2G,每次索引更新都需要10分钟左右来优化索引。至于如何分配索引,要根据实际情况来决定,而且要考虑诸如程序崩溃等情况。

在Java版的搜索引擎解决方案中有很多可以借鉴的地方,比如,对于数据索引,Compass的索引方式可以参考;对于抓取式的搜索引擎,Nutch可以参考;分布式解决方案可以参考Hadoop。如何实现像Compass一样,添加、删除、更新都能及时反映到索引当中,站内搜索引擎一般都会面临这样的问题。Lucene.Net已经为我们提供了实现的方法,至于实现的逻辑需要你去思考。

6、索引小节

本篇文章是索引部分的完结篇。从第一篇到这里第七篇,主要介绍了两个东西,一个是Lucene.Net的逻辑存储,另外一个就是如何操作逻辑存储。在逻辑存储上讲得比较详细,特别是关于权重部分,而操作则只简单提一下。因为,逻辑存储有助于理解Lucene.Net索引的流程,而操作则只是相当于CPU的指令,业务逻辑需要自己去实现。相信看了以上七篇文章,有助于对Lucene.Net索引的理解,当然,这里只讲了表面上的东西,更加深入地理解Lucene需要从更加底层的Directory入手。索引部分就暂时写到这里了,后面将进入搜索问题的探讨。

上一篇:机器人操作系统 除了Android还有一个ROS(转)


下一篇:Lucene.Net 2.3.1开发介绍 —— 三、索引(四)