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

Question

我想索引大约300万个solr文本文档。这些文件中大约1/3是电子邮件，其中包含大约1-5段文字。剩下的2/3文件每句只有几句话。

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

整个数据集最初都必须编入索引。这就像一个旧系统必须加载到一个新系统，所以数据必须被索引，并且需要尽可能快，但是我不确定要优化这个时间需要考虑哪些领域。

我在想，也许有很多像“这，一个，因为，应该，如果......”这样的小词汇造成了很多开销并且只是“噪音”字。我很好奇，如果我将它们切断，如果它会大大加快索引时间。我一直在看Lucid文档一段时间，但我似乎无法找到一种方法来指定什么词不索引。我遇到了“停止列表”一词，但没有多过提及它。

是否有其他方法可以使这种索引变得更快，或者我只是坚持1小时索引时间？

Answer 1

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

可以有多种方法（比如你提到的那个，停用词等）来优化，但是无论你在索引时间方面做了什么，Solr都无法击败Sphinx。我已经完成了自己的基准测试。

我也非常喜欢Solr，因为它易于使用，它具有出色的功能，如N-Gram Indexing，Faceting，Multi-core，Spelling Correctors以及与其他apache产品的整合等等。但是当它来优化算法（是它的索引大小，索引时间等）狮身人面像岩石！

斯芬克斯也是开源的。试试看。

Answer 2

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

1. 使用GZipOutput/InputStream和Bse64Output/InputStream压缩大文本。这可以减少约85％的文本大小，这可以减少传送请求/响应的时间。

2. 为了减少内存使用在客户端：

   2.1我们使用流API（GSON流或XML斯塔克斯）通过一个阅读文档之一。

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

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