1. 使用 _mapping API 获取字段信息

2. 使用 _search API 显示字段值

3. 使用fields 参数 过滤字段

4. 显示嵌套字段

1.使用 _mapping API 获取字段信息

_mapping API 允许您检索一个或多个索引的映射定义。这包括有关字段、其数据类型和其他属性的信息。要检索特定索引的映射，请使用以下请求：

例如，如果有一个名为my_index 的索引，可以通过以下请求检索其映射：

响应将包括索引的映射定义，其中包含有关字段及其属性的信息。

还可以检索某一特定字段的映射。如果您的映射范围很大，而您只想专注于某一特定领域，这将非常有用。要检索特定字段的映射，请使用以下请求：

您还可以检索多个字段的映射，方法是用逗号分隔字段名，如下所示：

2.使用 _search API 显示字段值

要显示 Elasticsearch 索引中字段的值，可以使用_search API。默认情况下，_search API 会返回_source 字段，其中包含被索引的原始 JSON 文档。要只显示特定字段，可以在搜索请求中使用_source 参数。

下面是一个搜索请求示例，它返回my_index 索引中文档的title 和author 字段的值：

在本例中，_source 参数指定了要返回的字段。

3.使用字段参数过滤字段

您还可以使用fields 参数过滤搜索响应中返回的字段。如果您只需要特定字段，并希望减小回复的大小，这可能会很有用。fields 参数接受一个字段名或通配符模式数组。

例如，要只返回my_index 索引中文档的title 和author 字段，可以使用以下搜索请求：

请注意，为了不返回源文件，_source 参数设置为 false。

要返回text 数据类型的所有字段，可以使用通配符模式，如下所示：

4.显示嵌套字段

如果索引包含嵌套字段，可以使用点符号在fields 参数中指定嵌套字段路径。例如，如果嵌套字段的名称是address.city ，可以像这样将其包含在搜索响应中：

在此示例中，搜索响应将包括title 、author 和address.city 字段的值。

结论

总之，在 Elasticsearch 索引中显示字段可以使用_mapping API 来检索字段信息，使用_search API 来显示字段值。您可以使用_source 或fields 参数过滤搜索响应中返回的字段，并使用点符号显示嵌套字段。这些技术可以帮助您了解数据结构、识别特定字段并排除故障。

水印背景

Elasticsearch 集群上有各种 "水印 "阈值，可帮助您跟踪可用磁盘空间。当节点上的磁盘填满时，第一个越过的阈值就是 "低磁盘水印"。 第二个阈值就是 "高磁盘水印阈值"。 最后，将达到 "磁盘淹没阶段"。一旦过了这个阈值，群集就会阻止写入已通过水印的节点上有一个分片（主分片或副本）的所有索引。 仍可进行读取（搜索）。

如何预防和处理磁盘过满（利用率过高）的情况

有多种方法可以处理 Elasticsearch 磁盘过满的情况：

1. 删除 旧数据：通常情况下，数据不应无限期保存。防止和解决磁盘过满的方法之一是确保当数据达到一定年限时，对其进行可靠的归档和删除。一种方法是使用ILM。

2. 增加存储容量：如果无法删除数据，可能需要添加更多数据节点或增加磁盘大小，以便在不影响性能的情况下保留所有数据。如果需要为群集增加存储容量，则应考虑是否只需增加存储容量，还是同时按比例增加存储容量以及 RAM 和 CPU 资源（请参阅下文有关磁盘大小、RAM 和 CPU 比例的部分）。

如何为 Elasticsearch 集群增加存储容量

1. 增加数据节点的数量： 请记住，新节点的大小应与现有节点相同，并使用相同的 Elasticsearch 版本。

2. 扩大现有节点的规模： 在基于云的环境中，增加现有节点的磁盘大小和内存/CPU 通常很容易。

3. 只增加磁盘大小： 在基于云的环境中，增加磁盘大小通常相对容易。

4. 快照 和 恢复：如果您愿意让旧数据根据要求通过自动流程从备份中检索出来，您可以对旧索引进行快照、删除，并根据要求从快照中临时恢复数据。

5. 减少每个分片的副本数量：减少数据的另一个方法是减少每个分片的副本数量。为了实现高可用性，您希望每个分片有一个副本，但当数据变旧时，您可能不需要副本也能工作。如果数据是持久性的，或者您有备份可以在需要时恢复，那么这种方法通常是可行的。

6. 创建警报：为了防止磁盘将来被填满并采取主动行动，应根据磁盘使用情况创建警报，以便在磁盘开始填满时发出通知。

如何预防和处理磁盘容量利用不足的情况

如果磁盘容量未得到充分利用，有多种选择可以减少群集的存储容量。

如何减少 Elasticsearch 集群的存储容量

减少群集存储容量的方法有很多种。

1.减少数据节点数量

如果你想减少数据存储，同时按相同比例减少 RAM 和 CPU 资源，那么这是最简单的策略。停用不必要的节点可能会节省最大的成本。

在停止节点运行之前，您应该

