lucene3.6 mysql_Lucene 3.5和Solr 3.5:大幅降低内存用量、SearcherManager和深度分页支持...

Lucene项目管理委员会宣布Apache Lucene 3.5.0和Apache Solr 3.5.0已经可以使用。Lucene是一个高性能、支持全文搜索的文本搜索开发库。Solr是一个独立的搜索服务器,其核心使用了Lucene来做索引和搜索。

Lucene 3.5.0版本的主要变化包括:

降低内存消耗。现在建立词汇索引需要的内存比以前降低了3到5倍,实现这一点,是使用了更有效的内存数据结构来保存词汇。

深度分页支持。加入IndexSearcher.searchAfter方法,它在特定的ScoreDoc之后会返回结果。你可以将上一页的最后一个document传递给searchAfter方法,以得到下一页的结果。

SearcherManager。加入了org.apache.lucene.search.SearcherManager类, 简化了在多个搜索线程中对IndexSearcher的分享和重新开启。底层的IndexReader实例如果不再被引用,可以安全关闭,其中使用了 IndexReader的引用计数。还使用了获取方法来取得一个IndexSearcher,还有释放方法来关闭取得的IndexSearcher。

SearcherLifetimeManager。加入了org.apache.lucene.search.SearcherLifetimeManager类,提供跨越多个请求的索引的统一视图。它简化了服务多个请求的同一个IndexSearcher实例的使用,在分页或上下钻取搜索结果时,有更好的用户体验。

IndexWriter.optimize()弃用。IndexWriter.optimize方法不再使用,并被重新命名为forceMerge。这么做,是不再鼓励使用该方法,因此它的操作成本很高,而且只能在静态索引上使用。

IndexReader.reopen()重命名。IndexWriter.reopen方法替代为openIfChanged。如果索引没有变化,IndexReader.openIfChanged会返回null。一般来说,相对开启新的IndexReader,该方法成本更低。

NGramPhraseQuery。org.apache.lucene.search.NGramPhraseQuery是PhraseQuery类,针对n-gram模型的查询做了优化。当使用n-gram分析时,可以加速查询速度30%-50%。

可以访问Lucene 3.5发布说明来了解完整的变更列表。

Solr 3.5.0的主要变化有:

Lucene 3.5.0。来自Lucene 3.5.0的缺陷修复和改进,主要是保持词汇索引需要的内存数量大幅减少。

分布式结果分组。支持分布式搜索结果分组,也被称为field collapsing。该特性限制了每“组”展示的文档数目,作为一个字段的唯一值定义,现在支持分布式搜索。

语言检测。新的模块“langid”加入了在索引前检测文档语言的能力,以辅助正确决策。使用了Apache Tika的LanguageIdentifier 或Cybozu的语言检测程序库,作为UpdateRequestProcessor实现。

支持数字类型的sortMissingFirst和sortMissingLast。包括Trie在内的数字类型和日期类型现在支持sortMissingFirst和sortMissingLast。

HunspellStemmerFilter。添加对Lucene的 HunspellStemmerFilter支持,这样就可以支持90种语言的stemming词根缩减功能。Hunspell本来是一个高级的拼写检查 库,它因为用于OpenOffice套件而出名,现在在Solr中使用,提供stemming词根缩减。

hl.q参数。加入了可选的hl.q参数,如果给定值,在Highlighter(HighlightComponent类)中会重写q参数。

可以访问Solr 3.5发布说明来了解完整的变更列表。

Yonik Seeley是Apache Solr的创始人,同时也是Lucid Imagination的首席开源架构师和联合创始人,他回答了InfoQ针对本次Lucene和Solr发布的一些问题。

InfoQ:对于大部分Lucene和Solr的用户来说,这次发布能够让他们马上用起来的有哪些功能?

Yonik Seeley:Lucene和Solr的用户可以受益于词汇索引大幅减少的内存用量、改进后的向量强调(vector highlighting)等等。Solr还加入了对分布式分组的支持,提供针对缺少首值或末值的数字字段排序的能力。Lucene还加入了对深度分页的优化。

InfoQ:您是否推荐开发人员使用默认的新SearcherManager?

Yonik Seeley:对于刚刚开发基于Lucene的项目的人来说,用新的Lucene SearcherManager是个好的开始,但是没必要把正常使用的自定义搜索的manager代码迁移过来。对于Solr的用户,searcher的管理从一开始就是内部实现的细节了。

InfoQ:Lucene和Solr 3.6有什么计划?

Yonik Seeley:在开源软件中很难说,因为没有正式的路线图。大部分的重大突破都发生在主干代码中,发布时自然就是4.0了。Lucene已经完全更新了对索引机制,支持codec。Solr正在逐步转向使用NoSQL data store,使用更先进的分布式索引功能。

InfoQ:我们什么时候才能看到带有NRT功能的Solr正式版发布?

Yonik Seeley:LucidWorks是我们的Apache Solr的商业版本,基于主干代码的稳定版本(4.0-dev),具备NRT功能。至于这个功能何时移植回Solr 3.x,现在还不清楚。Lucene和Solr 4.0版本应该在2012年某个时候发布。

想对它们有所了解,您可以从Apache的镜像站点下载Lucene 3.5和Solr 3.5。Maven的用户要使用Lucene,其groupId为org.apache.lucene,artifactId模式为lucene-*,版本是3.5.0。您也可以订阅Lucene和Solr的邮件列表获取最新信息。

Lucene 的详细介绍:请点这里

Lucene 的下载地址:请点这里0b1331709591d260c1c78e86d0c51c18.png

lucene搜索分页过程中,可以有两种方式 一种是将搜索结果集直接放到session中,但是假如结果集非常大,同时又存在大并发访问的时候,很可能造成服务器的内存不足,而使服务器宕机 还有一种是每次都重新进行搜索,这样虽然避免了内存溢出的可能,但是,每次搜索都要进行一次IO操作,如果大并发访问的时候,你要保证你的硬盘的转速足够的快,还要保证你的cpu有足够高的频率 而我们可以将这两种方式结合下,每次查询都多缓存一部分的结果集,翻页的时候看看所查询的内容是不是在已经存在在缓存当中,如果已经存在了就直接拿出来,如果不存在,就进行查询后,从缓存中读出来. 比如:现在我们有一个搜索结果集 一个有100条数据,每页显示10条,就有10页数据. 安装第一种的思路就是,我直接把这100条数据缓存起来,每次翻页时从缓存种读取 而第二种思路就是,我直接从搜索到的结果集种显示前十条给第一页显示,第二页的时候,我在查询一次,给出10-20条数据给第二页显示,我每次翻页都要重新查询 第三种思路就变成了 我第一页仅需要10条数据,但是我一次读出来50条数据,把这50条数据放入到缓存当中,当我需要10--20之间的数据的时候,我的发现我的这些数据已经在我的缓存种存在了,我就直接存缓存中把数据读出来,少了一次查询,速度自然也提高了很多. 如果我访问第六页的数据,我就把我的缓存更新一次.这样连续翻页10次才进行两次IO操作 同时又保证了内存不容易被溢出.而具体缓存设置多少,要看你的服务器的能力和访问的人数来决定
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值