`
cfan_haifeng
  • 浏览: 121937 次
  • 性别: Icon_minigender_1
  • 来自: 郑州
社区版块
存档分类
最新评论

lucene-wiki翻译:如何提高索引速度-4

阅读更多

 


11.当IndexWriter处于open状态时,请将autoCommit设置为false 

原文 写道
Use autoCommit=false when you open your IndexWriter
In Lucene 2.3 there are substantial optimizations for Documents that use stored fields and term vectors, to save merging of these very large index files. You should see the best gains by using autoCommit=false for a single long-running session of IndexWriter. Note however that searchers will not see any of the changes flushed by thisIndexWriter until it is closed; if that is important you should stick with autoCommit=true instead or periodically close and re-open the writer.

      Lucene 2.3 为合并巨大的索引文件,对于储存fields 和term vectors的Documents给与大量的优化措施。你应该发现在长期运行IndexWriter的情况下,将autoCommit设置为false会取得最好的效率。注意,这时候的搜索将看不到任何改变,直到IndexWriter关闭。如果你需要添加的索引可以立刻被搜索到,你可以把autoCommit设置为false,或者周期性的打开、关闭IndexWriter

 

       再看人家的翻译:

 

在Lucene 2.3中对拥有存储字段和Term向量的文档进行了大量的优化,以节省大索引合并的时间。你可以将单一复用的IndexWriter实例的autoCommit设置为false来见证这些优化带来的好处。注意这样做将导致searcher在IndexWriter关闭之前不会看到任何索引的更新。如果你认为这个对你很重要,你可以继续将autoCommit设置为true,或者周期性的打开和关闭你的writer。

 

 

12. 原文 写道

 写道
Instead of indexing many small text fields, aggregate the text into a single "contents" field and index only that (you can still store the other fields).
  

   你可以将许多小的文本fields,聚合成一个文本并放到,放到一个"contents" field中。

 

  再看人家的翻译:

 

如果你要索引很多小文本字段,如果没有特别需求,建议你将这些小文本字段合并为一个大的contents字段,然后只索引contents。(当然你也可以继续存储那些字段)

 

   这个要看需求吧,呵呵

 

 

13. 适当增大mergeFactor

 

原文 写道

Increase mergeFactor, but not too much.

Larger mergeFactors defers merging of segments until later, thus speeding up indexing because merging is a large part of indexing. However, this will slow down searching, and, you will run out of file descriptors if you make it too large. Values that are too large may even slow down indexing since merging more segments at once means much more seeking for the hard drives.

 

       合并因子越大意味着合格合并segments 越晚,这样将会提高索引的速度,因为合并在建立索引的时间中占据了很大一部分然而这种方式也将会见面搜索速度,同时如果你的索引很大的时候,你还很有可能用光你的文件句柄(为什么?????合并因子太大也会适得其反的使索引变慢,因为这意味一次将会合并更多的segments ,从而导致对硬盘的更多扫描。

 

      其他翻译:

 

大的合并因子将延迟segment的合并时间,这样做可以提高索引速度,因为合并是索引很耗时的一个部分。但是,这样做将降低你的搜索速度。同时,你有可能会用光你的文件句柄如果你把合并因子设置的太大。值太大了设置可能降低索引速度,因为这意味着将同时合并更多的segment,将大大的增加硬盘的负担。

 

 

      MegerFactor(合并因子)是控制segment合并频率的,其决定了一个索引块中包括多少个文档,当硬盘上的索引块达到多少时,将它们合并成一个较大的索引块。当MergeFactor值较大时,生成索引的速度较快。MergeFactor的默认值是10,建议在建立索引前将其设置的大一些。

 

 

14. 关闭所有你不使用的功能 

 

原文 写道 
Turn off any features(这里翻译成“功能比较好) you are not in fact(实际,晕看成face了) using. If you are storing fields but not using them at query time, don't store them. Likewise for term vectors. If you are indexing many fields, turning off norms for those fields may help performance.
     关闭所有你不使用的功能 。如果你现在存储的fields在搜索时并不会使用他们,那么请不要存储他们。term向量也一样。如果你索引了很多fields,关闭这些 fields 的norms 可以提高性能。

 

   其他翻译:

 

关闭所有你实际上没有使用的功能 。如果你存储了字段,但是在查询时根本没有用到它们,那么别存储它们。同样Term向量也是如此。如果你索引很多的字段,关闭这些字段的不必要的特性将对索引速度提升产生很大的帮助。

   

15. 用更快的分析器analyzer

 

    原文 写道

 

Use a faster analyzer.
Sometimes analysis of a document takes alot of time. For example, StandardAnalyzer is quite time consuming(相当费时), especially in Lucene version <= 2.2. If you can get by with a simpler analyzer, then try it
   

   有时,分析一个文档将会花费大量的时间。例如,标准分析器StandardAnalyzer 就相当耗时,尤其是在小于Lucene 2.2的版本下,如果你有一个更快的分析器,那么用他吧(前提是符合你要求,呵呵)。

 

 

 

 

16. 加快文档构建(Speed up document construction 

原文 写道
Speed up document construction. Often the process of retrieving a document from somewhere external (database, filesystem, crawled from a Web site, etc.) is very time consuming.
  加快文档构建。从数据库、文件系统、爬虫……中索引文档都是非常耗时的。

 

 

17. 在你真的需要之前不要随意的优化optimize索引(只有在需要更快的搜索速度的时候)——(Don't optimize... ever.

 

 

18. 多个线程同时使用一个IndexWriter(Use multiple threads with one IndexWriter

 

 原文 写道

Use multiple threads with one IndexWriter. Modern hardware is highly concurrent (multi-core CPUs, multi-channel memory architectures, native command queuing in hard drives, etc.) so using more than one thread to add documents can give good gains overall. Even on older machines there is often still concurrency to be gained between IO and CPU. Test the number of threads to find the best performance point.
  

     多个线程同时使用一个IndexWriter。如今的硬件是高并发的(多核cpu,多通道内存架构……),所以使用多线程add documents 话效果将会更好。即使在较老的机器上使用多线程也将会在IO和CPU上取得较好的效果。在实际环境中,你要通过实验来确定线程个数,……

 

 

 

19.先分别建立几个索引文件,最后在合并索引

 

 原文 写道

 

Index into separate indices(index的复数) then merge. If you have a very large amount of content to index then you can break your content into N "silos"(筒仓), index each silo on a separate machine,then use the writer.addIndexesNoOptimize to merge them all into one final index.
 
   先分别建立几个索引文件,最后在合并索引。如果你有打了的内容需要索引,你可以首先将这些内容分成“ 筒仓 ”,然后分别有单独的机器(有这必要,什么情况下有这必要?去对这些 筒仓 建立索引,最后 writer.addIndexesNoOptimize调用合并这些索引。记得有个cms项目的索引就是这么搞的,但可惜没具体看效果,半死不活,非重点,唉


20运行Java分析器(Run a Java profiler.)

 

 原文 写道

Run a Java profiler.
If all else fails, profile your application to figure out where the time is going. I've had success with a very simple profiler called JMP. There are many others. Often you will be pleasantly surprised to find some silly, unexpected method is taking far too much time.

 

    如果以上所有方法都失败了,你可以尝试分析一下你的应用,找出来哪里最花费时间。这里给你推荐个即成功又简单的分析器 JMP当然也有很多其他的分析器。在分析之后,你通常会惊喜的发现一些可笑、……的方法花费了远超预料的时间。

 

    一点点的翻译,不知不觉这一小节文章都跨年度了,今天已经是2012年1月9日14:37:56了。必须创建文章的时候才可以选择“原创、翻译”,让我有点小郁闷。呵呵,继续积硅步

   


分享到:
评论

相关推荐

    lucene-search-开源

    4. **构建索引**:启动Lucene守护进程,对MediaWiki的页面内容进行索引。这可能需要运行特定的脚本或工具。 5. **测试与优化**:测试搜索功能是否正常工作,根据实际效果调整Lucene的配置参数,如分词器、分析器等...

    Lucene索引优化

    描述:在Lucene的wiki上,我们找到了一系列关于如何提升Lucene应用中索引速度的技巧与策略。这不仅涵盖了技术细节,还提供了实际操作建议,旨在帮助开发者针对特定场景优化其Lucene索引性能。 ### 知识点详细解析:...

    Wiki-Search-engine:维基搜索引擎

    9. **优化和性能**:包括索引构建的速度优化、查询响应时间的减少以及内存和磁盘空间的有效利用。 10. **用户界面**:虽然题目中没有明确提到,但一个完整的搜索引擎系统通常还包括用户友好的搜索界面,接收用户的...

    Wikipedia2Lucene:从HDFS导入Wikipedia XML转储到Lucene索引或Elasticsearch,并基于Lucene的MoreLikeThis查询检索类似的Wikipedia文章

    从HDFS导入Wikipedia XML转储到Lucene索引或Elasticsearch,并基于Lucene的MoreLikeThis查询检索类似的Wikipedia文章。 此应用程序是基于文本的文档相似性度量的实现,该度量被用作的研究中的基准度量。 将...

    Wiki-Search-Engine:涉及使用大小为 43 GB 的 2013 年数据转储在 Wikipedia Data Dump 上构建搜索引擎。 搜索结果实时返回

    1. 并行处理:Java的并发框架如ExecutorService和Future,使得数据处理和索引构建可以在多核CPU上并行进行,大大提高了处理速度。 2. 内存管理:Java虚拟机(JVM)的垃圾回收机制使得开发者无需关心内存的分配和...

    xwiki全文搜索lucene后台代码

    - **性能优化**:为了提高搜索速度,可以考虑使用多线程索引、内存缓冲、分布式搜索等技术。 以上就是XWiki全文搜索与Lucene后台代码的工作原理。通过深入理解这一过程,开发者可以更好地利用XWiki的搜索功能,同时...

    lucence case study

    - **学术相关性调整**:提高检索结果的学术价值。 **技术栈**: - Lucene - Tapestry Rossetti Archive 是一个致力于收集和展示 Dante Gabriel Rossetti 及其家族作品的网站。为了实现这些目标,项目团队采用了 ...

    ASP.NET源码——[博客空间]ScrewTurn Wiki 2.0.37.zip

    4. **缓存管理**:为了提高性能,ScrewTurn Wiki可能会利用ASP.NET的缓存机制来存储频繁访问的数据,如wiki页面内容。这包括页面级别的缓存、数据集缓存以及自定义对象缓存等。 5. **身份验证与授权**:作为一个...

    ASP.NET-[博客空间]外索维客.99.zip

    4. **数据库交互**:Wiki系统通常需要存储页面内容和用户信息,因此会涉及ADO.NET或Entity Framework进行数据库访问。可能使用SQL Server或其他关系型数据库存储页面版本、作者信息等。 5. **权限和角色管理**:...

    Solr文档.pdf

    尽管单独使用Lucene实现站内搜索在索引维护、索引性能优化和搜索性能优化方面需要较大的开发工作量,而通过第三方搜索引擎接口实现站内搜索又会带来系统依赖紧密和扩展性较差的问题,但Solr提供了一个相对较好的解决...

    CodeXCavator - code indexing and search-开源

    搜索和索引基于Apache Software Foundation的Lucene框架。 CodeXCavator也可以通过插件扩展。 详细的文档可以在项目的Wiki中找到。 注意:如果您有一些有趣的语法突出显示定义并将其发送给我,我将把它们集成到下一...

    2-8+Elasticsearch应用及平台建设实践.pdf

    在58集团的数据库部门中,Elasticsearch被用于多个业务场景,包括日志流水处理、用户标签画像、数据库二级缓存、安全风控行为数据、图数据库索引、监控数据检索以及Wiki文档搜索。随着业务规模的扩大,集群的数量和...

    SMW SolrStore-开源

    4. **自动补全**:Solr 的自动补全功能可提供搜索建议,提高用户搜索效率。 5. **多语言支持**:Solr 对多种语言的处理能力使得 SMW SolrStore 能够处理多语言的 Mediawiki 环境。 ### 安装与配置 安装 SMW ...

Global site tag (gtag.js) - Google Analytics