• 确保要停用的节点不需要作为 MASTER 节点。应始终至少有三个节点具有 MASTER 节点角色。

• 将数据碎片从要退役的节点上移走。

2.用较小的节点取代现有节点

如果无法进一步减少节点数量（通常最低配置为 3 个），则可能需要缩小现有节点的规模。请记住，最好确保所有数据节点的 RAM 内存和磁盘大小相同，因为分片是根据每个节点的分片数量进行平衡的。

过程如下

• 向群集添加新的、较小的节点

• 将碎片迁移到远离将要退役的节点的地方

• 关闭旧节点

3.缩小节点上的磁盘大小

如果只想减少节点上的磁盘大小，而不改变群集的整体 RAM 或 CPU，那么可以减少每个节点的磁盘大小。减少 Elasticsearch 节点上的磁盘大小并非易事。

最简单的方法通常是

• 从节点迁移碎片

• 停止节点

• 在节点上挂载新数据卷，并设置适当大小

• 将旧磁盘卷中的所有数据复制到新卷中

• 分离旧卷 A

• 启动节点并将碎片迁移回节点

这就要求其他节点上有足够的容量，以便在此过程中临时存储节点上的额外碎片。在许多情况下，管理这一流程的成本可能会超过潜在的磁盘使用节余。因此，用具有所需磁盘大小的新节点完全替换该节点可能更简单（请参阅上文 "用较小节点替换现有节点"）。

在为不必要的资源付费时，显然可以通过优化资源利用率来降低成本。

磁盘大小、内存和 CPU 之间的关系

集群中磁盘容量与内存的理想比例取决于您的具体使用情况。因此，在考虑更改存储容量时，还应考虑当前的磁盘/内存/CPU 比例是否适当平衡，以及是否需要按相同比例增加/减少内存/CPU。

内存和 CPU 需求取决于索引活动量、查询次数和类型，以及搜索和汇总的数据量。这通常与群集上存储的数据量成正比，因此也应与磁盘大小相关。

磁盘容量和内存之间的比例可根据使用情况进行调整。请看这里的几个例子：

指数活动

保留

搜索活动

磁盘容量

内存

企业搜索应用程序

适度摄入原木

长

灯光

2TB

32GB

应用程序监控

大量摄入原木

短

灯光

1TB

32GB

电子商务

轻型数据索引

无限期

重型

500GB

32GB

请记住，修改节点机器配置时必须小心谨慎，因为这可能会导致节点宕机，而且需要确保分片不会开始迁移到其他已经过度紧张的节点上。

副本在 Elasticsearch 中的作用

在 Elasticsearch 中，索引是在多个主分片上分区的文档集合。每个主分片都是一个独立的 Apache Lucene 索引，索引中的文档分布在所有主分片中。为确保高可用性和数据冗余，Elasticsearch 允许每个分片拥有一个或多个副本（称为副本）。number_of_replicas 设置可控制 Elasticsearch 为索引中每个主分区创建的副本分区（拷贝）数量。默认情况下，Elasticsearch 会为每个主分片创建一个副本，但可以根据系统要求进行更改。

配置复制数

number_of_replicas 设置可在创建索引时配置，也可稍后更新。下面是创建索引时的设置方法：

在此示例中，Elasticsearch 将为my_index 索引中的每个主分区创建两个副本。

要更新现有索引的number_of_replicas 设置，可以使用_settings API：

该命令将更新my_index 索引，使每个主分区都有三个副本。

复制数设置的影响

number_of_replicas 设置对 Elasticsearch集群的性能和弹性有重大影响。以下是一些需要考虑的要点：

1. 数据冗余和可用性：通过为每个分片创建更多副本，增加number_of_replicas 可提高数据的可用性。如果某个节点发生故障，Elasticsearch 仍可从其余节点上的副本分片提供数据。

2. 搜索性能：副本分片可以为读取请求提供服务，因此拥有更多的副本可以通过在更多分片上分配负载来提高搜索性能。

3. 写性能：不过，每次写操作都必须在分片的每个副本上执行。因此，较高的number_of_replicas 会降低索引性能，因为它会增加每次写入必须执行的操作次数。

4. 存储要求：更多的副本意味着更多的存储空间。应确保群集有足够的容量来存储额外的副本。

5. 节点故障恢复能力： number_of_replicas 的设置应考虑群集中的节点数量。如果number_of_replicas 等于或大于节点数，则群集可以承受多个节点的故障而不会丢失数据。

设置复制数的最佳做法

number_of_replicas 的最佳设置取决于系统的具体要求。不过，这里有一些通用的最佳做法：

• 对于单节点集群，number_of_replicas 应设置为 0，因为没有其他节点可以容纳副本。

• 对于多节点集群，number_of_replicas 至少应设置为 1，以确保数据冗余和高可用性。

• 如果搜索性能是一个优先事项，请考虑增加number_of_replicas 。不过，请注意写入性能和存储要求之间的权衡。

• 始终确保集群有足够的容量来存储额外的副本。

在本文中，我们将讨论从索引中排除字段的原因、如何配置 Elasticsearch 以排除特定字段，以及在这样做时应遵循的一些最佳实践。

