Google

Archives

Be care of RangeQuery in Lucene

Reminder, Lucene has many Query types

– TermQuery, BooleanQuery,

ConstantScoreQuery, MatchAllDocsQuery,

MultiPhraseQuery, FuzzyQuery,

WildcardQuery, RangeQuery, PrefixQuery,

PhraseQuery, Span*Query,

DisjunctionMaxQuery, etc.

There is a bunch of Query implements in Lucene, which makes lucene very powerful in search. However, you should be very care of using Query like RangeQuery, especially when the size of your collection is very large.

As you know that lucene will [...]

Trie-based approximate autocomplete implementation with support for ranks and synonyms

Thoughts on Lucene, Solr, Nutch and vertical search 
Trie-based approximate autocomplete implementation with support for ranks and synonyms

Posted by Kelvin on 01 Jul 2009 at 02:30 am | Tagged as: programming

The problem of auto-completing user queries is a well-explored one.

For example,
Type less, find more: fast autocompletion search with a succinct index
http://stevedaskam.wordpress.com/2009/06/07/putting-autocomplete-data-structure-to-the-test/
http://suggesttree.sourceforge.net/
http://sujitpal.blogspot.com/2007/02/three-autocomplete-implementations.html

However, there’s been little written [...]

Lucene 新子项目OpenRelevance起航

25 June 2009 – Apache Open Relevance Kickoff

也就是昨天,Apache 官方投票通过启动一个Lucene 子项目Open Relevance Project (ORP)。ORP主要目标是检索数据集、评价和查询,这样Lucene的开发者和用户就可以更容易地进行相关度评价测试。比较像TREC,NTCIR等这些评测,不过这个项目会更开放些。

更多信息可参考:

http://lucene.apache.org/openrelevance/

http://wiki.apache.org/lucene-java/OpenRelevance

这算是一个比较exciting NEWS,特别是像我比较喜欢Lucene,又想用Lucene搞点IR方面的研究的。

Incoming search terms for the article:lucene子项目 (1)openrelevance (1)TREC lucene (1)

lucene影响索引速度的因素-MergeFactor, MaxMergeDocs, RAMBufferSizeMB

版本:Java lucene2.4

在索引算法确定的情况下,最为影响Lucene索引速度有三个参数--IndexWriter中的 MergeFactor, MaxMergeDocs, RAMBufferSizeMB 。这些参数无非是控制内外存交换和索引合并频率,从而达到提高索引速度。当然这些参数的设置也得依照硬件条件灵活设置。

MaxMergeDocs

该参数决定写入内存索引文档个数,到达该数目后就把该内存索引写入硬盘,生成一个新的索引segment文件。
所以该参数也就是一个内存buffer,一般来说越大索引速度越快。
MaxBufferedDocs这个参数默认是disabled的,因为Lucene中还用另外一个参数(RAMBufferSizeMB)控制这个bufffer的索引文档个数。
其实MaxBufferedDocs和RAMBufferSizeMB这两个参数是可以一起使用的,一起使用时只要有一个触发条件满足就写入硬盘,生成一个新的索引segment文件。

RAMBufferSizeMB

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

MergeFactor

这个参数是用于子索引(Segment)合并的。
Lucene中索引总体上是这样进行,索引现写到内存,触发一定限制条件后写入硬盘,生成一个独立的子索引-lucene中叫Segment。一般来说这些子索引需要合并成一个索引,也就是optimize(),否则会影响检索速度,而且也可能导致open too many files。
MergeFactor 这个参数就是控制当硬盘中有多少个子索引segments,我们就需要现把这些索引合并冲一个稍微大些的索引了。
MergeFactor这个不能设置太大,特别是当MaxBufferedDocs比较小时(segment 越多),否则会导致open too many files错误,甚至导致虚拟机外面出错。

Note: Lucene 中默认索引合并机制并不是两两合并,好像是多个segment 合并成最终的一个大索引,所以MergeFactor越大耗费内存越多,索引速度也会快些,但我的感觉太大譬如300,最后合并的时候还是很满。Batch indexing 应 MergeFactor>10

Incoming search terms for the article:MergeFactor (19)lucene 两两 合并 索引 (16)lucene mergeFactor (12)ramBufferSizeMB (2)lucene maxmergeDoc (2)

Lucene的检索优化(一)

 
 

Sent to you by Jeffye via Google Reader:

 
 

Lucene的检索优化(一)

via 笨笨的小田园 by 笨笨 on 8/14/08

ucene支持内存索引:这样的搜索比基于文件的I/O有数量级的速度提升。
http://www.onjava.com/lpt/a/3273

而尽可能减少IndexSearcher的创建和对搜索结果的前台的缓存也是必要的。

Lucene面向全文检索的优化在于首次索引检索后,并不把所有的记录(Document)具体内容读取出来,而是只将所有结果中匹配度最高的头
100条结果(TopDocs)的ID放到结果集缓存中并返回,这里可以比较一下数据库检索:如果是一个10,000条的数据库检索结果集,数据库是一定
要把所有记录内容都取得以后再开始返回给应用结果集的。所以即使检索匹配总数很多,Lucene的结果集占用的内存空间也不会很多。对于一般的模糊检索应
用是用不到这么多的结果的,头100条已经可以满足90%以上的检索需求。

如果首批缓存结果数用完后还要读取更后面的结果时Searcher会再次检索并生成一个上次的搜索缓存数大1倍的缓存,并再重新向后抓取。所以如果
构造一个Searcher去查1-120条结果,Searcher其实是进行了2次搜索过程:头100条取完后,缓存结果用完,Searcher重新检索
再构造一个200条的结果缓存,依此类推,400条缓存,800条缓存。由于每次Searcher对象消失后,这些缓存也访问那不到了,你有可能想将结果
记录缓存下来,缓存数尽量保证在100以下以充分利用首次的结果缓存,不让Lucene浪费多次检索,而且可以分级进行结果缓存。

Lucene的另外一个特点是在收集结果的过程中将匹配度低的结果自动过滤掉了。这也是和数据库应用需要将搜索的结果全部返回不同之处。

 
 

Things you can do from here:

Subscribe to 笨笨的小田园 using Google Reader
Get started using Google Reader to easily keep up with all your favorite sites

 
 
Incoming search terms for the article:lucene查询优化 (7)lucene 优化 (6)lucene优化 (6)lucene 查询优化 (4)lucene 缓存 (4)