使用Lucene的缺点是什么？

Question

我正在考虑在我的项目中使用Lucene来进行非常快速的搜索。 我知道Lucene创建了自己的文件，它保存所有的数据/索引。

我想知道使用Lucene的缺点是什么？ 有吗？

您是否必须对文件数据库执行任何操作，或者在没有任何外部帮助的情况下工作得很好？

PS我知道还有Lucene .NET，我打赌同样的规则适用于那里。

Answer 1

Lucene很棒。 非常灵活，令人惊讶的快速，以及可靠的API。 邮件列表非常有用。

这些文件确实需要一些维护，但可以使用提供的工具完成。 最重要的是偶尔优化索引，但只有在定期更新索引时才需要这样做。

我建议也要考虑Solr。 它本质上是一个位于Lucene之上的webapp和工具。 它使创建新索引，保持优化以及为可伸缩搜索集群提供主/从同步变得更加容易。 当然，这取决于您的实际需求。

举个例子，我曾经为一家知名的大型游戏公司维护一个搜索索引。 该索引拥有数十万种多语言（全球）和语言环境的条目。 它每天在集群上执行一百万次搜索，几乎不使用任何CPU和合理的内存量。 它已经在我们拥有的硬件上进行了大约3亿次搜索的负载测试，并且可以通过简单地向cluser添加更多的盒子来线性扩展。 Solr和Lucene是这方面的主要工具。

如果我不得不给出一个缺点，那就是学习曲线。 有一点需要理解，如果你想要一个真正优化的解决方案，你需要很好地了解它。 但是，如果您自己执行此操作，则会使用您使用的任何搜索工具。 文档，维基和邮件列表为此提升提供了大量支持。

Answer 2

我对Lucene的经验有限，到目前为止它一直很棒。 我能看到的缺点主要来自业务方面：

1. 我必须积极地将Lucene用于我的老板，默认我们会使用SQL Server。 为了进行切换，我必须毫无疑问地证明Lucene对于我们的用例表现更好（而不仅仅是类似）。 我想这个问题是“没有人因购买IBM设备而被解雇”。
2. 特别是Lucene.Net正在进行的开发/错误修复在这一点上是值得怀疑的，再次更难以出售。 我希望社区能够团结起来。

Answer 3

Lucene为很多人和公司做了很多工作。 不过，您的里程可能有所不同。 一个可能的问题是Lucene的评分模型 - 它使用TF / IDF和布尔评分的组合，而其他IR工具使用概率更强的BM25。 但是，您可能会与Lucene合作多年，搜索结果也足够好。 此外，扩展到数百万个文档并不容易。

它归结为您的具体用例。 最好使用Solr开始测试，看看是否符合您的需求。

Answer 4

Lucene确实存在可扩展性问题。 当索引越来越大时，其性能会下降。