将字段排除在索引之外的原因

1. 性能： 索引文档中的所有字段会导致索引时间增加，搜索性能降低。通过排除搜索或聚合不需要的字段，可以提高 Elasticsearch 集群的整体性能。

2. 存储空间 索引字段会消耗存储空间。排除搜索或聚合不需要的字段有助于降低 Elasticsearch 集群的存储需求。

3. 索引大小： Elasticsearch 索引的大小与索引字段的数量直接相关。通过排除不必要的字段，可以最大限度地减少索引的大小，从而提高搜索和索引性能。

配置 Elasticsearch 以排除字段

要在 Elasticsearch 中排除对某个字段的索引，可以在字段映射中使用 "index "属性。如果将 "index "属性设置为 "false"，Elasticsearch 将不会为该字段建立索引，也就无法对其进行搜索或聚合。

下面是一个如何使用 Elasticsearch 映射将字段排除在索引之外的示例：

在本例中，我们将创建一个名为 "my_index "的新索引，其中包含一个名为 "field_to_exclude "的字段。通过将 "index "属性设置为 "false"，我们告诉 Elasticsearch 不要为这个字段建立索引。但该字段仍可在源文件中使用。

从索引中排除字段的最佳做法

1. 分析数据： 在将字段排除在索引之外之前，有必要对数据进行分析，了解哪些字段对于搜索和聚合是必要的。这将有助于您做出明智的决定，排除哪些字段。

2. 测试更改： 在将字段排除在索引之外时，必须对更改进行测试，以确保搜索和聚合功能仍能按预期运行。这可以帮助您避免任何意外问题或性能问题。

3. 监控性能：从索引中排除字段后，请监控 Elasticsearch 集群的性能，以确保您的更改达到了预期效果。这可以帮助您确定可能需要进行的其他优化。

4. 使用源过滤：如果需要在 Elasticsearch 中存储一个字段，但又不想让它被搜索或用于聚合，那么可以考虑使用源过滤。这样就可以将字段存储在 _source 字段中，但将其排除在索引之外。

结论

将字段排除在 Elasticsearch 索引之外有助于提高性能、降低存储成本，并最大限度地减少索引的总体大小。通过仔细分析数据并了解哪些字段对于搜索和汇总是必要的，您就可以做出明智的决定，排除哪些字段。请始终测试您的更改并监控 Elasticsearch 集群的性能，以确保您的优化达到预期效果。

方法 1：使用更新 API

Update API 允许您通过提供一段修改文档源数据的脚本来更新文档。您可以通过将字段值设为 null 来使用此 API 删除文档中的字段。以下是详细的操作步骤：

1.确定要更新的文档的索引、文档类型（如果使用 Elasticsearch 6.x 或更早版本）和文档 ID。

2.使用更新 API 并编写脚本，将字段设置为空，或者更好的做法是从源文档中删除该字段。下面的示例演示了如何从 "my_index "索引中 ID 为 "1 "的文档中删除 "field_to_delete "字段：

3.执行请求。如果成功，Elasticsearch 将返回一个响应，表明文档已被更新。

注意：此方法只能从指定文档中删除字段。该字段仍将存在于映射和索引中的其他文档中。

方法二：使用修改后的源数据进行重新索引

若要从某个索引的所有文档中删除一个字段，您可以使用 Reindex API 来创建一个包含修改后源数据的新索引。具体操作如下：

1.创建一个新索引，其设置和映射与原始索引相同。您可以使用获取索引 API 来检索原始索引的设置和映射。

2.使用重新索引 API 将原始索引中的文档复制到新索引中，同时从源中删除字段。下面的示例演示了如何从 "my_index "索引中的所有文档中删除 "field_to_delete "字段：

3.验证新索引是否包含已删除字段的正确文件。

4.如果一切正常，就可以删除原始索引，如有必要，还可以为新索引添加一个别名，其名称与原始索引名称相同。

方法三：更新映射并重新索引

如果要从映射和索引中的所有文档中删除某个字段，可以更新映射，然后重新索引文档。具体方法如下

1.创建一个新索引，设置与原始索引相同。

2.使用获取映射 API 检索原始索引的映射。

3.修改映射，删除要删除的字段。

4.使用 Put Mapping API 将修改后的映射应用到新索引。

5.如方法 2 所述，使用重新索引 API 将原始索引中的文档复制到新索引中。

6.验证新索引是否包含已删除字段的正确文件，以及映射中是否不存在该字段。

7. 如果一切正常，您可以删除原始索引，并在必要时为新的索引添加一个与原始索引同名的别名。

结论

在本文中，我们讨论了从 Elasticsearch 文档中删除字段的三种方法：使用 Update API、使用修改后的源重新索引，以及更新映射并重新索引。每种方法都有自己的用例和权衡，因此请选择最适合您要求的方法。在将更改应用到生产环境之前，请务必记住测试更改并验证结果。

Elasticsearch 中的评分机制

Elasticsearch 默认使用一种名为实用评分函数 (BM25) 的评分模型。该模型以概率信息检索理论为基础，考虑了术语频率、反向文档频率和字段长度规范化等因素。让我们简要讨论一下这些因素：

1. 术语频率 (TF)：它表示术语在文档中出现的次数。术语频率越高，说明术语与文档之间的关系越密切。

2. 反向文档频率 (IDF)：该因子用于衡量术语在整个文档集中的重要性。出现在许多文件中的术语被认为不太重要，而出现在较少文件中的术语则被认为更重要。

3. 字段长度归一化：该因子考虑了术语所在字段的长度。较短字段的权重更大，因为在较短字段中，术语被认为更重要。

使用解释 API

Elasticsearch 中的解释 API 是了解评分过程的重要工具。它详细解释了如何计算特定文件的得分。要使用解释 API，您需要向以下端点发送 GET 请求：

在请求正文中，您需要提供想要了解评分的查询。这里有一个例子：

解释 API 的回复将包括评分过程的详细分类，包括各个因素（TF、IDF 和字段长度正常化）及其对最终得分的贡献。下面是一个答复样本：

在本例中，回复显示 1.2 分是 IDF 值（2.2）和 tfNorm 值（0.5）的乘积。详细的解释有助于了解评分因素，并有助于微调搜索相关性。

结论

Elasticsearch 评分是提供相关搜索结果的一个重要方面。通过了解评分机制和使用解释 API，您可以深入了解影响搜索结果的因素，并优化搜索查询以提高相关性和性能。

• 映射定义指定了数据模式。

• 设置将设定分区大小和刷新率。

• 别名用于为索引提供备用名称。

当我们首次为文档创建索引或使用创建索引 API 创建空索引时，将使用默认设置创建索引，不包含数据模式和别名。这些默认设置在开发和测试环境中非常有效，但我们可能需要为生产环境定制索引。

在生产中使用默认映射和设置可能会导致索引和搜索性能低下。 手动实例化索引是一个繁琐耗时的过程。如果我们有一个复杂的映射模式以及自定义设置和别名，在每个环境中重新创建这样的索引尤其不切实际。

幸运的是，Elasticsearch 提供了一种工具，可以在创建索引时以索引 模板的形式自动应用预定义配置。

索引模板

通过索引模板，我们可以创建用户自定义配置的索引。索引在实例化过程中可以从这些模板中提取配置，例如设定分片和副本的数量或字段映射。模板中将定义一个名称模式和一些配置。如果索引名称与模板的命名模式相匹配，新索引将按照模板中定义的配置创建。

Elasticsearch 在 7.8 版本中升级了模板功能，增加了可组合模板。如本文所示，新版本提供了更多可重复使用的索引模板。

索引模板的类型

索引模板可分为两类：

• 索引模板（或可组合索引模板）：可组合索引模板既可以单独存在，也可以由一个或多个组件模板组成（见第二类）。

• 组件模板：组件模板本身就是一个可重复使用的模板，它定义了所需的配置。通常，组件模板应与索引模板相关联。每个组件模板都可以附加一个或多个索引模板。

如下图所示，索引模板 A 和 B 之间共享组件模板（本例中只有一个--模板 3）。索引模板可由一个或多个组件模板组成，每个组件模板可与一个或多个索引模板相关联。这两种模板都可以单独存在，但组件模板除非附加到索引模板上，否则没有任何用处。

总体思路是开发一个组件模板目录，供企业用于满足各种需求（例如，为个别环境指定各种组件模板），并通过可组合索引模板将其附加到各种索引。

如何创建可组合（索引）模板

Elasticsearch 提供了一个 _index_template 端点，用于管理索引模板。用户在此模板中提供所有必需的映射、设置和别名以及索引名称模式。让我们以创建微服务应用程序customer-order-service的模板为例，该应用程序负责订单生成逻辑。

比方说，我们的需求是为客户订单创建一个模板，该模板使用带有通配符的模式表示：*orders.该模板应具有某些映射和设置，如订单日期字段以及分片和副本编号。

任何在创建过程中与此模板匹配的索引都会继承此模板中定义的配置。例如，black_friday_orders 索引将包含 order_date 字段，分片将设置为 5，副本设置为 2。 除此之外，从该模板创建的所有索引也将继承一个别名！让我们创建一个订单模板（orders_template），其索引模式定义为 *orders，映射模式由一个日期格式为 dd-MM-yyyy 的 oder_date 字段组成。下面的代码显示了如何创建该索引模板。

在 Kibana 的 DevTools 中执行此查询时，会创建包含索引模式 *orders 以及预定义映射、设置和别名的模板。index_patterns 是一个匹配模式数组；任何与该模式匹配的索引都将导出模板配置。您可以执行以下操作来获取持久化模板，该模板应重申我们的操作：

在创建模板属性时还会定义一个优先级（正数）：每个模板都有一个优先级，这样不同模板的任何冲突更改都会通过使用该值来解决，优先级较高的值优先。下面我们将更深入地探讨模板的优先级。

使用模板创建索引

