Elasticsearch 8.X reindex 源码剖析及提速指南

1、reindex 源码在线地址

为方便大家验证，这里给出 reindex github 源码地址。

​​https://github.com/elastic/elasticsearch/blob/001fcfb931454d760dbccff9f4d1b8d113f8708c/server/src/main/java/org/elasticsearch/index/reindex/ReindexRequest.java​​

reindex 常见问题：

2、reindex 源码本质

​​reindex​​ 操作的本质是从一个或多个源索引中读取文档，并将这些文档索引到一个目标索引中，可能还涉及对文档的某些转换。

以下是从源码中得出的 reindex 操作的关键点：

2.1 源和目标

ReindexRequest 定义了源索引（从中读取文档）和目标索引（将文档索引到其中）。

2.2 查询和过滤

可以为源索引定义一个查询（使用 setSourceQuery 方法），以确定哪些文档应该被重新索引。

也就是可以迁移满足给定检索语句的数据。

2.3 文档转换

如果提供了一个脚本，它可以在文档从源索引移动到目标索引之前对文档进行修改或转换。

2.4 批量处理

文档是批量从源索引读取并批量索引到目标索引的。

批处理的大小可以通过 setSourceBatchSize 方法进行调整。

这个值究竟可以多大，源码并没有明示。但是如下规则咱们得知道！

• 设置一个非常大的滚动大小仍然可能会对集群造成压力，因为它会增加内存使用和集群节点之间的数据传输。
• 因此，选择一个合适的滚动大小是很重要的，以确保在取得良好性能的同时，不会过度压迫集群。

2.5 远程源索引

reindex 不仅可以在当前 Elasticsearch 集群中的索引之间移动文档（如图 1 所示），还可以从一个远程的 Elasticsearch 集群读取文档（如图 2 所示）。

这是通过 RemoteInfo 类实现的，它包含了远程集群的所有必要信息。

包含信息如下：

• 远程集群的地址（可能是一个 URL 或 URI）
• 认证信息（例如用户名和密码）
• 请求头（为远程请求定制的特定头信息）
• 连接超时和套接字超时
• 其他与远程集群交互所需的配置信息

2.6 验证

在执行 reindex 操作之前，会进行一系列的验证检查（使用 validate 方法），以确保请求是合法的。

2.7 序列化/反序列化

ReindexRequest 类包含了将请求序列化到网络传输格式并从该格式反序列化的方法。

这允许 Elasticsearch 节点之间有效地通信并执行 reindex 请求。

2.8 输出

ReindexRequest 可以被转化为一个描述性的字符串（使用 toString 方法）或一个XContent格式（通常是JSON，使用 toXContent 方法），这对于日志记录和调试非常有用。

总结起来，reindex 操作的本质是从源索引读取文档、可能进行一些转换，然后将这些文档索引到目标索引。

此操作可以在当前集群的索引之间进行，也可以跨集群进行。这是一种强大的方式，可以用于数据迁移、索引重组、数据转换等任务。

3、reindex 加速

重新索引操作的速度受多个因素的影响， 如果希望加速 reindex 操作，以下是一些建议：

3.1 调整批次大小：

ReindexRequest 有一个 setSourceBatchSize 方法，允许我们设置每批处理的文档数量。

  /**

     * Sets the scroll size for setting how many documents are to be processed in one batch during reindex

     */

    public ReindexRequest setSourceBatchSize(int size) {

        this.getSearchRequest().source().size(size);

        return this;

    }

增加批次大小可能会提高性能，但请注意，太大的批次可能会导致内存问题或请求超时。

3.2  slice 并行处理

slice 在 Elasticsearch 的重索引操作中确实可以帮助提速。slice 是一种将大型查询分解为多个较小部分并并行执行它们的方法，从而使整体操作更快。

在 ReindexRequest 类中，我们可以看到方法 forSlice(TaskId slicingTask, SearchRequest slice, int totalSlices)，它允许我们为给定的滚动请求创建一个子切片。

如何实操?

关于设置切片数量: 当我们执行重索引操作时，可以设置 slices 参数来指定我们想要的切片数。

例如，如果我们选择 slices: 5，那么 Elasticsearch 将尝试将查询拆分成5个子查询，并尽可能均匀地分布文档。

并行执行提速

使用切片后，每个切片都可以在单独的线程或节点上并行执行。这样，如果我们有多个节点或足够的资源，切片可以显著提高重索引的速度。

实际命令:

在 Elasticsearch REST API 中，进行带切片的重索引操作的命令可能如下：

POST _reindex
{
  "source": {
    "index": "old_index",
    "size": 1000,
    "slice": {
      "id": 0,
      "max": 5
    }
  },
  "dest": {
    "index": "new_index"
  }
}

在上面的命令中，我们将原始索引分成了5个切片，并使用 id 参数来指定当前切片的编号。

要并行执行所有切片，需要为每个切片编号运行此命令（在此例中，从0到4）。

slice 注意事项

虽然切片可以加速操作，但它也会增加集群的负担，因为每个切片都会创建自己的滚动上下文。确保的 Elasticsearch 集群有足够的资源来处理我们选择的切片数量。

切片操作的最佳数量取决于数据、查询和集群配置。可能需要进行一些性能测验来找到最佳的切片数量。

总的来说，slice 可以显著提高重索引操作的速度（一会我们验证一把，用事实证明），但需要确保正确使用它，以便在提高速度的同时不过度负担集群。

3.3 优化查询

如果我们在 reindex 请求中使用了查询来筛选文档，确保该查询是优化的。避免使用复杂或低效的查询。比如：复杂嵌套查询、​​wildcard​​模糊查询等都尽量避免。

3.4 增加硬件资源

增加 Elasticsearch节点的 CPU、内存和I/O能力可以提高 reindex 的速度。

如果我们正在从远程集群进行重新索引，确保两个集群都有足够的资源。

这种针对数据量极大的情况。

3.5 优化索引设置：

在目标索引上临时禁用一些功能，如刷新和副本。完成 reindex 后，再启用它们：

设置 ​​index.number_of_replicas​​​ 为 0 以​​禁用副本​​。

设置 ​​index.refresh_interval​​​ 为 -1 以​​禁用刷新​​。

3.6 使用 Ingest Pipelines

如果我们正在在 reindex 操作中使用脚本对文档进行转换，考虑使用 ​​Ingest Pipelines​​，这可能比脚本更高效。

3.7 网络优化

如果从远程集群重新索引，确保网络连接是高速、低延迟的。限制其他网络密集型操作的使用，以确保 reindex 请求可以充分利用带宽。

这属于边缘化建议，一般常识属于必知必会的。

3.8 限制其他操作

尝试在集群的非高峰时段执行 reindex 操作，并限制执行其他资源密集型操作，如大型搜索或其他索引操作（如​​段合并​​等）。

3.9 检查插件和外部脚本

确保没有任何插件或外部脚本影响 ​​reindex ​​操作的性能。

3.10监控并调优

使用Elasticsearch的监控工具，如 Elastic Stack 的监控功能，来监控 reindex 操作的性能。这可以帮助我们识别瓶颈并进行相应的调优。

考虑到这些建议，最好在生产环境中进行测试，以找到最佳的设置和优化策略。

4、reindex 借助 slice 加速验证

4.1准备工作

• 条件1——选择或创建一个足够大的数据。

需要一个大型索引，这样性能差异才会明显。小数据集可能不会显示出明显的差异。

• 条件2——确保集群健康。

确保 Elasticsearch 集群在开始测试之前是健康的，所有节点都是在线的，没有挂起的任务。

• 条件3——关闭其他大型操作。

确保集群上没有其他大型查询或索引操作在运行，以免影响性能测试结果。

4.2 不使用 slice 的重索引

• 记录开始时间。
• 使用 _reindex API 执行重索引操作，但不使用 slice。
• 记录完成时间。
• 计算持续时间。

## 第一种：直接迁移。

  "took": 4005,

POST _reindex
{
  "source": {
    "index": "image_index"
  },
  "dest": {
    "index": "image_index_direct"
  }
}

GET image_index_direct/_count

4.3 使用 slice 的重索引

• 选择一个切片数量：例如，如果有5个数据节点，我们可能想尝试5个切片。
• 记录开始时间。
• 使用 _reindex API 执行重索引操作，为每个切片创建一个单独的请求。可以使用并发工具（如 parallel 命令或脚本）来并行运行所有的请求。
• 记录所有切片完成的时间。
• 计算总持续时间。

## 第二种，加了并行处理！
 
POST _reindex
{
  "source": {
    "index": "image_index",
    "slice": {
      "id": 0,
      "max": 5
    }
  },
  "dest": {
    "index": "image_index_slice"
  }
}

4.4 比较

比较两次重索引的总时间。理论上，使用 slice 的版本应该更快，尤其是在有多个节点和大量数据的集群中。

数据量 16MB，上万条数据迁移结果对比：

数据量 112MB，15万条长津湖影评数据迁移结果对比：

综上两种数量级不同数据的 reindex 结果可以看出，加了 slice 能提速 3-4倍！

更多节点规模集群和大规模数据，期待大家留言反馈结果。

5、小结

有了方案，更多的付诸实践，拿出结果才更有谁服力！

加油！

文章转载自公众号：铭毅天下Elasticsearch