我们正在开发一个使用Spring MVC，Spring和Hibernate的Web应用程序。哪一个更适合高效的自由文本搜索，Hibernate Search或Lucene？
我们需要为我们的应用程序添加高效的自由文本搜索功能。为此，我们正在考虑使用Hibernate Search（它使用Lucene下的引擎）或直接使用lucene。
对我们来说最好的选择是什么，因为我们已经在我们的应用程序中使用hibernate了？相互之间有什么优点和缺点？
谢谢。
你自己说的 - 你会用一种或另一种方式使用Lucene。
原始Lucene API不是很容易使用。它比Hibernate Search低得多。如果您已经在使用Hibernate，那么这是一件简单的事情 - 使用Hibernate Search来实现您的文本搜索功能。
使用Lucene的另一种方式是获取被称为SOLR的middlman API。 SOLR将连接到Lucene并执行HTTP调用以进行搜索。请注意，您需要构建并解析Solr消耗的XML。 Lucene的所有功能都是通过SOLR进行处理，应该是非常有用的。
免责声明：我是Hibernate Search的开发人员之一。
该项目的目标不是与Lucene或Solr竞争，而是为了尽可能地促进与Hibernate应用程序的集成，避免必须保持两个世界同步并复制所有映射和CRUD操作。虽然我们提供了一些常用的帮助程序和一个很好的封装，但Hibernate Search也可以直接引用Lucene API，所以如果您发现自己需要使用“原始”Lucene API，您将永远不会被卡住。同样为了写入索引，Hibernate Search提供了一个通用模式，它将解决大部分已知的需求，但是如果你有非标准的需求，你可以完全控制书面文档。
Solr是一个很好的选择，但由于它是一个单独的服务器，您必须通过REST API进行交互，这是非常不同的，它有其优点和缺点。有第二个服务来管理并不总是想要的，当然，远程调用将永远不会像直接引用Lucene一样有效，而且它的所有内部过滤器和缓存都是如此。 并非Lucene的所有功能都可以通过远程API公开，并且如果您需要执行一些“低级别”操作，如果在Solr中未实现此操作，则无法执行此操作（不修补Solr）。 Solr仍然非常可爱，特别是当你想与其他非Java应用程序共享索引时，所以我们可能会为Hibernate Search添加一个Solr后端，以最终保持Solr服务器同步（尤其是如果它对此感兴趣，并且可能一些帮助）。
最后，Lucene API真的是很难核心的东西。我们花费了大量的精力来充分利用它来提供最佳性能，同时向使用Hibernate Search的用户公开稳定的API，基本上到现在为止，所有版本都向后兼容，以提供“插入式”性能提升，以便使用最新版本Lucene的最大窍门 - 实际上经常改变API;这些改变总是令人兴奋的，但是如果你没有使用适当的抽象方法，就要准备好在应用程序中保留这些改变。