现在我们有了一个模板--创建索引的蓝图--下一步就是创建索引。当索引名称与给定模式匹配时，将自动应用模板化配置。为了证明这一点，正如下面的代码所示，让我们创建一个名为：blackfriday_orders 的全新索引：

由于索引名称（blackfriday_orders）与模板中定义的命名模式（即*orders），该索引应获取从模板派生的所有配置。让我们通过执行以下代码来检索这个新创建的索引，并检查其是否属实：

应该返回

如回复所示，blackfriday_orders 的配置已从模板继承。我们可以尝试各种指数组合，以成功继承模板配置：

但是，下列索引将不会继承配置，因为名称与模式不匹配：

需要记住的重要一点是，在本例中，从模板派生的所有索引都有相同的别名--all_orders。使用这种别名有一个好处--我们可以简单地查询这个单一的别名，而不是多个索引。

当我们为 *orders 创建模板时，任何匹配的索引都会采用模板配置。通常，出于各种原因，团队会有意无意地多创建几个模板。这意味着有时索引名称可能会匹配两个不同的模板模式！Elasticsearch 必须决定需要应用这些模板中的哪些配置。幸运的是，使用模板优先权可以解决这一难题。

如何创建组件模板

我们在本文前半部分了解了索引模板。使用内置配置创建模板有几个缺点，其中一个缺点是不能将配置导出到其他模板中。如果我们希望有类似的配置，比如与客户相关的模板（*客户），我们可能需要重新创建整个模板。这意味着，在一个典型的组织中，我们可能会创建几十个这样的系统（此外，根据环境的不同，您可能还会创建更多的系统）。

我们一直期待着可重用性，因此 Elasticsearch 在重新设计模板时考虑到了可重用性。组件模板正好符合这一要求。如果你是 DevOps 背景，很可能需要为每个环境创建预设配置的索引。与其繁琐地手动应用这些配置，不如为每个环境创建一个组件模板。

组件模板只不过是一个可重复使用的配置块，我们可以用它来组成更多的索引模板。请注意，组件模板除非与索引模板结合在一起，否则没有任何价值。它们通过 _component_template 端点公开。让我们看看这一切是如何组合在一起的。

索引模板中的设置

让我们提取之前在索引模板中定义的设置，并从中创建一个组件模板。settings_component_template 预计有五个主分区，每个主分区有两个副本。正如下面的代码列表所示，第一步是用此配置声明并执行一个组件模板。

如上面的代码所示，我们使用 _component_template 端点创建组件模板。请求正文在模板对象中保存模板信息。settings_component_template 现在可在索引模板的其他地方使用。一个显著的区别是，这个模板没有定义任何索引模式；它只是一个为我们配置一些属性的代码块。

映射模板

同样，让我们创建另一个模板。这次，让我们提取之前在独立索引模板中定义的映射模式。下面的代码显示了脚本：

别名模板

按照同样的流程，我们还可以在组件模板中加入别名--两个别名（all_orders 和 sales_orders）：

可组合索引模板

现在我们有了这三个组件模板，下一步就是将它们投入使用。我们可以让索引模板使用它，比如 christmas_orders：

composed_of 标签是组成该模板的所有组件模板的集合。在这种情况下，我们要选择设置、映射和别名组件模板。我们还将提高优先级，使该模板优先于其他模板。模板就绪后，任何与 *orders 模式匹配的索引都将继承这三个组件模板的配置。

尽管如此，如果我们希望创建一个新模板，例如客户模板，只使用一个现有模板（settings_component_template）和一个新创建的别名模板（aliases_component_template，见下文），我们可以通过以下方法实现：

索引模板是这样的

您是否发现 settings_component_template 被（重新）用于两个不同的模板？这就是组件模板的力量。

索引模板的优先级

开发人员有可能在没有查看现有库存的情况下创建多个索引模板。重要的是要为每个模板设置优先级，以便使用优先级较高的模板。例如，在下面的代码片段中，my_orders_template_1 会覆盖 my_orders_template_2：

如果有多个模板与正在创建的索引相匹配，Elasticsearch 会应用所有匹配模板中的所有配置，但会覆盖优先级较高的配置。

模板优先

最后，您可能想知道模板的优先级--组件模板中定义的配置是否优先于主索引模板本身定义的配置？还是相反？嗯，是有一些规则的：

• 使用显式配置创建的索引优先于所有配置--这意味着如果使用显式配置创建索引，不要指望它们会被模板覆盖。

• 传统模板（7.8 版之前创建的模板）的优先级低于可组合模板。

总结

• 索引包含映射、设置和别名：映射定义字段模式，设置设置索引参数（如分片数和副本数），别名为索引提供备用名称。

• 通过模板，我们可以创建具有预定义配置的索引。使用与特定模板中定义的索引模式相匹配的名称命名索引，将自动根据模板配置该索引。

• Elasticsearch 在 7.8 版中引入了可组合索引模板。可组合的索引模板可实现模板的模块化和版本化。

• 可组合模板由一个或多个组件模板组成。

• 索引模板也可以定义自己的配置。

• 组件模板是一种可重复使用的模板，具有预定义的配置，就像可组合索引模板一样。

• 但是，组件模板应该是索引模板的一部分；如果没有 "组成 "索引模板，组件模板就毫无用处。

• 组件模板中没有定义索引模式，这也是它们 "有望 "成为索引模板一部分的另一个原因。

• 每个模板都有一个优先级--一个正数。数字越大，应用该模板的优先级就越高。

通过两个字段执行搜索的高级技术

1.多匹配查询

多匹配查询允许您在多个字段中搜索单个查询字符串。当您要查找两个字段中任何一个包含给定查询字符串的文档时，这种方法非常有用。下面是一个多重匹配查询的示例，在 "标题 "或 "描述 "字段中搜索术语 "示例"：

2.布尔查询

bool 查询允许您使用布尔逻辑组合多个查询。您可以使用 "should "子句搜索两个字段中任何一个与查询匹配的文档。下面是一个在 "标题 "和 "描述 "字段中搜索术语 "示例 "的 bool 查询示例：

3.查询时间字段增强

有时，您可能希望在搜索过程中更重视一个字段而不是另一个字段。您可以在查询时对字段应用提升因子来实现这一点。提升值越高，该字段的权重就越大，从而更有可能影响最终搜索得分。下面是一个多匹配查询的示例，在 "标题 "字段中应用了提升因子：

在这个例子中，"标题 "字段的提升系数为 3，因此在决定搜索得分时，它比 "描述 "字段重要三倍。

4.组合使用不同提升因子的查询

您还可以使用 bool 查询将具有不同提升因子的多个查询组合起来。这样，您就可以微调搜索结果中每个字段的重要性。下面是一个 bool 查询的示例，"标题 "和 "描述 "字段应用了不同的提升因子：

在这个例子中，"标题 "字段的提升因子为 3，而 "描述 "字段的提升因子为 1。

结论

在 Elasticsearch 中，可以使用多匹配查询、布尔查询和查询时字段增强等高级技术实现两个字段的搜索。通过结合这些技术，您可以为用户创建更准确、更相关的搜索结果。尝试使用不同的查询组合和提升因素，为您的特定使用情况找到最佳搜索配置。

从 7.11 版开始，Elasticsearch 默认会根据节点的角色和总内存自动设置 JVM 堆大小。建议大多数生产环境使用默认大小。不过，如果要手动设置 JVM 堆大小，一般来说，应将 -Xms 和 -Xmx 设置为相同的值，即总可用内存的 50% ，最大（约）为 31GB。

堆大小越大，节点用于索引和搜索操作的内存就越大。不过，节点也需要内存进行缓存，因此使用 50% 可以在两者之间保持健康的平衡。出于同样的原因，在生产中应避免在 Elasticsearch 的同一节点上使用其他内存密集型进程。

通常情况下，堆使用量会呈现锯齿状，在最大堆使用量的 30 到 70% 之间摇摆。这是因为 JVM 会稳步增加堆使用百分比，直到垃圾回收过程再次释放内存。当垃圾回收进程跟不上时，就会出现堆使用率高的情况。堆使用率高的一个指标是垃圾回收无法将堆使用率降低到 30% 左右。

在上图中，您可以看到 JVM 堆的正常锯齿形。

你还会看到有两种类型的垃圾回收，即年轻的 GC 和年老的 GC。

在健康的 JVM 中，垃圾回收最好能满足以下条件：

• 年轻 GC 的处理速度很快（50 毫秒内）。

• 年轻的 GC 执行频率不高（约 10 秒）。

• 旧 GC 处理速度很快（1 秒内）。

• 旧 GC 执行频率不高（每 10 分钟或更长时间执行一次）。

如何解决堆内存使用率过高或 JVM 性能不佳的问题

堆内存使用量增加有多种原因：

过度包庇

请点击此处查看有关过度储藏的文件。

聚合规模大

为了避免聚合大小过大，请尽量减少查询中聚合桶的数量（大小）。

您可以使用慢查询日志（慢日志），并通过以下方式在特定索引上实施。

需要很长时间才能返回结果的查询可能是资源密集型查询。

批量索引大小过大

如果您发送的请求很大，那么这可能是堆消耗大的原因。尝试减少批量索引请求的大小。

制图问题

特别是，如果您使用 "fielddata: true"，那么这将成为 JVM 堆的主要用户。

堆大小设置错误

堆大小可以通过以下方式手动定义：

设置环境变量

编辑 Elasticsearch 配置目录中的 jvm.options 文件：

环境变量设置优先于文件设置。

必须重新启动节点才能将设置考虑在内。

JVM 新比率设置错误

通常无需设置，因为 Elasticsearch 默认设置此值。该参数定义 JVM 中 "新一代 "和 "老一代 "对象的可用空间比例。

如果发现旧 GC 变得非常频繁，可以尝试在 Elasticsearch 配置目录下的 jvm.options 文件中专门设置该值。

在大型 Elasticsearch 集群中，管理堆大小使用和 JVM 垃圾收集的最佳实践是什么？

