休眠搜索与自定义搜索答案

【问题标题】：Hibernate Search vs Custom Search休眠搜索与自定义搜索
【发布时间】：2011-12-24 23:58:48
【问题描述】：

我有一个页面可以根据某些条件（id、姓名、电子邮件、部门、工作）搜索用户现在我正在使用 Hibernate Criteria Queries 进行搜索，它工作得很好。我想知道 hibernate search 与 lucene 查询 的优势，这将使我使用它，而不是使用我当前的自定义搜索。

【问题讨论】：

标签： hibernate design-patterns jakarta-ee hibernate-search

【解决方案1】：

对于您的情况，我相信 Criteria API 就足够了。如果缓存了可重复的并且您在索引数据上执行它们，您的 Criteria API 搜索可以执行良好。

如果您有以下类型的查询，这可能就足够了：

给我“FooBar”部门的所有用户。

或

给我“FooBar”部门的所有工作“FooBarIst”的用户

但是，如果您对大量未编入索引的数据进行操作，您可能会注意到性能下降。例如，如果您的“名称”属性没有被缓存，您会注意到以下类型的查询：

给我所有名为“Harr*”的用户这应该给你用户的名字

Harrold 
Harrison 
Harring 
Harrelson

表现会很差。

我的意思是，如果您没有在数据库引擎中为“名称”属性编制索引，那么这个查询会很慢。因此，如果您打算使用此类查询，最好开始考虑全文搜索解决方案，即 Hibernate Search/Lucene/Solr。

例如，在搜索电子邮件或其他一些属性并且您尝试创建自动完成功能时，它们会为您提供更好的性能。

所以，我给你的建议如下：根据所涉及的场景，选择是仅使用 Criteria API 还是 Criteria API + Hibernate Search/Lucene。只要您知道它的限制是什么，只使用 Criteria API 就可以了。

这里是第一个场景的常见查询（其中 Criteria API 就足够了，而 Hibernate Search + Lucene 有点矫枉过正）：

FooBarDepartment 中的所有用户

这是第二种情况的常见查询（Criteria API 可以做到，但 Hibernate Search + Lucene 会是更好的选择）：

电子邮件以字母“f”开头的所有用户所有电子邮件以“fOo”开头的用户会怎样？

当然，可以使用普通的 Criteria API 完成上述查询，但如果您有数百万用户，在进行此类查询时，您会开始注意到 Hibernate Search/Lucene 方法与简单的标准方法。

因此，总而言之，您是使用普通 Criteria 还是 Criteria + Hibernte Search + Lucene 取决于您，并且取决于需求、设计和数据。

【讨论】：

【解决方案2】：

是的，正如 baba 建议的那样，您可以获得更好的性能，但最重要的是，它提供了巨大的功能提升和更好的用户体验。

返回匹配的顺序将（可选地）按相关性，并且可以处理用户拼写错误、自动建议并对搜索词的文本（如单词相似度）进行一些智能处理。

您可以提供“google like”单字段输入文本，智能匹配不同字段甚至实体类型；使用 Criteria 或 SQL 实现这样的功能是一种疯狂的复杂性，不会为您带来好的结果。

集成您自己的基于 Lucene 的自定义引擎的最佳部分是您可以根据应用程序的特定需求自定义几乎所有内容，以声明方式；例如，您定义特定领域的同义词，以及您的应用程序如何理解首字母缩略词。

在生成的索引之上，执行数据挖掘、文档相似性搜索等变得轻而易举。例如，您可以构建标签云，而无需用户实际手动标记内容：您已经有了数据库中所有术语的频率。

一个例子？该网站右侧的列显示“相关”问题。我不知道他们是否为此使用了 Hibernate Search，但这正是它有助于实现的功能。

【讨论】：