您的位置:首页 > 理论基础 > 计算机网络

【直播】Lucene学习进阶--总结1[来自网络]

2011-12-03 23:45 316 查看

 1、正确关闭indexWriter实例?关闭过程中发生问题如何处理?

try {
writer.close();
} finally {
if (IndexWriter.isLocked(directory)) {
IndexWriter.unlock(directory);
}
}

2、IndexWriter有关的3个参数

1.MAXBufferedDocs

MaxBufferedDocs这个参数默认是disabled的,因为Lucene中还用另外一个参数(RAMBufferSizeMB)控制这个bufffer的索引文档个数。
其实MaxBufferedDocs和RAMBufferSizeMB这两个参数是可以一起使用的,一起使用时只要有一个触发条件满足就写入硬盘,生成一个新的索引segment文件。

2.RAMBufferSize

控制用于buffer索引文档的内存上限,如果buffer的索引文档个数到达该上限就写入硬盘。当然,一般来说也只越大索引速度越快。当我们对文档大小不太确定时,这个参数就相当有用,不至于outofmemory error.

3.MegerFactor
SetMergeFactor是控制segment合并频率的,其决定了一个索引块中包括多少个文档,当硬盘上的索引块达到多少时,将它们合并成一个较大的索引块。当MergeFactor值较大时,生成索引的速度较快。MergeFactor的默认值是10,建议在建立索引前将其设置的大一些。
 3、注意:
1.不要随意设置MaxbufferedDocs。
MaxBufferedDocs和RAMBufferSize共同控制内存中文档的容量。
如果对MaxBufferedDocs进行设置要比较小心了,因为它本身是disabled,如果设置不合理将导致大规模的重建索引非常慢。
例如:

dir = SimpleFSDirectory.open(new File("d:/20101015index"));
writer = new IndexWriter(dir, new StandardAnalyzer(Version.LUCENE_30), true, MaxFieldLength.UNLIMITED);
writer.setUseCompoundFile(true);
writer.setMaxBufferedDocs(100);
writer.setMergeFactor(10);
//add document
//注意点2:filed实例在多次添加的时候可以重用,节约构造field实例的时间。
Field f1 = new Field("f1", "", Store.YES, Index.ANALYZED) ;
Field f2 = new Field("f2", "", Store.YES, Index.ANALYZED) ;
for (int i = 0; i < 1000000; i++) {
Document doc = new Document();
f1.setValue("f1 hello doc" + i);
doc.add(f1);
f2.setValue("f2 world doc" + i);
doc.add(f2);
writer.addDocument(doc);
}
writer.optimize();

上述代码中对MaxBufferedDocs进行设置:

writer.setMaxBufferedDocs(100);
那么现在对内存中文档的容量有两个控制量:
1.文档数量达到100就写回磁盘;
2.文档总容量达到16m就写回磁盘;
因为上面一个文档的大小很小,100个文档的容量肯定不会达到16m,所以第一个控制量起到主要的作用。
在没有设置MaxBufferedDocs之前就只有RAMBufferSize(16m)控制内存中文档的数量,
较之这两种情况,明显是没有设置MaxbufferedDocs更好的利用了内存,因此建立索引更快速。
实验证明:
不设置MaxbufferedDocs,耗时20s左右;
设置MaxbufferedDocs为100,耗时280000s左右。 = =! 差别太大了,所以一定要小心!!!

2.不要太迷信MegerFactor比较大会加快重建索引的速度。
通过实验,在上述代码中奖MegerFactor设置成10比100要快2s。

“一家之言”——
对于一般的系统(数据量在千万级,重建索引暂不考虑并发压力),在重建索引时不要太纠结这些参数的设置,
只要不犯太严重的问题(例如像上面一样将MaxbufferedDocs设置得过小,还不如不设置),效率出入都不会太大。

3.是否有必要将数据先放到RAM中,再和磁盘的索引进行合并?
我认为在重建索引的环节没有必要。因为在使用FSDirectory建立索引的时候不就可以控制内存的使用么!?(MaxbufferedDocs和RAMBufferSize)
而RAMDiretory应该重点使用在实时索引上面。
(= =! 我指的重建索引是什么意思?"对大量的数据一次性建立成磁盘索引!")
这里也做了一个测试,是先将文档写入内存,然后合并到磁盘。
主要代码如下所示:

 dir = new RAMDirectory();

dirFS = SimpleFSDirectory.open(new File("d:/20101015index"));
writer = new IndexWriter(dir, new StandardAnalyzer(Version.LUCENE_30), MaxFieldLength.UNLIMITED);
writerFS = new IndexWriter(dirFS, new StandardAnalyzer(Version.LUCENE_30), true, MaxFieldLength.UNLIMITED);
//
Field f1 = new Field("f1", "", Store.YES, Index.ANALYZED);
Field f2 = new Field("f2", "", Store.YES, Index.ANALYZED);
for (int i = 0; i < 1000000; i++) {
Document doc = new Document();
f1.setValue("f1 hello doc" + i);
doc.add(f1);
f2.setValue("f2 world doc" + i);
doc.add(f2);
writer.addDocument(doc);
}
//            writer.commit();
writerFS.addIndexes(writer.getReader());

 刚开始学lucene的时候,总热衷提高效率,什么参数的设置啊、RAM的使用啊等等,殊不知重建索引是一个初始化阶段(服务于后期的检索),

就算有优化的必要,但绝不是当前必要解决的“主要矛盾”。

应该将重点放到:

1.实时索引;

2.分布式构建检索框架(如果系统规模有必要的);

3.怎么在程序质量上利用好内存,不至于运行时到处时 内存溢出 。

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: