lucene-wiki翻译-(lucene 常见问题提醒)LuceneCaveats

 

 

 

• 原文： http://wiki.apache.org/lucene-java/LuceneCaveats
• 导航：Lucene-java Wiki-》1 Overview-》 1.1 Informational-》 1.1.1 BasicsOfPerformance-》 1.1.1.6 LuceneCaveats
• 注意：“ 红色 ”，表示不知道、不确定怎么翻译。  “ 蓝色”自己的描述。
• 状态：翻译完

    文章内容如下（不是一板一眼的翻译，夹杂了自己的思路，呵呵）：

       本文叙述的是一些经典、常见的Lucene的错误。由于这些错误的详细解决方法在其他文档中已经被提出来过，所以呢，本文并不会重复的在讲一遍，而只是一些简单的提示。具体解决方法，去看 HowTo吧。

 

 

 

学习使用lucene的好助手luke（Luke is your friend）

   工欲善其事必先利其器。在讨论这些常见错误之前，先隆重介绍一款工具luke。Luke 这工具真很不错，他可以帮助你深刻的理解索引结构，通过这个工具我们可以(部分)看到索引中到底存储了什么。下载地址如： Luke。不过，比较让我郁闷的是，我的lucene版本是lucene-3.4.0，而下载到的Luke是lukeall-0.9.9.jar（针对Lucene 2.9.0），结果索引文件打不开，小郁闷。

 

    我们把错误分成两类，一类是索引错误，另一类是查询错误。先说常见索引错误。

 

1.常见索引错误

 

1.1请确保在索引时使用相同的分词器-analyzer

 

     Analyzer—按功能应该称之为“分词器”。它的作用就是把一段文字分成词组，例如：“google是一个非常好的搜索引擎”在不同的分词器下可能有不同的结果，如下：

 

分词器A： google 非常 搜索引擎
分词器B： google 非常 搜索 引擎

 

     假设你建立索引时用了“分词器A”、查询时用了“分词器B”。那么当你输入“搜索引擎”肯定找不到你需要的结果了。 可以参考看看: LuceneFAQ, "Why am I getting no hits / incorrect hits?".

1.2文档被意外截断

 

 

 原文

The indexer by default truncates documents to IndexWriter.DEFAULT_MAX_FIELD_LENGTH or 10,000 terms in Lucene 2.0.

Rule of thumb: an average page of English text contains about 250 words. (Source: Google Answers.) This means only about 40 pages are indexed by default. If any of your documents are longer than this (and you want them indexed in full), you should raise the limit with IndexWriter.setMaxFieldLength().

 

 

 

      默认情况下，Lucene 2.0的indexer（索引器）最多只会保存IndexWriter.DEFAULT_MAX_FIELD_LENGTH （10,000） ，即1万个terms（注意，我觉得这一点应该是FIELD才对，算了下去做试验吧）。理解这一点，你需要事先理解一下lucene的索引结构。

 

 

1.3停用词剔除（Stopwords are removed）

 

    原文

StandardAnalyzer (the most commonly recommended analyzer) does not index "stopwords". Stopwords are common English words such "the", "a", etc. -- the default list is StopAnalyzer.ENGLISH_STOP_WORDS. These words are completely ignored andcannot be searched for, at all. This means that even phrase queries aren't exact. E.g. the phrase query "to be or not to be" finds nothing at all.

     StandardAnalyzer （这是一个老外用的分词器，中国人几乎不用，呵呵），不过几乎所有的分词器都不会解析停用词，例如：的，了……。既然，没被分词，也不会被索引了，当然也不可能查询到了啊

 

2.性能（Performance）

 

2.1保存索引处于open状态（Keep the index open） 

原文

Especially in a Web application, where keeping state between requests requires additional work, it is tempting to open and close the index on every request. Unfortunately, this leads to very poor performance. At first this might work with small indexes or beefy hardware, but performance problems soon crop up -- e.g. large garbage collections.

You should keep the index open as long as possible. Both IndexReader and IndexSearcher are thread-safe and don't require additional synchronization. One could cache the index searcher e.g. in the application context.

See also: LuceneFAQ, "Is the IndexSearcher thread-safe?".

 

      尤其是在web应用中(这种应用需要保持requests 、requires状态)，通常会在每次请求中都打开一次、关闭一次索引。不幸的是，这中方式将导致非常低的性能。这种方式可能只会在索引文件较小，或者非常好的硬件环境下才可以正常工作。但系能问题将会很快的出现，例如，巨大垃圾回收负担（这句话怎么感觉驴唇不对马嘴啊，还请指教）。

 

     我们应该尽可能让index处于open状态。另外IndexReader 和IndexSearcher 对象都是线程安全的，不要求增加额外的同步。（我检讨，我有个项目写成每个请求都open，并close的了）。我们应该缓存index searcher，例如，在web应用中我们可以放到application上文中。

 

