优化Lucid/Solr索引大型文本文档

Question

我正在尝试用solr为大约300万个文本文档建立索引。这些文件中约有1/3是电子邮件，其中包含大约1-5段文本。剩下的2/3的文件每个只有几个单词到句子。

Lucid/Solr需要将近1个小时才能完全索引我正在使用的整个数据集。我正在试图找到优化这一点的方法。我将Lucid/Solr设置为每100,000个文件提交一次，并且它一次对50,000个文件的批处理文件进行索引。内存不再是问题，因为它始终保持在1 1GB左右的内存，因为批处理。

整个数据集必须在一开始就建立索引。这就像一个遗留系统，必须加载到新系统中，所以数据必须被索引，并且需要尽可能快，但我不确定这次要优化哪些领域。

我在想，也许有很多小单词，比如"the，a，因为，should，if，...“它们造成了大量的开销，只是“噪音”词。我很好奇，如果我把它们去掉，会不会大大加快索引速度。我已经看了Lucid文档一段时间了，但我似乎找不到一种方法来指定哪些单词不需要索引。我偶然发现了“停止列表”这一术语，但除了顺便提到它之外，没有看到更多的东西。

有没有其他方法可以让索引速度更快，或者我只是坚持了1小时的索引时间？

Answer 1

从您的查询中可以看出，索引时间对您的应用程序非常重要。Solr是一个很棒的搜索引擎，但是如果你需要超快的索引时间，如果这对你来说是一个非常重要的标准，那么你应该使用Sphinx搜索引擎。使用Sphinx快速设置和基准测试结果不会花费太多时间。

有很多方法(比如你提到的那个，停用词等等)。然而，为了优化，无论您在索引时间方面做什么，Solr都无法击败Sphinx。我已经完成了自己的基准测试。

我也非常喜欢Solr，因为它易于使用，它的开箱即用的强大功能，如N-Gram索引，刻面，多核，拼写校正器以及它与其他apache产品的集成等。但是当涉及到优化算法时(索引大小、索引时间等)斯芬克斯太棒了！！

Sphinx也是开源的。试试看。

Answer 2

我们最近遇到了类似的问题。我们不能使用solrj，因为请求和响应必须经过一些应用程序，所以我们采取以下步骤：Creating Custom Solr Type to Stream Large Text Field！

1. 使用GZipOutput/InputStream和Bse64Output/InputStream来压缩大文本。这可以减少大约85%的文本大小，这可以减少传输request/response.
2. To的时间，减少客户端的内存使用：

2.1我们使用stream api(GSon流或XML Stax)逐个读取文档。

2.2定义一个自定义的Solr字段类型:接受FileHolder作为值的FileTextField。FileTextField最终会将一个阅读器传递给Lucene。Lucene将使用阅读器读取内容并添加到索引中。

2.3.当文本字段太大时，首先将其解压缩为临时文件，创建FileHolder实例，然后将FileHolder实例设置为字段值。