Hibernate Search 中文操作指南

全文搜索是一组技术，用于在文本文档语料库中搜索与给定查询最匹配的文档。

与传统搜索（例如在 SQL 数据库中）的主要区别在于，存储的文本不被视为单个文本块，而是标记（单词）的集合。

Hibernate Search 依靠 #coordination-none[或 ]#coordination-none[来实施全文搜索功能。由于 Elasticsearch 在内部使用 Lucene，因此它们有很多特性和一般全文搜索方法是相同的。

简而言之，这些搜索引擎基于倒排索引的概念：一个字典，其中键是文档中找到的标记（单词），值是包含此标记的每个文档的标识符列表。

仍然简化一下，一旦所有文档编入索引，搜索文档就会涉及三个步骤：

当涉及到应用程序的领域模型时，Hibernate Search 会区分被视为实体的类型（Java 类）和非实体的类型。

Hibernate Search 中实体类型的定义特征在于它们的实例具有不同的生命周期：实体实例可以保存到数据存储中，或者从数据存储中检索，而无需保存或检索另一种类型的实例。出于此目的，假设每个实体实例都带有不可变的唯一标识符。

这些特性使 Hibernate Search 能够将实体类型 map 到索引，但只能索引实体类型。从实体中引用或包含在其中的“可嵌入”类型，但其生命周期完全绑定到该实体，不能映射到索引。

Hibernate Search 的多个方面涉及实体类型概念：

Hibernate search 针对的应用程序使用基于 entity 的模型来表示数据。在此模型中，每个实体都是单个对象，具有几个原子类型属性（String、Integer、LocalDate、…​）。每个实体可以包含非根聚合（“可嵌入”类型），并且每个实体还可以与一个甚至多个其他实体有多个关联。

相比之下，Lucene 和 Elasticsearch 使用文档。每个文档都是一个“字段”集合，每个字段都被分配一个名称（一个唯一字符串）和一个值（可以是文本，也可以是整数或日期等数字数据）。字段还具有类型，该类型不仅确定值（文本/数字）的类型，更重要的是确定该值将被存储的方式：已编入索引、已存储、含 doc 值等。每个文档都可以包含嵌套聚合（“对象”/“嵌套文档”），但顶级文档之间实际上不能有关联。

这样：

实体模型和文档模型之间存在多个不匹配：简单属性类型与更复杂的字段类型、关联与无关联、图表与树集合。

mapping 在 Hibernate search 中的目标是通过定义如何将一个或多个实体转换为文档，以及如何将搜索结果解析回原始实体，来解决这些不匹配的情况。这是 Hibernate Search 的主要附加值，也是从 indexing 到各种搜索 DSL 的一切事物的基础。

映射通常使用实体模型中的注释进行配置，但这也可以使用编程 API 来实现。要了解有关如何配置映射的更多信息，请参见 Mapping entities to indexes。

要了解如何为生成的文档编制索引，请参见 Indexing entities（提示：对于 Hibernate ORM integration，为 automatic）。

要了解如何使用利用映射来更接近实体模型的 API 进行搜索（特别是将结果作为实体而不是仅仅作为文档标识符进行返回），请参见 Searching。

尽管 mapping 定义是声明式的，但需要解释这些声明并将其实际应用于领域模型。

这就是 Hibernate Search 所谓的“绑定”：在启动期间，给定的映射指令（例如 @GenericField）将导致实例化并调用“绑定程序”，使它有机会检查其应用于该部分的域模型并“绑定”（分配）一个组件到模型的那一部分（例如“桥”，负责在索引期间从实体中提取数据）。

Hibernate Search 附带绑定程序和桥接程序，用于许多常见用例，还提供了插入自定义绑定程序和桥接程序的能力。

有关更多信息，特别是有关如何插入自定义绑定器和桥接器的信息，请参见 Binding and bridges。

如 Full-text search 中所述，全文引擎处理标记，这意味着必须在索引（文档处理，构建标记 → 文档索引）和搜索（查询处理，生成要查找的标记列表）时处理文本。

但是，处理不仅仅是“标记化”。索引查找是精确查找，这意味着查找 Great （大写）不会返回仅包含 great （全小写）的文档。在处理文本时执行额外的步骤来解决此警告：标记过滤器，这可以规范标记。由于这种“规范化”， Great 将被编入索引为 great ，以便查询的索引查找 great 将按预期匹配。

在 Lucene 世界（Lucene、Elasticsearch、Solr，…​），在索引和搜索阶段期间的文本处理称为“分析”，并由“分析器”执行。

分析器由三类组件组成，这些组件将按照以下顺序连续处理文本：

分词器通常在空格处分隔（尽管还有其他选项）。令牌筛选器通常是在其中进行自定义的地方。它们可以删除重音字符，删除无意义的后缀（-ing、 -s、…​）或令牌（a、 the、…​），用所选拼写替换令牌（wi-fi ⇒ wifi），等等。

除非您知道自己在做什么，否则通常应该支持标记过滤器。

在某些情况下，有必要在不分词的情况下以一个块的方式对文本进行索引：

为了解决这些用例，可以使用一种称为“规范化器”的特殊分析器类型。规范化器只是保证不使用分词器的分析器：它们只能使用字符筛选器和令牌筛选器。

在 Hibernate Search 中，分析器和规范化器由其名称引用，例如 when defining a full-text field。分析器和规范化器具有两个单独的命名空间。

某些名称已分配给内置分析器（特别是在 Elasticsearch 中），但可以（并且建议）为自定义分析器和规范化器分配名称，使用内置组件（分词器、筛选器）组装这些名称以满足您的特定需求。

每个后端都公开其自己的 API 来定义分析器和规范化器，并通常来配置分析。有关更多信息，请参阅每个后端的文档：

为了在索引和搜索时获得最佳吞吐量，Elasticsearch 和 Lucene 在写入和从索引读取时都依赖于“缓冲区”：

在写入程序为 committed 时，会将更改“推”到实际索引。在提交发生之前，未提交的更改处于“不安全”状态：如果应用程序崩溃或服务器断电，未提交的更改将丢失。

在阅读程序为 refreshed 时，视图会更新。在刷新发生之前，搜索查询的结果可能略有过期：自上次刷新以来添加的文档将丢失，自上次刷新以来删除的文档仍会存在，等等。

显然，不安全的更改和不同步索引不可取，但它们是提高性能的权衡之计。

以下不同因素会影响刷新和提交发生的时间：

请参阅 here for Elasticsearch 。

请参阅 here for Lucene 。

也没有隔离的概念。在刷新之后，将考虑对索引的所有更改：那些提交给索引的更改，以及仍缓冲在索引写入器中的更改。

出于此原因，提交和刷新可以被视为完全正交的概念：某些设置偶尔会导致提交的更改在搜索查询中不可见，而其他设置则允许即使未提交的更改在搜索查询中可见。

分片将索引数据拆分为多个称为分片的“较小索引”，以提升在处理大量数据时性能。

在 Hibernate Search 中，与 Elasticsearch 类似，另外一个概念与分片密切相关：路由。路由包含将文档标识符（或一般称为“路由密钥”的任意字符串）解析到对应分片。

在索引时：

在搜索时：

后端将这些路由键解析为一组分片，并将仅在所有分片上执行查询，忽略其他分片。

添加一个过滤器到查询中，以便仅匹配用给定的一个路由键建立索引的文档。

因此，分片可用于通过以下两种方式提升性能：

要启用分片，需要一些配置：