在大型 Elasticsearch 集群中，管理堆大小使用和 JVM 垃圾收集的最佳做法是确保堆大小最多设置为可用 RAM 的 50% ，并根据具体使用情况优化 JVM 垃圾收集设置。必须监控堆大小和垃圾回收指标，以确保群集以最佳状态运行。具体来说，监控 JVM 堆大小、垃圾收集时间和垃圾收集暂停非常重要。此外，监控垃圾回收周期的次数和垃圾回收所花费的时间也很重要。通过监控这些指标，可以发现堆大小或垃圾回收设置方面的任何潜在问题，并在必要时采取纠正措施。

与 _reindex API 相比，_split API 通常是更快的方法。在进行这两项操作前， 必须停止 索引 ，否则源索引和目标索引的文档计数将不同。

方法 1 - 使用拆分 API

拆分 API 用于通过复制设置和映射现有索引来创建一个新索引，其中包含所需的主分片数量。可在创建过程中设置所需的主分区数量。在实施拆分 API 之前，应检查以下设置：

1. 源索引必须是只读的。这意味着需要停止索引进程。

2. 目标索引中主分区的数量必须是源索引中主分区数量的倍数。例如，如果源索引有 5 个主分区，那么目标索引的主分区可以设置为 10、15、20，以此类推。

注意：如果只需要更改主分区编号，则首选拆分 API，因为它比 Reindex API 快得多。

实施拆分应用程序接口

创建测试索引：

源索引必须是只读的，才能进行拆分：

设置和映射将自动从源索引中复制：

您可以通过以下方式检查进度：

由于设置和映射是从源索引中复制的，因此目标索引是只读的。让我们启用目标索引的写操作：

删除原始索引前，检查源索引和目标索引的 docs.count：

索引名称和别名不能相同。您需要删除源索引，并将源索引名称作为别名添加到目标索引中：

将test_split_source别名添加到test_split_target索引后，应使用

方法 2 - 使用重新索引 API

通过使用 Reindex API 创建新索引，可以给出任意数量的主分区计数。在创建具有预定主分片数量的新索引后，源索引中的所有数据都可以重新索引到这个新索引。

除了拆分 API 功能外，还可以使用 reindex AP 中的 ingest_pipeline 对数据进行操作。通过摄取管道，只有符合过滤器的指定字段才会被索引到使用查询的目标索引中。数据内容可通过简单的脚本进行更改，多个索引可合并为一个索引。

实施重新索引 API

创建测试重新索引：

从源索引中复制设置和映射：

创建包含设置、映射和所需分片数的目标索引：

*注意：设置 number_of_replicas：0 和 refresh_interval: -1 会提高重新索引的速度。

启动重新索引程序。设置 requests_per_second=-1 和 slices=auto 可以调整重新索引的速度。

运行 reindex API 时，您将看到 task_id。复制并使用 _tasks API 进行检查：

重新索引完成后更新设置：

删除原始索引前，请检查源索引和目标索引的 docs.count，它们应该是一样的：

索引名称和别名不能相同。删除源索引，并将源索引名称作为别名添加到目标索引中：

将 test_split_source 别名添加到 test_split_target 索引后，使用

总结

如果要增加现有索引的主分区数，则需要重新创建新索引的设置和映射。主要有两种方法：重新索引 API 和拆分 API。在使用这两种方法之前，必须先停止主动索引。

这种方法的缺点是需要一些重复的硬件，在试图顺利传输和同步所有数据时可能会造成困难。

如果需要将应用程序从一个数据中心迁移到另一个数据中心，也可能需要执行类似的程序。

本文将讨论并详细介绍在 Elasticsearch 集群之间传输数据的三种方法。

如何在 Elasticsearch 集群之间迁移数据？

在 Elasticsearch 集群之间传输数据有 3 种方法：

1. 从远程群集重新编排索引

2. 使用快照传输数据

3. 使用 Logstash 传输数据

使用快照通常是最快速、最可靠的数据传输方法。不过，请记住，您只能将快照还原到相同或更高版本的群集上，而不能还原到相差一个主版本以上的群集上。这意味着您可以将 6.x 快照还原到 7.x 群集上，但不能还原到 8.x 群集上。

如果需要增加一个以上的主要版本，则需要重新索引或使用 Logstash。

现在，让我们分别详细了解在 Elasticsearch 集群之间传输数据的三个选项。

1.从远程群集重新索引数据

在开始重新索引之前，请记住您需要为新群集上的所有索引设置适当的映射。为此，您必须使用适当的映射直接创建索引，或者使用索引模板。

从远程重新索引 - 需要配置

要从远程重新索引，应将以下配置添加到接收数据的群集的 elasticseearch.yml 文件中，在 Linux 系统中，该文件通常位于此处：/etc/elasticsearch/elasticsearch.yml。要添加的配置如下：

如果使用 SSL，则应将 CA 证书添加到每个节点，并在 elasticsearch.yml 中每个节点的命令中包含以下内容：

