注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

小葫芦君(汉斯的博客)

博客迁移到新博客:https://blog.ssxingshou.com

 
 
 

日志

 
 
关于我

小小葫芦商城,为您提供高品质的商品,一流的产品,一流的包装服务,一流的物流服务,放心购买

网易考拉推荐

如何提高Lucene的搜索速度  

2013-01-27 10:11:50|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

译自:http://wiki.apache.org/lucene-java/ImproveSearchingSpeed

这里讨论了提高基于Lucene的应用程序搜索速度的几种方法。

首先确定你需要加快搜索速度。这里的很多方法很容易尝试,但是有些会增加你程序的复杂性。所以请首先确定搜索速度确实太慢,而且速度问题确实是Lucene导致的。

  • 确保你使用的是最新版本的Lucene。
  • 使用本地文件系统。
    远程文件系统搜索的速度总是会慢一些。如果你的索引必须放在远程文件系统之上,那么可以考虑把远程文件系统用“只读方式”加载(mount)。某些时候这会改善性能。
  • 使用更快的硬件,尤其是更快的IO系统。
    固态硬盘(solid-state disk,SSD)非常适合Lucene的搜索。SSD的寻道时间大概是传统磁盘式硬盘的100倍,也就是说常见的寻道时间造成的开销几乎可以忽略掉了。 也就是说装有SSD的机器无需太多的内存作为文件缓存,搜索器在允许反应之前需要的预热(warm-up)时间更短。
  • 调节操作系统。
    Linux可以调节的一个典型的参数是swappiness(参看http://kerneltrap.org/node/3000, 译注:可理解为交换系统,调节物理内存和交换分区使用倾向的),这个参数控制了操作系统把内存交换出到IO缓存的倾向性。这个参数在大多数Linux发行 版中的默认设置都是一个很大的数(也就是说,倾向于交换分区),这容易造成严重的搜索延迟,特别是在查询频率不高的情况下,搜索一个大的索引时。请尝试把 swappiness调低,甚至关闭(把它设置为0)。Windows也有一个选框,在我的电脑->属性->高级->性能设置 ->内存使用,允许你选择倾向于应用程序还是系统缓存,好像也是起这个作用的。
  • 使用readOnly=true选项打开IndexReader。
    在多线程共享同一个reader的时候这将起巨大的作用,因为这样会去掉处理线程冲突的代码。
  • 在非Windows平台,使用NIOFSDirectory取代FSDirectory。
    这样访问这些文件的时候,也会去掉处理线程冲突的代码。不幸的是,由于Sun JRE Windows版本长期存在的bug(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6265734),NIOFSDirectory在Windows下表现很差。
  • 使用IndexSearcher的同一个实例。
    在程序的查询和线程之间,使用单一的一个IndexSearcher的实例。
  • 测量性能的时候,忽视第一条查询。
    对搜索器的第一次查询,要付出初始化缓存的代价(特别是按照字段排序的时候),会干扰你的结论(假设你重用搜索器进行多次查存)。另外一方面,如果你一遍 遍的重复同样的查询,结论也会被扭曲,因为操作系统会使用它的缓存加速IO操作。Linux(核心2.6.16或者更新版本)下,你可以用命令 sync ; echo 3 > /proc/sys/vm/drop_caches 来清空缓存。参见http://linux-mm.org/Drop_Caches
  • 仅在需要的时候重新打开IndexSearcher
    只有在需要让最新提交的更新出现在搜索中的时候,才应该重新打开IndexSearcher。注意,重新打开搜索器有它的开销(在大的索引和排序打开的情况下可以被察觉到的),必须将这一开销最小化。可以考虑在面对第一个查询之前,使用预热技术对缓存进行预热。
  • 搜索前对你的索引进行优化(optimize)
    优化(optimize)过的索引只有一个段,这样通常比多个段速度快得多,尤其是对于大的索引。如果你的程序不经常更新索引,那么最好是,先构建索引, 然后优化,使用优化过的索引进行搜索。如果你的索引更新频率很高,而且更新后就要刷新搜索器的话,那么优化对你的开销就太大了,你可以采用降低合并因子的 方法。
  • 降低合并因子(mergeFactor)
    小的合并因子意味着更少的段和更快的搜索。然而,这将降低索引的速度,所以,你应该测试这个值,直到找到对于你的程序满足平衡的值。
  • 限制保存字段和词向量的使用。
    从索引中获取这些信息开销太大。一般来说,你应该只获取用户看前可见的“页”内的条目的这些信息,而不是整个结果集的。针对每个获取的文档,Lucene必须寻道到不同文件的不同位置。尝试首先用docID排序你要获取的文档(译注:有可能提高寻道效率)。
  • 在你获取一个文档时,使用FieldSelector仔细的选择要载入哪些字段,以及如何载入他们。
  • 不要枚举比所需命中结果更多的结果。
    枚举所有的命中很慢,有两个原因。首先,返回Hits对象的search()方法在你需要超过100个命中的时候,需要内部重新执行搜索。解决方法:用带 有HitCollector的search方法代替。其次,命中通常遍布磁盘的每个角落,访问全部需要大量的I/O活动。这很难避免,除非索引小到可以直 接放到内存里。如果你不需要完整的文档,而只需要一个(小的)字段,那么你可以用FieldCache类来缓存它,这样就可以告诉访问它了。
  • 使用模糊查询(fuzzy query)的时候设置最小的前缀长度。
    模糊查询执行耗费CPU的字符串比较──要避免将用户输入的词和所有的索引的词项进行比较,应该只比较前“N”个字符相同的词项。前缀长度是QueryParser和FuzzyQuery都有的参数,默认为0,所有的词项都要比较。
  • 考虑使用过滤器(filter)。
    把结果限定在索引的一部分时,使用缓存的位域过滤器比使用查询条件高效得多。尤其是在限制条件包含了一个大索引的大量文档时。过滤器通常用于限定一个分类下的结果,但是可以在很多中情况下替代任何查询条件。查询和过滤之间的一个区别在于,查询影响结果评分,过滤不影响。
  • 找到瓶颈。
    复杂的查询分析或者对结果过度处理,是隐藏的搜索瓶颈的例子。使用VisualVM这样的工具profile程序可以帮助定位这些问题。
  评论这张
 
阅读(1038)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017