使用Lucene的缺点是什么？

Question

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

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

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

P.S。我知道还有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为many people and companies做了出色的工作。不过，您的里程可能有所不同。 一个可能的问题是Lucene的评分模型 - 它使用TF / IDF和布尔评分的组合，而其他IR工具使用概率更强的BM25。但是，您可能会与Lucene合作多年，搜索结果也足够好。此外，扩展到数百万个文档并不容易。

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

Answer 4

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