参考: LuceneFAQ, "IndexSearcher是线程安全的吗？".

 

2.2无需缓存搜索结果（No need to cache search results）

 

    原文

 

 Lucene is amazingly fast at searching. Rather than caching hits and paging through them, merely re-executing the query is often fast enough.

 

See: LuceneFAQ, "How do I implement paging, i.e. showing result from 1-10, 11-20 etc?"

When doing sub-searches (searching the results of a previous search), it's easier (and fast enough) to add the first query as a conditional to the second.

But if you really need to do this, see: LuceneFAQ, "Can I cache search results with Lucene?". See also: LuceneFAQ, "Can Lucene do a "search within search", so that the second search is constrained by the results of the first query?".

 

. 

    与上相反，lucene虽然建议index一直处于open状态，但不建议缓存结果。（晕，苍天啊、大地啊，我又差点搞翻）。

 

    lucene的搜索速度非常、非常快。（多快呢？？江湖传言上G的话，速度将会变慢，要0.X秒）。与缓存查询结果和paging through them（分页，遍历，NND的，不确定啊）相比，重新执行反而更快。

 

    关于分页参看: LuceneFAQ, "如何实现分页，例如显示1-1-10, 11-20 ……这样的结果？".

 

    “子搜索”-sub-searches（即在搜索结果中再次进行搜索）要比把两次查询结果放到一起要容易，也更快些。

 

    如果你真的需要缓存结果，可以参看：: LuceneFAQ, "可以缓存Lucene搜索结果吗？". 也可以参考: LuceneFAQ, "可以在搜索结果中搜索吗？……".

2.3 使用RangeFilter代替RangeQuery（Use RangeFilter instead of RangeQuery）

 原文

RangeQuery expands every term in the range to a boolean expression, and easily blows past the built-inBooleanQuery.maxClauseCount limit (Lucene 2.0 defaults to about 1000).
RangeFilter doesn't suffer from this limitation.
See: LuceneFAQ, "Why am I getting a TooManyClauses exception?".

 

 

 

RangeQuery expands every term in the range to a boolean expression, and easily blows past the built-inBooleanQuery.maxClauseCount limit (Lucene 2.0 defaults to about 1000).

RangeFilter 没有该限制.

参看: LuceneFAQ, "为什么会出现TooManyClauses 异常?".

3 Querying

 

3.1 lucene是根据query对象进行搜索的而不是String对象（Edit the query rather than the string）

 

 

原文 写道

Parsing free text is a surprisingly hard problem at which QueryParser does a pretty good job. Rather than editing the query string, change the Query objects returned by the QueryParser.
E.g. when offering additional search options in a Web form, it's easier and safer to combine them with the parsed Query object rather doing text manipulations on the query string.

 

 

解析自由文本是一个非常艰巨的工作，不过 QueryParser 做的很好。lucene通过 QueryParser.对象返回的Query 对象来进行是搜索。

 

 

 

 

E.g. when offering additional search options in a Web form, it's easier and safer to combine them with the parsed Query object rather doing text manipulations on the query string.

 

对于这一小节，感觉很简单的事情被说复杂了。个人认为其要表达的意思是：

 

3.2 Lucene并不是一个真正的布尔系统（Lucene is not a true boolean system）

 

 

原文 写道

Or: apple AND banana OR orange doesn't work. Surprising at first. QueryParser does its best to translate from a boolean syntax to Lucene's own set-oriented queries, but it falls short. Either use parentheses everywhere or try to design your user interface accordingly.
See BooleanQuerySyntax.

 

输入“Or: apple AND banana OR orange” 并不能够工作。这是应为  QueryParser  并不能很好的把用户（这不是一般的用户，是一个会玩布尔查询表达式的用户，普通用google、百度的用户，罕有这么玩的）输入布尔表达式翻译成Query对象。

参考： BooleanQuerySyntax .

这标题很吓人，google、百度早已经让人忘记了“布尔查询”语句这种玩意，真的有人在乎吗？

 

 

3.3 遍历素有hits是非常耗时的（Iterating over all hits takes a long time）

 

 

原文 写道

This is by design. Try using a HitCollector instead if you need access to all the hits for a search.

 

 

没啥说的，被设计成这样了。如果你需要遍历所有的搜索结果，可以尝试使用 HitCollector  代替。 

 

 

3.4 高亮显示搜索结果（Highlighting search results）

 

The Lucene-contributed highlighter does the best it can, but it doesn't have the information it really needs to correctly highlight the search results.

See: LuceneFAQ, "Is there a way to get a text summary of an indexed document with Lucene (a.k.a. a "snippet" or "fragment") to display along with the search result?"