写文档时, 偶然发现很久以前的东西,给大家分享一下. 现在lucene已经过了这个版本, 已经有OpenBitSet这种好东西了.~
1. lucene2.3.2的变更
2. 疱丁解牛分词器分析
3. 几种分词器精度和速度的比较
<!----><!----> <!---->
Author: Jeremy Chow([email protected])
Last Modified: Aug 1st, 2008
<!---->1. <!---->IndexWriter最大化地提高了现有的索引速度。第一,IndexWriter现在由内存的使用情况来决定刷新索引至磁盘,而不是之前用IndexWriter.setMaxBufferedDocs规定缓存的Docuement数量来决定刷新行为。第二,ConcurrentMergeScheduler使用后方(backgroud)线程(调用IndexWriter.setMergeScheduler (new SerialMergeScheduler())保持向下兼容) 来进行合并操作,由此得到的好处是合并行为不会阻塞IndexWriter.addDocument操作。第三,现在对segment的合并操作是依据每个segment大小,而不再是依据它们所包含Document的数量。
<!---->2. <!---->SortField.AUTO对long型起作用。在之前的lucene版本中,为排序自动检测Field类型时,数字首先被解释成int,如果解释失败,则认为是float。现在则先检测是否int,然后是否long,最后是float。
<!---->1. <!---->新加了IndexWriter.setRAMBufferSizeMB(...),IndexWriter当缓存的Documents容量大于指定内存大小时进行刷新。同时,Token也添加了新的API,使用户使用char[]结合偏移量与长度来表示token (避免为每个Token调用一次new String ())。
<!---->1. <!---->新加了IndexReader.reopen() 方法用来重新打开已经存在的IndexReader。
<!---->2. <!---->新加了IndexWriter.optimize(int maxNumSegments) 用来局部优化值小于maxNumSegments 的片段
<!---->3. <!---->新加了IndexWriter.optimize(int maxNumSegments) 局部优化索引
<!---->4. <!---->新加了IndexCommit.isOptimized()。
<!---->5. <!---->新加了TokenFilter.reset()。
1. CachingTokenFilter 现在使用一个迭代器来访问缓存在LinkedList内的Tokens。显著地提升了性能,特别是在Tokens数目比较大的情况。
2. 从实质上优化了IndexWriter怎么使用RAM来缓存Documents,使索引速度加快到之前的2~8倍。现在使用了一个简单的共享散列表记录在内存中的Postings。一个Term对应一个posting。这个表直接写入到一个segment中。
3. 消除了偶尔会发生在复合文件(compound files)上的缓存到缓存拷贝(buffer to buffer copy)。
4. 去掉了Document中的同步机制,实际就是把存储Fields的Vector改成了ArrayList。
5. StandardTokenizer (StandardAnalyzer)使用JFlex代替JavaCC生成Tokenizer,使其速度是以前的6倍。
6. 使用bulk-coping技术拷贝原始字节,加速邻接的未删除文档的合并。
7.加速了 ISOLatin1AccentFilter 。
IndexReader .reopen()
如果IndexReader实例调用此方法时,索引有变化,则生成一个新的IndexReader实例。
打开索引是非常昂贵的操作。此方法可以用来刷新已经存在的IndexReader,减少代价。此方法尝试只加载已经变化或新建立的片段(segement)。
如果索引自从打开后没有变化,则返回原来的IndexReader对象,否则会返回一个新的IndexReader对象。此时旧的IndexReader对象没有 关闭,只是不可用。
注意: 新打开的IndexReader对象可能会与旧的对象共享资源,据此,千万不要调用这些对象对索引的任何修改操作(例如:deleteDocument(int) , setNorm(int, String, byte) ),除非旧IndexReader对象已经关闭。否则,其行为将是不可确定的。
你可以通过比较返回的IndexReader与原来的IndexReader来判断其是否真的重新打开了:
IndexReader reader = ...
...
IndexReader new = r.reopen();
if (new != reader) {
... // reader was reopened
reader.close();
}
reader = new;
...
以DocumentsWriter代替了之前的DocumentWriter。前者接受多个文档(Documents)的添加,并且直接把它们写入到一个单一的片段(segment)中。它比lucene2.2.0中用DocumentWriter为每个文档建立一个片段,然后将这些片段合并的方法更高效。
当加一篇文档时,它所存储的属性(Field)和词条向量(Term Vector)立即被写入到磁盘目录(假设不用RAM)。词频freq/prox 等词条信息(Posting),以词条为键值加入到Posting散列中。Posting散列表的每项维护着一个词频和prox组成的独立字节流。它包含多个文档的Posting数据。如果启用了向量,则为每个文档的每条词条都分配一个Posting向量(Posting Vector)。向量的每个元素记录词条的偏移量、位置等信息。
当Posting散列已满(假设使用RAM)或者加入到RAM的文档数目足够大(在此,我们用文档数目,而不是RAM使用量来刷新索引)时,我们会建立一个真实的片段,把它刷新到磁盘,然后重置Posting散列。
加入文档时,我们首先由属性(Field)名来组织文档所有的属性,并为每个属性记录其Posting散列。处理完每个属性后,我们刷新它的词条向量。当到整个片段的时候,我们首先通过名称将属性(fields)排序,然后依次排序每个属性的Postings。
线程:
多条线程可以同时调用addDocument方法。DocumentsWriter内部有一个getThreadState的同步调用,它为当前线程式分配一个ThreadState对象。无论何时,同一线程将会得到同一ThreadState。因此,如果各线程为各自不同的内容建立索引,则可以更有效地使用RAM。之后,processDocument会在那个ThreadState之上被调用,它不用作同步(很多消耗在这一步)。这是lucene2.3.0最重要的改进。 最后,同步调用finishDocument刷新变化至磁盘目录。
每个ThreadState实例都有属于其自身的Postng散列。当我们使用过多RAM时,会通过合并多个线程状态(ThreadSate)中相同词条的Posting表中的文档ID(docIDs),刷新所有线程的Posting散列至一个片段中。
当IndexWriter调用刷新操作(flush),且autoCommit=false时,会执行刷新。此时,我们强制所有线程空闲,且确定它们都空闲后才刷新。这意味着,你可以由一个给定的线程调用刷新操作。
CPU: Intel Dual CPU 2.00GHz,
内存: 1G DDR400
文本材料大小 : : 43.9 MB
文件数目 : 19997 个
分析器 : lucene 标准 StandardAnalyzer
Lucene 版本: 2.2.0
生成索引大小 : : 16,901,638 字节
耗时:
158094 微秒
110437 微秒
106328 微秒
Lucene 版本: 2.3.2
生成索引大小 : 16,177,772 字节
默认 16M 缓存耗时 :
15407 微秒
15500 微秒
设置 64M 缓存耗时 :
13578 微秒
13984 微秒
13359 微秒
15500 微秒
可以看出 2.3 比 2.2 建索引的速度要快 5~10 倍。 (不过现在看来是因为StandardAnalyzer变快了. )