在什么情况下更喜欢 Apache Lucene 而不是 Solr？
使用 Solr 1.4 有几个优点（开箱即用的分面搜索、分组、复制、http 管理与 luke 相比，...）。
即使我在 Java 应用程序中嵌入了搜索功能，我也可以使用 SolrJ 来避免 HTTP使用 Solr 时的权衡。 SolrJ 是否值得推荐？
那么，您什么时候建议使用“纯 Lucene”？它是否具有更好的性能或需要更少的 RAM？单元测试是否更好？
PS：我知道这个问题。
There are several advantages to use Solr 1.4 (out-of-the-box facetting search, grouping, replication, http administration vs. luke, ...).
Even if I embed a search-functionality in my Java application I could use SolrJ to avoid the HTTP trade-off when using Solr. Is SolrJ recommended at all?
So, when would you recommend to use "pure-Lucene"? Does it have a better performance or requires less RAM? Is it better unit-testable?
PS: I am aware of this question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您有 Web 应用程序，请使用 Solr - 我尝试过将两者集成，并且 Solr 更容易。否则，如果您不需要 Solr 的功能（我想到的最重要的功能是分面搜索），那么请使用 Lucene。
If you have a web application, use Solr - I've tried integrating both, and Solr is easier. Otherwise, if you don't need Solr's features (the one that comes to mind as being most important is faceted search), then use Lucene.
如果您想将搜索功能完全嵌入到应用程序中，并且不想维护像 Solr 这样的单独进程，那么使用 Lucene 可能是更好的选择。例如，桌面应用程序可能需要一些搜索功能（例如使用 Lucene 搜索其文档的 Eclipse IDE）。您可能不希望此类应用程序启动像 Solr 这样的繁重进程。
If you want to completely embed your search functionality within your application and do not want to maintain a separate process like Solr, using Lucene is probably preferable. Per example, a desktop application might need some search functionality (like the Eclipse IDE that uses Lucene for searching its documentation). You probably don't want this kind of application to launch a heavy process like Solr.
这是我必须使用 Lucene 的一种情况。
给定一组文档，找出其中最常见的术语。
在这里，我需要访问每个文档的术语向量（使用 TermVectorMapper 的低级 API）。使用 Lucene 就很容易了。
另一个用例是对搜索结果进行非常专业的排序。例如，我想要搜索作者姓名（写过多本书），以便在前 10 个结果中找到每个商店的一本书。在本例中，我将从每个书店查找结果，并从每个书店选择一个结果来显示最终结果。在这里，您实际上是在进行多次搜索以生成最终结果。访问 lucene 的低级 API 肯定会有所帮助。
选择 Lucene 的另一个原因是尽快获得新的东西。这不再是真的，因为它们都已经合并并且将会有同步版本。
Here is one situation where I have to use Lucene.
Given a set of documents, find out the most common terms in them.
Here, I need to access term vectors of each document (using low-level APIs of TermVectorMapper). With Lucene it's quite easy.
Another use case is for very specialized ordering of search results. For exmaple, I want a search for an author name (who has writen multiple books) to result into one book from each store in the first 10 results. In this case, I will find results from each book store and to show final results I will pick one result from each book store. Here you are essentially doing multiple searches to generate final results. Having access to low-level APIs of lucene definitely helps.
One more reason to go for Lucene was to get new goodies ASAP. This no longer is true as both of them have been merged and there will be synchronous releases.
我很惊讶没有人提到 NRT - 近实时搜索，可用于 Lucene，但不可用于 Solr（尚）。
I'm surprised nobody mentioned NRT - Near Real Time search, available with Lucene, but not with Solr (yet).
如果您更关心可扩展性而不是性能，请使用 Solr；如果您更关心性能而不是可扩展性，请使用 Lucene。
Use Solr if you are more concerned about scalability than performance and use Lucene if you are more concerned about performance than scalability.