使用 Solr 1.4 有几个优点（开箱即用的分面搜索、分组、复制、http 管理与卢克，...）。
即使我在我的 Java 应用程序中嵌入了搜索功能，我也可以使用SolrJ来避免使用 Solr 时的 HTTP 权衡。是否推荐 SolrJ？
那么，您何时建议使用“纯 Lucene”？它是否具有更好的性能或需要更少的 RAM？单元测试更好吗？
PS：我知道这个问题。
6789 次
5 回答
6
如果您有 Web 应用程序，请使用 Solr - 我已经尝试将两者集成，并且 Solr 更容易。否则，如果您不需要 Solr 的功能（想到的最重要的是分面搜索），请使用 Lucene。
于 2010-05-18T12:48:05.530 回答
5
如果您想将搜索功能完全嵌入到应用程序中，并且不想维护像 Solr 这样的单独进程，那么使用 Lucene 可能更可取。例如，桌面应用程序可能需要一些搜索功能（例如使用 Lucene 搜索其文档的 Eclipse IDE）。您可能不希望此类应用程序启动像 Solr 这样的繁重进程。
于 2010-05-18T12:23:48.260 回答
2
这是我必须使用 Lucene 的一种情况。
给定一组文档，找出其中最常用的术语。
在这里，我需要访问每个文档的术语向量（使用 TermVectorMapper 的低级 API）。使用 Lucene，这很容易。
另一个用例是对搜索结果进行非常专业的排序。例如，我希望搜索一个作者姓名（他写过多本书）以在前 10 个结果中从每个商店中生成一本书。在这种情况下，我会从每家书店找到结果，为了显示最终结果，我将从每家书店中挑选一个结果。在这里，您实际上是在进行多次搜索以生成最终结果。访问 lucene 的低级 API 肯定会有所帮助。
选择 Lucene 的另一个原因是尽快获得新的好东西。这不再是正确的，因为它们都已合并并且将有同步发布。
于 2010-05-18T12:54:01.463 回答
2
我很惊讶没有人提到 NRT - Near Real Time search，Lucene 提供，但 Solr 还没有。
于 2010-05-24T04:50:57.723 回答
0
如果您更关心可伸缩性而不是性能，请使用 Solr；如果您更关心性能而不是可伸缩性，请使用 Lucene。
于 2014-04-28T06:12:50.823 回答