或者，也可以在所有 Elasticsearch 节点上添加下面一行，以禁用 SSL 验证。不过，由于这种方法不如前一种方法安全，因此不太推荐使用：

您需要在每个节点上进行这些修改，并进行滚动重启。有关如何操作的详细信息，请参阅我们的指南。

重编索引命令

在 elasticsearch.yml 文件中定义远程主机，并在必要时添加 SSL 证书后，就可以使用下面的命令开始重新索引数据了：

在此过程中，您可能会遇到超时错误，因此最好为超时设置宽松的值，而不是依赖默认值。

现在，让我们来看看从远程重新索引时可能会遇到的其他一些常见错误。

从远程重新索引时的常见错误

1.重新索引未列入白名单

如果遇到此错误，则表明您没有按照上文所述在 Elasticsearch 中定义远程主机 IP 地址或节点名称 DNS，或者忘记重启 Elasticsearch 服务。

要解决 Elasticsearch 集群的问题，需要将远程主机添加到所有 Elasticsearch 节点，并重新启动 Elasticsearch 服务。

2.SSL 握手异常

这个错误说明，你忘记按上文所述在 elasticsearch.yml 中添加 reindex.ssl.certificate_authorities。加进去：

2.使用快照传输数据

请记住，如上所述，您只能将快照还原到相同或更高版本的群集上，而不能还原到相差一个主要版本以上的群集上。

如果需要增加一个以上的主要版本，则需要重新索引或使用 Logstash。

通过快照传输数据需要以下步骤：

步骤 1.将版本库插件添加到第一个 Elasticsearch 群集--为了通过快照在群集间传输数据，需要确保新旧群集都能访问版本库。AWS、Google 和 Azure 等云存储库通常是理想的选择。要拍摄快照，请参阅我们的指南，并按照其中描述的步骤操作。

步骤 2.重启 Elasticsearch 服务（滚动重启）。

第 3 步为第一个 Elasticsearch 集群创建一个存储库。

步骤 4- 将版本库插件添加到第二个 Elasticsearch 集群。

第 5 步--向第二个 Elasticsearch 集群添加只读版本库--您需要重复创建第一个 Elasticsearch 集群的相同步骤来添加版本库。

重要提示：将第二个 Elasticsearch 集群连接到同一个 AWS S3 存储库时，应将存储库定义为只读存储库：

这一点很重要，因为你要防止在同一个快照存储库中出现混合 Elasticsearch 版本的风险。

第 6 步 - 将数据还原到第二个 Elasticsearch 群集 - 采取上述步骤后，您可以还原数据并将其传输到新的群集。请按照本文所述步骤将数据恢复到新群集。

3.使用 Logstash 传输数据

在开始使用 logstash 传输数据之前，请记住您需要为新群集上的所有索引设置适当的映射。为此，您需要直接创建索引或使用索引模板。

要在两个 Elasticsearch 集群之间传输数据，可以设置一个临时 Logstash 服务器，并用它在两个集群之间传输数据。对于小型集群，2GB 内存的实例就足够了。对于较大的集群，可以使用配备 8GB 内存的四核 CPU。

有关安装 Logstash 的指导，请参阅此处。

从一个群集向另一个群集传输数据的 Logstash 配置

将单个索引从群集 A 复制到群集 B 的基本配置是

对于安全的 elasticsearch，可以使用下面的配置：

索引元数据

上述命令将写入一个命名索引。如果要传输多个索引并保留索引名称，则需要在 Logstash 输出中添加以下一行：

此外，如果您想保留文件的原始 ID，则需要添加：

请注意，设置文档 ID 会大大降低数据传输的速度，因此只有在必要时才保留原始 ID。

同步更新

上述所有方法都需要相对较长的时间，您可能会发现在等待过程完成时，原始群集中的数据已被更新。

有多种策略可以同步数据传输过程中可能出现的任何更新，在开始这一过程之前，你应该考虑一下这些问题。您尤其需要考虑

• 您有什么方法来识别自数据传输过程开始以来已更新/添加的任何数据（例如，数据中的 "最后更新时间 "字段）？

• 您可以使用什么方法来传输最后一个数据？

• 是否存在记录重复的风险？通常会有，除非您使用的方法在重新索引时将文档 ID 设置为已知值）。

下文介绍了实现同步更新的不同方法。

1.使用排队系统

有些摄取/更新系统使用队列，可以 "重放 "过去 x 天内收到的数据修改。这可以为同步任何更改提供一种手段。

2.从远程重新索引

对 "last_update_time"> x 天前的所有项目重复重新索引过程。您可以在重新索引请求中添加一个 "查询 "参数。

3.Logstash

在 Logstash 输入中，可以添加一个查询来过滤所有 "last_update_time"> x 天前的项目。不过，除非设置了 document_id，否则这一过程会导致非时间序列数据出现重复。

4.快照

不可能只恢复索引的一部分，因此必须使用上述其他数据传输方法之一（或脚本）来更新数据传输过程后发生的任何更改。

不过，快照恢复比重新索引/Logstash 快得多，因此可以在传输快照时短暂暂停更新，以完全避免问题。