系列回顾与引言

在我们的 INFINI 本地环境搭建系列博客中：

1. 第一篇《搭建持久化的 INFINI Console 与 Easysearch 容器环境》，我们深入探讨了如何使用基础的 docker run 命令，一步步构建起 Console 和 Easysearch 服务，并重点解决了数据持久化的问题。
2. 第二篇《使用 Docker Compose 简化 INFINI Console 与 Easysearch 环境搭建》，我们学习了如何利用 Docker Compose 的声明式配置，将多容器应用的定义和管理变得更加简洁高效。

虽然 Docker Compose 已经极大地提升了便利性，但在实际的开发和测试流程中，我们可能还需要处理版本选择、初始配置复制、多节点配置、指标采集开启等更细致的需求。为了进一步封装这些复杂性，提供真正的一键式体验，我们精心打造了一个强大的 Shell 脚本 start-local 。

本篇文章将带你领略 start-local 的魅力，看看它是如何将 Console 和 Easysearch (本文仍以 Console 1.29.6 和 Easysearch 1.13.0 为例) 的本地环境搭建与管理提升到一个全新的便捷高度——只需一行命令，即可拥有一个功能完备、数据持久的本地 INFINI Console 运行环境。

start-local：您的 INFINI Console 本地环境瑞士军刀

start-local 脚本（灵感来源于 elastic/start-local）集成了环境搭建的诸多最佳实践，旨在提供极致的易用性。它在后台仍然依赖 Docker 和 Docker Compose，但为用户屏蔽了底层的复杂配置细节。

核心功能：

• 智能版本管理：自动获取 INFINI Console 和 Easysearch 的最新稳定版（或你指定的版本）作为默认镜像标签。
• 动态配置生成：根据用户提供的命令行选项（如节点数、密码、版本等）自动生成 .env 和 docker-compose.yml 文件。
• 初始配置自动处理：在首次启动或本地配置目录不存在时，自动从 Docker 镜像中提取并设置初始配置文件。
• 一键式生命周期管理：通过简单的命令 (up, down, logs, clean) 管理整个应用的启动、停止、日志查看和彻底清理。
• 持久化内置：默认将所有关键数据（配置、索引数据、日志）持久化到本地的 ./startlocal 目录（可配置）。
• 集成 Agent 指标采集：通过 --metrics-agent 选项，轻松启用 Easysearch 的指标收集并自动配置其指向 INFINI Console。
• 跨平台设计：主要针对 Linux 和 macOS 环境。

如何获取和使用 start-local

获取和执行 start-local 最便捷的方式是通过 curl 将脚本内容直接通过管道传递给 sh 执行：

# 启动默认配置 (Console + 1 个 Easysearch 节点)
curl -fsSL http://get.infini.cloud/start-local | sh -s

# 想要更丰富的体验？试试这个：
# 启动 3 个 Easysearch 节点，设置密码，并开启 Agent 指标采集
curl -fsSL http://get.infini.cloud/start-local | sh -s -- up --nodes 3 --password "MyDevPass123." --metrics-agent

(请将 http://get.infini.cloud/start-local 替换为脚本的实际官方获取地址)

sh -s -- 部分确保脚本从标准输入读取，并且后续参数能正确传递给脚本。

脚本执行后，所有操作文件和持久化数据都会在当前目录下的 ./startlocal (默认) 子目录中创建和管理。

start-local 命令和选项概览

通过 help 命令可以查看所有支持的功能：

curl -fsSL http://get.infini.cloud/start-local | sh -s -- help

以下是一些最常用的命令和选项：

命令 (COMMAND):

• up: 核心命令。创建并启动定义的服务。自动处理初始配置。
• down: 停止服务，移除容器、网络和相关匿名卷。本地持久化数据不受影响。
• logs [服务名...]: 实时查看指定服务或所有服务的日志。
• clean: 彻底清理。执行 down 后，删除整个工作目录 (./startlocal 及其所有内容)。
• help: 显示帮助信息。

常用选项 (OPTIONS) (主要用于 up 命令):

• -cv TAG, --console-version TAG: 指定 Console 镜像版本 (例如 1.29.6)。
• -ev TAG, --easysearch-version TAG: 指定 Easysearch 镜像版本 (例如 1.13.0)。
• -n N, --nodes N: Easysearch 节点数量 (默认 1)。
• -p PASSWORD, --password PASSWORD: Easysearch admin 用户初始密码 (默认 ShouldChangeme123.)。
• --services s1[,s2,...]: 指定要启动的服务 (可选值: console, easysearch)。如果未指定，默认启动两者。
• --metrics-agent: 启用 Easysearch 指标收集代理。
• -wd PATH, --work-dir PATH: 自定义工作目录，替代默认的 ./startlocal。

实际操作示例

让我们通过几个示例来感受 start-local 的便捷：

1. 启动一个标准的开发环境 (Console + 1 个 Easysearch 节点，开启指标)

curl -fsSL http://get.infini.cloud/start-local | sh -s

脚本会自动完成所有后台工作：检查依赖、确定版本、创建工作目录、生成配置文件、复制初始配置、生成 docker-compose.yml，最后启动服务并打印访问地址。

2. 启动一个 3 节点的 Easysearch 集群，并指定版本和密码

curl -fsSL http://get.infini.cloud/start-local | sh -s -- up \
--nodes 3 \
--password "ComplexP@ssw0rd." \
--console-version 1.29.6 \
--easysearch-version 1.13.0 \
--services easysearch,console

脚本会智能处理多节点配置和持久化目录结构。

3. 查看所有服务的日志

curl -fsSL http://get.infini.cloud/start-local | sh -s -- logs

4. 停止运行环境（慎重操作）

curl -fsSL http://get.infini.cloud/start-local | sh -s -- down

这将停止运行的所有容器。

4. 删除运行环境（慎重操作）

curl -fsSL http://get.infini.cloud/start-local | sh -s -- clean

这将移除所有相关的 Docker 资源以及本地的 ./startlocal 目录。

持久化：数据安全无忧

start-local 脚本的核心设计之一就是确保数据的持久化。所有重要的配置、数据和日志都会映射到宿主机的 ./startlocal (或你通过 -wd 指定的) 目录下的结构化子目录中：

• Console: ./startlocal/console/{config,data,logs}/
• Easysearch (单节点): ./startlocal/easysearch/{config,data,logs}/
• Easysearch (多节点): ./startlocal/easysearch/node-X/{config,data,logs}/

这意味着你可以随时 down 和 up 你的环境，而不用担心丢失任何工作。

访问服务

启动成功后，脚本会打印出访问地址：

• INFINI Console: http://localhost:9000 (默认主机端口)
• INFINI Easysearch: https://localhost:9200 (默认主机端口，用户 admin，密码为你设置的或默认值)

总结：从复杂到简单，专注核心价值

从繁琐的 docker run 命令，到结构化的 docker-compose.yml，再到如今便捷的 start-local 脚本，我们一步步简化了 INFINI 本地环境的搭建和管理过程。start-local 将所有底层的复杂性封装起来，让你能够通过一行命令就拥有一个功能齐全、数据持久的本地环境，从而更专注于应用本身的功能测试、开发和学习。

这正是良好工具的价值所在——让复杂的事情变简单，让我们能更高效地创造。

希望这个 start-local 脚本能成为你日常工作中得力的助手！如果你有任何建议或发现问题，欢迎通过项目仓库反馈。

关于 INFINI Console

INFINI Console 是一款开源的非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管，企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。INFINI Console 还可以对集群内的索引及数据进行操作管理，可以配置灵活的告警规则，可以指定统一的安全策略，可以查看各个维度的日志和审计信息，真正实现企业级的搜索服务平台化建设和运营。

官网文档：https://docs.infinilabs.com/console/main/
开源地址：https://github.com/infinilabs/console

作者：罗厚付，极限科技（INFINI Labs）云上产品设计与研发负责人，拥有多年安全风控及大数据系统架构经验，主导过多个核心产品的设计与落地，日常负责运维超大规模 ES 集群（800+节点/1PB+数据）。
原文：http://localhost:1313/blog/2025/console-easysearch-start-local/

前言回顾

在上一篇文章《搭建持久化的 INFINI Console 与 Easysearch 容器环境》中，我们详细介绍了如何使用基础的 docker run 命令，手动启动和配置 INFINI Console (1.29.6) 和 INFINI Easysearch (1.13.0) 容器，并实现了关键数据的持久化，解决了重启后配置丢失的问题。

手动操作虽然能让我们深入理解 Docker 的核心机制，但在管理多个容器、网络和卷时，命令会变得冗长且容易出错。这时，Docker Compose 就派上了用场。它允许我们使用一个 YAML 文件来定义和运行多容器 Docker 应用程序。

本篇文章将演示如何将上一篇的手动步骤转换为使用 Docker Compose，让你更轻松地管理和维护这套本地开发测试环境。

Docker Compose 的优势

使用 Docker Compose 带来了诸多好处：

• 声明式配置：在一个 docker-compose.yml 文件中定义所有服务、网络和卷，清晰明了。
• 一键式管理：使用简单的命令（如 docker compose up, docker compose down）即可启动、停止和重建整个应用环境。
• 简化网络和服务连接：Compose 会自动处理服务间的网络设置和依赖关系。
• 易于共享和版本控制：docker-compose.yml 文件可以轻松地与团队共享并通过版本控制系统（如 Git）进行管理。

准备工作

与上一篇类似，你需要：

• 操作系统: macOS (本文示例)
• Docker 环境: OrbStack (https://orbstack.dev/) 或 Docker Desktop for Mac。
• 确保 Docker Compose V2 (docker compose) 或 V1 (docker-compose) 已安装并可用。

查看 docker compose 版本

docker compose version
Docker Compose version v2.24.5

步骤一：项目目录结构

我们将继续使用上一篇文章中创建的目录结构。如果你还没有创建，或者想重新开始，可以在你的项目根目录（例如 ~/infini_compose_lab）下创建如下结构：

# 1. 创建项目根目录
mkdir -p ~/infini_compose_lab
cd ~/infini_compose_lab

# 2. 为 Console 和 Easysearch 创建持久化子目录
# 这些目录将用于存储配置、数据和日志
mkdir -p console/config console/data console/logs
mkdir -p easysearch/config easysearch/data easysearch/logs

步骤二：提取初始配置文件

这一步与上一篇完全相同。你在首次启动时使用从镜像中提取的默认配置，请执行以下操作。如果这些目录中已存在配置文件（例如从上一篇博客的操作中保留下来的），Docker Compose 在挂载时会直接使用它们。

1. INFINI Console (1.29.6) 初始配置 (容器内配置路径: /config)

# 确保在 ~/infini_compose_lab 目录下
docker pull infinilabs/console:1.29.6
docker run --rm \
-v $PWD/console/config:/temp_host_config \
infinilabs/console:1.29.6 \
sh -c "cp -a /config/. /temp_host_config/ && chmod -R ugo+rw /temp_host_config/"

2. INFINI Easysearch (1.13.0) 初始配置 (容器内配置路径: /app/easysearch/config，初始密码: INFINILabs01)

重要提示：请务必为 Easysearch 设置安全的密码。

# 确保在 ~/infini_compose_lab 目录下
docker pull infinilabs/easysearch:1.13.0
docker run --rm \
-e EASYSEARCH_INITIAL_ADMIN_PASSWORD="INFINILabs01" \
-v $PWD/easysearch/config:/temp_host_config \
infinilabs/easysearch:1.13.0 \
sh -c "cp -a /app/easysearch/config/. /temp_host_config/ && chmod -R ugo+rw /temp_host_config/"

步骤三：创建 docker-compose.yml 文件

这是核心步骤。在你的项目根目录 ~/infini_compose_lab 下，创建一个名为 docker-compose.yml 的文件，并填入以下内容。这个文件定义了我们的服务、它们如何运行以及它们如何交互。

cat <<EOF > docker-compose.yml
services:
  easysearch:
    image: infinilabs/easysearch:1.13.0
    container_name: infini-easysearch
    environment:
      - cluster.name=infini_compose_cluster
      - node.name=node-01
      - cluster.initial_master_nodes=node-01
      - "ES_JAVA_OPTS=-Xms1g -Xmx1g"
      - EASYSEARCH_INITIAL_ADMIN_PASSWORD=INFINILabs01
    ports:
      - "9200:9200"
      - "9300:9300"
    volumes:
      - ./easysearch/config:/app/easysearch/config
      - ./easysearch/data:/app/easysearch/data
      - ./easysearch/logs:/app/easysearch/logs
    ulimits:
      memlock: {soft: -1, hard: -1}
      nofile: {soft: 65536, hard: 65536}
    networks:
      - infini_app_net

  console:
    image: infinilabs/console:1.29.6
    container_name: infini-console
    ports:
      - "9000:9000"
    volumes:
      - ./console/config:/config
      - ./console/data:/data
      - ./console/logs:/log
    networks:
      - infini_app_net

networks:
  infini_app_net:
    driver: bridge
EOF

docker-compose.yml 文件关键点：

• services: 定义了 easysearch 和 console 两个服务。
• image: 指定了每个服务使用的 Docker 镜像和版本。
• container_name: 为容器指定一个易于识别的名称。
• environment: 设置容器的环境变量。
• Easysearch 单节点配置: 注意 cluster.initial_master_nodes 设置为节点自身的名称。
• ports: 将容器的端口映射到宿主机的端口。
• volumes: 实现持久化的核心。将宿主机当前目录 (./) 下的 console/* 和 easysearch/* 子目录分别映射到容器内对应的路径。
• networks: 将两个服务都连接到我们定义的 infini_app_net 网络。这使得 console 服务可以通过服务名 easysearch (例如 https://easysearch:9200) 来访问 easysearch 服务。

步骤四：使用 Docker Compose 启动环境

现在，所有配置都在 docker-compose.yml 文件中了。启动整个环境只需要一条命令。 在 ~/infini_compose_lab 目录下（包含 docker-compose.yml 文件），执行：

docker compose up -d

• docker compose (V2) 或 docker-compose (V1)。
• up: 创建并启动在 docker-compose.yml 中定义的所有服务。
• -d: 后台模式运行。

首次运行时，如果本地没有对应的镜像，Docker Compose 会自动拉取。

常用 Docker Compose 命令：

• 查看服务状态：

docker compose ps

• 查看所有服务的实时日志：

docker compose logs -f

• 查看特定服务的日志：

docker compose logs -f console
docker compose logs -f easysearch

• 停止所有服务（保留数据）：

docker compose stop

• 停止并移除所有容器、网络和匿名卷（保留通过 volumes 映射的本地数据）：

docker compose down

步骤五：验证和使用

1. 访问 Console: 浏览器打开 http://localhost:9000。
2. 进行配置: 在 Console 中连接 Easysearch (https://easysearch:9200，因为它们在同一个 Docker 网络中，可以直接使用服务名)，创建用户，查看监控等。
3. 测试持久化:

docker compose down # 停止并移除容器
# 稍等片刻
docker compose up -d # 重新启动

再次访问 http://localhost:9000，你会发现之前的配置都还在！

操作截图

彻底清理，包括删除命名卷（如果使用了的话）和本地数据(可选)

# -v 移除命名卷
docker compose down -v
# 然后手动删除本地持久化目录
rm -rf ~/infini_compose_lab/console
rm -rf ~/infini_compose_lab/easysearch

总结

通过 Docker Compose，我们用一个简洁的 docker-compose.yml 文件取代了之前冗长的 docker run 命令，极大地简化了 INFINI Console 和 Easysearch 本地环境的搭建和管理过程。同时，通过正确的卷挂载配置，我们依然确保了数据的持久化，解决了重启后配置丢失的问题。

对于开发、测试和快速原型验证，Docker Compose 无疑是一个强大而高效的工具。希望本教程能帮助你更轻松地使用 INFINI Console 进行本地实验和开发！

关于 INFINI Console

INFINI Console 是一款开源的非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管，企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。INFINI Console 还可以对集群内的索引及数据进行操作管理，可以配置灵活的告警规则，可以指定统一的安全策略，可以查看各个维度的日志和审计信息，真正实现企业级的搜索服务平台化建设和运营。

官网文档：https://docs.infinilabs.com/console/main/
开源地址：https://github.com/infinilabs/console

作者：罗厚付，极限科技（INFINI Labs）云上产品设计与研发负责人，拥有多年安全风控及大数据系统架构经验，主导过多个核心产品的设计与落地，日常负责运维超大规模 ES 集群（800+节点/1PB+数据）。
原文：https://infinilabs.cn/blog/2025/console-easysearch-with-docker-compose/

背景介绍

许多用户在使用 Docker 部署 INFINI Console（本文使用 1.29.6 版本）时，可能会遇到一个常见问题：重启容器后，之前在 INFINI Console 中所连接的系统集群配置会丢失。这个问题通常源于未能正确配置 Docker 的数据持久化。原本通过 Docker 运行 INFINI Console 只是一个简单的测试示例，并未考虑多次重启使用，现官方文档也进行了更新，参考：容器部署

接下来我们本地测试一下。

理解核心问题：Docker 容器与数据持久化

默认情况下，Docker 容器的文件系统是临时的。当容器被停止并删除后，容器内部所做的任何未被持久化的更改都会丢失。INFINI Console 的配置存储在其容器内部的特定目录中。为了在容器重启或重建后保留这些信息，我们必须将这些关键目录映射到宿主机（你的电脑）上的持久化存储位置。

准备工作

• 操作系统: macOS (本文示例)
• Docker 环境: OrbStack (https://orbstack.dev/) 或 Docker Desktop for Mac。

请确保 Docker 服务已启动并正常运行。你可以通过在终端执行 docker --version 来验证。

docker --version
Docker version 25.0.5, build 5dc9bcc

步骤一：创建本地持久化目录和自定义 Docker 网络

首先，在宿主机上为 Console 和 Easysearch 创建用于存储配置、数据和日志的目录。同时，创建一个自定义 Docker 网络，以便容器之间可以通过名称进行通信。

# 1. 创建项目根目录和各个服务的持久化子目录
mkdir -p ~/infini_manual_setup/console/config ~/infini_manual_setup/console/data ~/infini_manual_setup/console/logs
mkdir -p ~/infini_manual_setup/easysearch/config ~/infini_manual_setup/easysearch/data ~/infini_manual_setup/easysearch/logs
cd ~/infini_manual_setup

# 2. 创建一个自定义的 Docker 桥接网络
docker network create infini_app_net

• infini_app_net 是我们为这两个容器创建的自定义网络名称。

步骤二：提取初始配置文件

为了方便首次启动和后续自定义，我们需要从官方 Docker 镜像中提取默认的配置文件到我们本地创建的持久化目录中。

1. INFINI Console (1.29.6) 初始配置 根据 INFINI Console 官方 Docker 文档，其容器内配置文件位于 /config。

docker pull infinilabs/console:1.29.6
docker run --rm \
    -v $PWD/console/config:/temp_host_config \
    infinilabs/console:1.29.6 \
    sh -c "cp -a /config/. /temp_host_config/ && chmod -R ugo+rw /temp_host_config/"

2. INFINI Easysearch (1.13.0) 初始配置 INFINI Easysearch 镜像内部的配置文件位于 /app/easysearch/config，并且需要初始管理员密码 INFINILabs01。

重要提示：请务必为 Easysearch 设置安全的密码。

docker pull infinilabs/easysearch:1.13.0
docker run --rm \
    -e EASYSEARCH_INITIAL_ADMIN_PASSWORD="INFINILabs01" \
    -v $PWD/easysearch/config:/temp_host_config \
    infinilabs/easysearch:1.13.0 \
    sh -c "cp -a /app/easysearch/config/. /temp_host_config/ && chmod -R ugo+rw /temp_host_config/"

现在，你的本地 console/config 和 easysearch/config 目录应该包含了初始配置文件。

检查目录如下

tree -L 3 .
.
├── console
│   ├── config
│   │   ├── install_agent.tpl
│   │   ├── permission.json
│   │   ├── setup
│   │   └── system_config.tpl
│   ├── data
│   └── logs
└── easysearch
    ├── config
    │   ├── admin.crt
    │   ├── admin.key
    │   ├── analysis-ik
    │   ├── ca.crt
    │   ├── ca.key
    │   ├── easysearch.yml
    │   ├── easysearch.yml.example
    │   ├── instance.crt
    │   ├── instance.key
    │   ├── jvm.options
    │   ├── jvm.options.d
    │   ├── log4j2.properties
    │   └── security
    ├── data
    └── logs

步骤三：手动运行 INFINI Easysearch 容器

使用 docker run 命令启动 Easysearch，并配置端口映射、环境变量和最重要的——卷挂载。

docker run -d \
--name easysearch01 \
--network infini_app_net \
-p 9200:9200 \
-p 9300:9300 \
-e cluster.name="infini_local_cluster" \
-e node.name="easysearch-node01" \
-e cluster.initial_master_nodes="easysearch-node01" \
-e "ES_JAVA_OPTS=-Xms1g -Xmx1g" \
-e EASYSEARCH_INITIAL_ADMIN_PASSWORD="INFINILabs01" \
-v $PWD/easysearch/config:/app/easysearch/config \
-v $PWD/easysearch/data:/app/easysearch/data \
-v $PWD/easysearch/logs:/app/easysearch/logs \
--ulimit memlock=-1:-1 \
--ulimit nofile=65536:65536 \
infinilabs/easysearch:1.13.0

关键参数解释：

• --name easysearch01: 为容器指定一个名称。
• --network infini_app_net: 连接到自定义网络。
• -p HOST_PORT:CONTAINER_PORT: 端口映射。
• -e VARIABLE=VALUE: 设置环境变量。
• -v $PWD/host/path:/container/path: 实现持久化的核心。将宿主机当前工作目录 ($PWD) 下的子目录映射到容器内的指定路径。

步骤四：手动运行 INFINI Console 容器

现在启动 Console 容器，同样配置网络、端口、环境变量和卷挂载。

docker run -d \
--name console01 \
--network infini_app_net \
-p 9000:9000 \
-v $PWD/console/config:/config \
-v $PWD/console/data:/data \
-v $PWD/console/logs:/log \
infinilabs/console:1.29.6

查看日志

docker logs -f easysearch01
docker logs -f console01

步骤五：验证服务和持久化

1. 检查容器状态: docker ps (应能看到 easysearch01 和 console01)。
2. 访问 Console: 浏览器打开 http://localhost:9000。
3. 在 Console 中进行初始化配置
4. 测试持久化 (重启 Console 容器):

docker stop console01
docker rm console01
# 重新运行步骤四中启动 Console 的 docker run 命令 (确保所有参数一致)

操作截图

再次访问 Console: 打开 http://localhost:9000。如果一切正常，证明持久化成功。

步骤六：停止和清理(可选)

• 停止容器: docker stop console01 easysearch01
• 移除容器: docker rm console01 easysearch01
• 移除网络: docker network rm infini_app_net
• 移除本地持久化数据 (如果不再需要):

rm -rf ~/infini_manual_setup/console
rm -rf ~/infini_manual_setup/easysearch

总结

通过 docker run 命令并仔细配置卷挂载，我们成功地为 INFINI Console 和 Easysearch 构建了一个具有持久化能力的本地容器环境，有效解决了重启后配置丢失的问题。虽然手动操作参数较多，但它能让你更清晰地理解 Docker 的核心机制。

在后续的文章中，我们将探讨如何使用 Docker Compose 来简化这一过程。

关于 INFINI Console

INFINI Console 是一款开源的非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管，企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。INFINI Console 还可以对集群内的索引及数据进行操作管理，可以配置灵活的告警规则，可以指定统一的安全策略，可以查看各个维度的日志和审计信息，真正实现企业级的搜索服务平台化建设和运营。

官网文档：https://docs.infinilabs.com/console/main/
开源地址：https://github.com/infinilabs/console

作者：罗厚付，极限科技（INFINI Labs）云上产品设计与研发负责人，拥有多年安全风控及大数据系统架构经验，主导过多个核心产品的设计与落地，日常负责运维超大规模 ES 集群（800+节点/1PB+数据）。
原文：https://infinilabs.cn/blog/2025/console-easysearch-with-docker/

在日常运维 Easysearch 的过程中，备份数据是一项重要工作。为了确保数据安全和业务连续性，我们可能需要了解并掌握多种备份索引的方法，以便应对不同的场景。我们先梳理下常用的备份方法有哪些。

Snapshot

Easysearch 的 Snapshot（快照） 是一种官方支持的集群数据备份与恢复机制，通过将索引数据、集群状态（如设置、模板）和分片分配信息保存到外部存储仓库（如本地文件系统、AWS S3、华为云 OBS 等）实现全量或增量备份。其核心原理是复制索引的 Lucene 分片文件，并利用段文件（Segment）的不可变性实现增量存储优化。

快照的优点包括：

1. 高效性：增量备份仅存储新增或修改的段文件，显著节省存储空间和网络传输成本；
2. 可靠性：支持跨集群恢复和灾难性故障修复，避免直接拷贝数据目录导致的数据不一致风险；
3. 灵活性：可指定备份特定索引，并支持版本兼容性恢复（需遵循版本匹配规则）；
4. 自动化：通过策略（Snapshot Policy）实现定时备份管理。

缺点则包括：

1. 时效性限制：无法实现实时备份，是一种 PIT (Point in Time) 备份；
2. 需预先配置：需预先注册仓库并确保存储系统可用性；
3. 恢复约束：恢复时需关闭或删除目标索引，或恢复时修改索引名称；
4. 依赖主分片状态：若主分片不可用（如节点故障），快照任务会失败。

总体而言，Snapshot 是生产环境首选的备份方案，尤其适合大规模数据归档和跨环境迁移，但需权衡备份频率与存储成本。详情可以参考文档。

Reindex

Easysearch 的 Reindex 是一种通过 API 将数据从一个索引复制到另一个索引的备份方法，适用于同集群或跨集群的数据迁移与重建。其核心操作是使用 POST _reindex 命令将源索引的文档批量读取并写入目标索引。备份时需确保目标索引的 Mapping 与源索引兼容（字段类型一致），并通过 size 参数控制批量处理量（如 "size": 2000）以优化性能。对于跨集群备份，需在目标集群配置文件中添加源集群 IP 白名单（reindex.remote.whitelist）并提供认证信息，详情可以参考文档。

优点：

1. 灵活性：支持通过 query 参数筛选特定数据备份（如仅迁移某字段值符合条件的数据）；
2. 无缝整合：可在目标索引中修改索引结构（如分片数、字段类型）；
3. 并发及限流：支持设置并发度和限流阈值，适应不同的场景；
4. 操作便捷：无需额外存储配置，适合临时备份或小规模迁移。

缺点：

1. 资源消耗大：reindex 本质是数据写入，要占用 CPU、内存和磁盘 IO，可能影响集群性能；
2. 网络依赖：跨集群备份依赖网络带宽，高延迟或带宽不足会显著拖慢速度；
3. 中断风险：reindex 一旦中途报错，无法继续重试，只能从头再来；
4. 时效性局限：备份完成后新增数据需手动触发二次迁移，无法实现实时同步。

建议在低峰期执行 Reindex，并优先采用快照（Snapshot）进行生产环境长期备份，Reindex 更适合索引结构调整或小规模数据迁移场景。

工具备份

还有些工具支持将 Easyearch 的索引数据备份成一个文件，比如 elasticsearch-dump、Logstash 等。数据量较大的情况下，这些工具可能会有效率问题，一般在特定场景下有用，在此不展开介绍。

Clone API

Easysearch 的 Clone API 并不是传统意义上的备份工具，其核心设计目标是通过复制索引的底层段文件（Segment）快速生成一个与原索引数据一致的新索引，包括源索引是 Mapping 和 Setting 也一起复制。

具体操作步骤如下：

1. 设置源索引为只读状态

PUT /.infini_metrics-000004/_settings
{
  "settings": {
    "index.blocks.write": true
  }
}

1. 执行 Clone 操作

POST .infini_metrics-000004/_clone/backup_infini_metrics-000004

3. 设置源索引和新索引为可读写状态

复制是新索引也会是只可读状态，大家根据需要选择是否都改成可读写状态。

PUT /.infini_metrics-000004,backup_infini_metrics-000004/_settings
{
  "settings": {
    "index.blocks.write": null
  }
}

优点：

• 极速复制：直接复用底层段文件，无需重写数据，适用于大数据量快速复制。
• 保留定义: 直接使用源索引的 Setting 和 Mapping。
• 存储优化：可调整目标索引的副本数，节省资源。

缺点：

• 业务影响：克隆前需修改源索引为只可读，导致写入中断，影响服务可用性。
• 不够灵活：沿用源索引 Setting 和 Mapping 无法修改（副本数可修改）。
• 扩展性不足：不能跨集群，目标索引只能在本集群。

Clone API 有自己鲜明的特点，对比 Snapshot，它不用恢复过程，目标索引直接在集群中了。对比 Reindex，它无需重写数据和先创建索引，更加高效。在特定场景下非常有用，也可以搭配其他备份方法一起使用。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch

作者：杨帆，极限科技（INFINI Labs）高级解决方案架构师、《老杨玩搜索》栏目 B 站 UP 主，拥有十余年金融行业服务工作经验，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。
原文：https://infinilabs.cn/blog/2025/easysearch-index-clone-api/

在之前的博客《从 Elasticsearch 迁移到 Easysearch 指引》中介绍过如何把索引从 Elasticsearch 迁移到 Easysearch。有时候想临时从 Elasticsearch 迁移点儿数据做测试，数据量不大，也可尝试使用 Reindex From Remote 的方法。

测试环境介绍

本次主要测试从远程集群索引数据，reindex 还有很多其他使用方式，详情请参考官方文档。

• Easysearch 版本：1.10.0，监听 localhost:9200
• Elasticsearch 版本：6.8.23，监听 localhost:9201
• INFINI Console 版本：1.25.1（运行 reindex 命令用）

Reindex API

Reindex 可以从本地或远程集群将源索引数据写入本地目标索引。使用简单，有以下注意点：

• 源索引启用 _source ，这个默认都是启用的
• 在调用 _reindex 之前，应该先创建、配置目标索引
• 如果源索引在远程集群，必须在 easysearch.yml 中配置 reindex.remote.whitelist 设置
• 使用 POST 调用

测试过程

我们先不设置白名单，直接从远程集群 reindex 看看会怎样。

报错提示 localhost:9201 不在 reindex.remote.whitelist 中。

正常操作步骤

1. 编辑 Easysearch 配置文件 easysearch.yml，添加白名单，重启生效。

reindex.remote.whitelist: [localhost:9201]

2. 建立目标索引，指定 setting 和 mapping

reindex 不会复制源索引的 setting 和 mapping，需要提前创建目标索引，否则会使用默认设置。

3. 执行 reindex 命令

执行成功。需要注意的是，如果数据量比较大，reindex 命令会超时，这个没关系，任务会继续在后台执行。也可以在执行 reindex 的时候添加参数 wait_for_completion=false 不等待执行完成，直接返回任务 id。

POST _reindex?wait_for_completion=false

针对有认证的集群，reindex 可以指定以下选项：

总结

针对临时数据量不大的场景可尝试使用 reindex 迁移数据。如果数据量大了，reindex 迁移速度不是很高效，而且如果中途出现错误迁移中断了，需要重新 reindex 不方便，建议使用 INFINI Console 进行数据迁移。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch

作者：杨帆，极限科技（INFINI Labs）高级解决方案架构师、《老杨玩搜索》栏目 B 站 UP 主，拥有十余年金融行业服务工作经验，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。
原文：https://infinilabs.cn/blog/2025/easysearch-reindex-from-remote/

如果你正在使用 Easysearch 处理日志、监控指标、事件流或其他任何具有时间顺序的数据，那么你一定知道索引的性能和效率至关重要。Easysearch 底层的 Lucene Segment 合并是保持搜索和索引性能的关键后台任务。然而，你是否意识到，默认的合并策略可能并不是处理时序数据的最佳选择？

今天，我们就来介绍 Easysearch 1.12.1 版本起引入的一个重要优化：基于时间范围的合并策略 (TimeRangeMergePolicy) ，它专门为优化时序数据的 Segment 合并而生。

时序数据的合并挑战：默认策略的局限性

Easysearch 默认使用的合并策略（如 TieredMergePolicy）非常智能，它会根据 Segment 的大小、文档删除比例等因素来决定合并哪些 Segment，以平衡查询性能和资源使用。

但在时序数据场景下，这种通用策略可能会遇到一些问题：

1. 冷热数据混合： 想象一下，几个月前的旧日志数据（冷数据）可能因为大小合适而被选中，与最近几小时内产生的新数据（热数据）进行合并。这会带来不必要的 I/O 和 CPU 开销，因为冷数据通常访问很少，合并它们对查询性能的提升有限，反而消耗了宝贵的资源。
2. 查询性能影响： 合并可能产生覆盖时间跨度非常大的 Segment。当你执行按时间范围过滤的查询时（这在时序场景中非常常见），查询可能需要扫描这些巨大的 Segment，即使其中大部分数据都不在你的目标时间范围内，从而降低查询效率。

解决方案：TimeRangeMergePolicy 登场！

为了解决上述痛点，Easysearch 引入了 TimeRangeMergePolicy。顾名思义，这种策略在做合并决策时，将时间维度纳入了核心考量。

它的核心思想很简单，但非常有效：

• 时间优先： 倾向于合并那些时间上相邻或接近的 Segment。比如，属于同一天或同一小时的 Segment 更有可能被一起合并。
• 保留时间分区： 尽量避免将时间跨度极大的 Segment 合并在一起。这有助于保持数据的“时间局部性”，使得按时间范围查询时能更快地排除不相关的 Segment。
• 优先合并新数据： 通常，新产生的数据（热数据）更新和删除操作更频繁。优先合并包含较新数据的 Segment，有助于更快地回收被删除文档占用的空间，并优化对最新数据的查询性能。

如何为你的时序索引启用 TimeRangeMergePolicy？

启用这个功能非常简单，只需要两步：

1. 确认日期字段： 首先，确保你的索引 Mapping 中有一个能准确代表数据时间的字段，通常是日期（date）或时间戳（date_nanos）类型，例如 @timestamp、event_time 等。这个字段的值应该反映数据产生的实际时间。
2. 更新索引设置： 使用 Index Settings API，为你的索引指定 index.merge.policy.time_range_field 参数，并将其值设置为你的时间字段名。

示例：

假设你的时间字段是 timestamp，索引名称是 my-timeseries-index，你可以执行以下请求：

PUT /my-timeseries-index/_settings
{
  "index": {
    "merge.policy.time_range_field": "timestamp"
  }
}

搞定！设置之后，my-timeseries-index 后续的 Segment 合并就会自动采用 TimeRangeMergePolicy 了。

专家提示： 如果你想让所有新创建的时序索引默认就使用这个策略，可以将这个设置添加到你的索引模板 (Index Template) 中。

TimeRangeMergePolicy 的优势

启用时间范围合并策略能带来哪些好处呢？

• 降低合并开销： 显著减少冷热数据的无效合并，节省 I/O 和 CPU 资源。
• 提高资源效率： 更智能的合并有助于更快地回收已删除文档的空间，并可能降低整体计算资源的使用。
• 优化查询性能： 保持 Segment 的时间局部性，对于按时间范围过滤的查询（例如，“查询过去一小时的日志”）可能会有明显的性能提升。
• 对时序数据更友好： 该策略的设计初衷就是为了更好地服务于日志、指标这类严格按时间增长的数据模式。

注意事项

在使用 TimeRangeMergePolicy 时，有几点需要注意：

• 时间字段是关键： 策略的效果高度依赖于你所指定的 time_range_field。如果该字段不存在，或者字段中的时间值混乱、不准确，策略可能无法发挥预期效果，甚至适得其反。
• 并非万能丹： 这个策略最适合具有明确时间序列特征的数据。对于非时序数据（例如，商品信息、用户信息索引），默认的 TieredMergePolicy 可能仍然是更好的选择。
• 版本要求： 请确保你的 Easysearch 集群版本至少为 1.12.1。

总结

对于处理大量时序数据的 Easysearch 用户来说，TimeRangeMergePolicy 是一个非常有价值的优化工具。通过感知数据的时间属性，它可以让 Segment 合并操作更加智能和高效，从而降低资源消耗、提升查询性能。如果你的索引符合时序数据的特征，并且正在运行 Easysearch 1.12.1 或更高版本，不妨尝试启用这个策略，看看它能否为你的集群带来改善！

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。
原文：https://infinilabs.cn/blog/2025/time-range-mergepolicy-for-easysearch/

背景

在处理时序数据时，Rollup 功能通过数据聚合显著降低存储成本，并提升查询性能。Easysearch 与 OpenSearch 均提供了 Rollup 能力，但在多个关键维度上，Easysearch Rollup 展现出更优的表现。本文将从查询体验、索引管理、聚合能力、性能优化和任务管理五个方面，分析 Easysearch Rollup 相较于 OpenSearch Rollup 的优势。

Easysearch vs OpenSearch

1. 查询体验：标准接口与无缝集成

Easysearch Rollup 支持通过标准的 _search API 查询原始索引，系统自动融合 Rollup 数据，用户无需变更现有代码或使用专用查询端点。相比之下，OpenSearch Rollup 虽然使用标准查询语法，但需要用户显式指定 Rollup 索引，无法自动结合原始数据，在需要同时访问原始与聚合数据的场景下显得更为繁琐。

• 差异：Easysearch 支持自动融合原始与 Rollup 数据，OpenSearch 需手动指定索引。
• 影响：Easysearch 显著降低了查询逻辑的复杂性和开发维护成本。

2. 索引管理：自动化与扩展能力

Easysearch Rollup 提供自动索引滚动功能，可通过 rollup.index_max_docs. 配置项为不同的目标 Rollup 索引设置文档数上限，触发新索引的动态创建，显著简化管理流程。此外，配置中支持使用变量（如 {{ctx.source_index}}）动态生成目标索引名，便于多个任务复用同一模板，批量扩展 Rollup 任务时更加高效和灵活。

相比之下，OpenSearch Rollup 依赖 Index State Management（ISM）策略或手动操作进行索引切换，配置复杂、监控成本高，且在大规模任务部署时缺乏灵活的模板化机制。

• 差异：Easysearch 提供内建的自动滚动机制，OpenSearch 依赖外部策略或手动配置。
• 影响：Easysearch 更易于统一管理和大规模扩展，运维成本更低。

3. 聚合能力：更广泛的聚合类型支持

Easysearch Rollup 支持丰富的聚合类型，包括数值字段的 avg、sum、max、min、percentiles，关键词字段的 terms，日期字段的 date_histogram 与 date_range，还支持 filter 聚合与 special_metrics（可自定义聚合字段和方式）等高级功能。OpenSearch Rollup 支持的聚合类型相对有限，不支持 date_range、filter 等复杂聚合表达式。

• 差异：Easysearch 提供更全面的聚合能力，OpenSearch 仅支持基础聚合。
• 影响：Easysearch 更适合构建复杂的时序分析任务，满足更广泛的业务需求。

4. 性能优化：精细化配置与资源控制

Easysearch Rollup 提供多种性能优化选项，例如 ROLLUP_SEARCH_MAX_COUNT 控制并发查询数，rollup.hours_before 限制回溯时间范围，write_optimization 和 field_abbr 用于优化写入效率与运行时的内存占用。而 OpenSearch Rollup 缺乏类似的专用配置项，主要依赖通用的集群参数，灵活性与精细度较低。

• 差异：Easysearch 提供针对 Rollup 场景的专属优化选项，OpenSearch 优化能力较通用。
• 影响：Easysearch 在资源使用效率、查询性能和成本控制方面更具优势。

5. 任务管理：批量控制与更高灵活性

Easysearch Rollup 支持使用通配符进行任务批量管理，且新建任务默认处于非激活状态，用户可按需启用。而 OpenSearch Rollup 中，任务默认立即启用，管理粒度较粗，仅支持单个任务的启停与修改，缺乏批量操作能力。

• 差异：Easysearch 支持批量任务管理与按需启用，OpenSearch 功能较为基础。
• 影响：Easysearch 在多任务环境下提供更高的管理效率和控制能力。

实战示例：节点统计 Rollup 配置

以下是一个 Easysearch Rollup 任务的配置示例：

{
  "rollup": {
    "source_index": ".infini_metrics",
    "target_index": "rollup_node_stats_{{ctx.source_index}}",
    "timestamp": "timestamp",
    "continuous": true,
    "page_size": 200,
    "cron": "*/5 1-23 * * *",
    "interval": "1m",
    "identity": ["metadata.labels.cluster_id", "metadata.labels.node_id"],
    "stats": [{ "max": {} }, { "min": {} }, { "value_count": {} }],
    "special_metrics": [
      {
        "source_field": "payload.elasticsearch.node_stats.jvm.mem.heap_used_in_bytes",
        "metrics": [{ "avg": {} }, { "max": {} }, { "min": {} }]
      }
    ],
    "write_optimization": true
  }
}

• 亮点：支持自动索引滚动、标准 API 查询、special_metrics 高级聚合与写入优化等特性。

总结

综合来看，Easysearch Rollup 在以下方面优于 OpenSearch Rollup：

• 查询接口的兼容性与无感知集成
• 自动化的索引管理与扩展能力
• 更丰富的聚合类型与表达能力
• 针对性更强的性能优化参数
• 灵活高效的任务批量管理机制

这些优势使 Easysearch Rollup 更加适用于复杂、多样化的时序数据处理场景，特别是在对性能、扩展性与运维效率有较高要求的系统中表现出色。如果你正在寻找一款功能全面、易于管理的 Rollup 解决方案，Easysearch 是一个值得重点考虑的选择。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。
原文：https://infinilabs.cn/blog/2025/Easysearch-Rollup-vs-OpenSearch-Rollup/

之前介绍了 Easysearch 如何使用 S3 进行快照备份，毕竟那是手工操作。Easysearch 还提供了快照生命周期管理，能够按照策略自动创建、删除快照，极大地方便了用户的日常管理。

快照生命周期管理计划由创建计划、删除计划以及快照配置组成。

• 创建计划和删除计划包含一个 cron 表达式，指定任务的频率和时间。
• 删除计划可以指定快照保留策略，以保留过去 30 天的快照或仅保留最近的 10 个快照。
• 快照配置包括快照的索引和存储库，并支持所有通过 API 创建快照时的参数。此外，还可以指定快照名称中使用的日期的格式和时区。

快照生命周期创建的快照名称格式为 <policy _ name>-<date>-<Random number> 。

比如， 计划每 2 分钟对索引 .infini_metrics-00001 创建一个快照，并且只保留最近的 2 个快照。

curl -XPOST -uadmin:admin -H 'Content-Type: application/json' 'https://localhost:9200/_slm/policies/daily-policy' -d '
{
  "description": "测试快照策略",
  "creation": {
    "schedule": {
      "cron": {
        "expression": "*/2 * * * *",
        "timezone": "Asia/Shanghai"
      }
    },
    "time_limit": "1h"
  },
  "deletion": {
    "schedule": {
      "cron": {
        "expression": "*/1 * * * *",
        "timezone": "Asia/Shanghai"
      }
    },
    "condition": {
      "max_count": 2
    },
    "time_limit": "1h"
  },
  "snapshot_config": {
    "date_format": "yyyy-MM-dd-HH:mm",
    "date_format_timezone": "Asia/Shanghai",
    "indices": ".infini_metrics-00001",
    "repository": "easysearch_s3_repo",
    "ignore_unavailable": "true",
    "include_global_state": "false"
  }
}'

自动创建的快照如下图，一个 16 点 34 分创建的，另一个 16 点 36 分创建的。

⚠️ 注意：虽然指定只保留最近两个快照，但因为创建和删除其实是两个独立的任务，所以会短暂出现存在 3 个快照的现象，等删除任务调度一次就会删除多余的快照了。

如果遇到维护需要停止自动备份，也有相应的 API 来启停快照策略。

停止策略

curl -XPOST -uadmin:admin 'https://localhost:9200/_slm/policies/daily-policy/_start'

启动策略

curl -XPOST -uadmin:admin 'https://localhost:9200/_slm/policies/daily-policy/_stop'

查看策略

curl -XGET -uadmin:admin 'https://localhost:9200/_slm/policies'

删除策略

curl -XDELETE -uadmin:admin 'https://localhost:9200/_slm/policies/daily-policy?pretty'

更多详细信息请参考官方文档。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch/main/

作者：杨帆，极限科技（INFINI Labs）高级解决方案架构师、《老杨玩搜索》栏目 B 站 UP 主，拥有十余年金融行业服务工作经验，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。

Easysearch 内置了 S3 插件，这意味着用户可以直接使用该功能而无需额外安装任何插件。通过这一内置支持，用户能够方便快捷地执行 Amazon S3 上的数据快照操作。这种设计不仅简化了配置流程，也提高了工作效率，使得数据备份或迁移等任务变得更加简单易行。对于需要频繁与 S3 存储服务交互的应用场景来说，这是一个非常实用且高效的功能特性。

Minio

MinIO 是一款高性能的开源对象存储系统，专为存储大量的非结构化数据而设计。它提供了与 Amazon S3 兼容的 API，本次测试我们使用 MinIO 作为存储仓库。

建立 Bucket

进入 MinIO 管理界面，创建测试用的 bucket。

创建 Access key

测试的 Access Key 设置的比较简单。

Easysearch

为了能够使用 S3 存储，Easysearch 要进行必要的配置。

easyearch.yml

修改 easysearch.yml 配置 S3 信息。

s3.client.default.endpoint: 172.17.0.4:9000
s3.client.default.protocol: http

⚠️ 注意：修改了 easysearch.yml 需要重启生效。

keystore

为了安全，我们把 S3 的 Access key 信息加入 keystore 中。

bin/easysearch-keystore add s3.client.default.access_key #输入easysearch
bin/easysearch-keystore add s3.client.default.secret_key #输入easysearch
bin/easysearch-keystore list

注册存储库

在 INFINI Console 的开发工具中，使用命令注册 s3 存储库。

PUT /_snapshot/easysearch_s3_repo?verify=true&pretty
{
  "type": "s3",
  "settings": {
    "bucket": "easysearch-bucket",
    "compress": true
  }
}

更多参数请查看文档。

创建快照

在 INFINI Console 的开发工具中，使用命令创建快照。

备份执行完成。

S3 查看快照

我们在 INFINI Console 中通过命令创建了快照，可以在 MinIO 的 bucket 中进行进一步确认是否有相关文件。

快照还原测试

删除以备份索引 .infini_metrics-0001，删除前先查看下索引情况，文档数 557953。

删除 .infini_metrics-0001 索引。

确认 .infini_metrics-0001 索引已被删除。

进行快照还原。

验证恢复索引。

索引 .infini_metrics-0001 已经还原了，文档数也一致。

小结

Easysearch 使用 S3 存储备份的步骤如下：

1. S3 服务建立 Bucket、Access Key。
2. Easysearch 编辑 easysearch.yml 添加 S3 服务 endpoint 信息。
3. easysearch-keystore 添加 S3 的 Access key 信息，加密保存。
4. Easysearch 注册 S3 存储仓库。
5. 执行快照备份。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch/main/

作者：杨帆，极限科技（INFINI Labs）高级解决方案架构师、《老杨玩搜索》栏目 B 站 UP 主，拥有十余年金融行业服务工作经验，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。

Easyearch 为了防止索引将磁盘空间完全占满，使用磁盘水位线进行磁盘空间控制。之前有文章提过不同水位线的作用，以及如何使用 INFINI Console 提前进行告警，提前进行处理。本篇主要探讨提前处理的情况。

一、增加资源

如果资源充裕，可考虑为 Easysearch 集群扩充资源：

1. 添加新的数据节点

扩充节点后，集群会自动进行数据平衡，可用下面的命令查看进度

GET /_cat/shards?v&h=state,node&s=state

如果响应中分片的状态是 RELOCATING ，则表示分片仍在移动。

2. 扩充现有数据节点磁盘容量

扩充完后可查看磁盘利用率下降情况

GET _cat/allocation?v&s=disk.avail&h=node,disk.percent,disk.avail,disk.total,disk.used,disk.indices,shards

二、释放磁盘空间

如果无资源可添加，则考虑减少磁盘消耗：

1. 删除无用索引

建议使用索引生命周期进行管理，自动删除过期索引。

2. 删除多余副本

有些业务索引可能会有多分副本，可酌情缩减副本数，降低磁盘消耗。以下命令按副本数量和主存储大小的降序排列索引。

GET _cat/indices?v&s=rep:desc,pri.store.size:desc&h=health,index,pri,rep,store.size,pri.store.size

3. 可搜索快照

对于有些数据平时不常用，但需要长期保留的，建议使用可搜索快照功能降低磁盘消耗。

三、索引空间优化

1. 启用 ZSTD 压缩及 source_reuse 功能

Easysearch 支持 ZSTD 和 source_reuse 功能，对比默认的压缩算法，可大幅降低磁盘消耗。

可在创建索引时启用 ZSTD 和 source_reuse 功能，也可通过索引模板来进行设置，参考文档。

PUT test-index
{
  "settings": {
    "index.codec": "ZSTD",
    "index.source_reuse": "true"
  }
}

⚠️ 注意：当索引里包含 nested 类型映射，或插件额外提供的数据类型时，不能启用 source_reuse，例如 knn 索引。

2. 索引优化

• mapping 优化
  避免使用默认的 mapping 类型，因为字符串类型的数据将得到 text 和 keyword 两个类型的 mapping。
• 字段优化
  统计指定索引每个字段的访问次数。

GET metrics/_field_usage_stats

分析指定索引各个字段占用磁盘的大小。

POST metrics/_disk_usage?run_expensive_tasks=true

结合以上信息进一步优化各个字段，如关闭不用的功能等

3. 使用 rollup 功能

对于时序场景类的数据，往往会有大量的非常详细的聚合指标，随着时间的图推移，存储将持续增长。汇总功能可以将旧的、细粒度的数据汇总为粗粒度格式以进行长期存储。通过将数据汇总到一个单一的文档中，可以大大降低历史数据的存储成本。

Easysearch 的 rollup 具备一些独特的优势，可以自动对 rollup 索引进行滚动而不用依赖其他 API 去单独设置，并且在进行聚合查询时支持直接搜索原始索引，做到了对业务端的搜索代码完全兼容，从而对用户无感知。

如果有问题，欢迎加我微信沟通。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://docs.infinilabs.com/easysearch

作者：杨帆，极限科技（INFINI Labs）高级解决方案架构师、《老杨玩搜索》栏目 B 站 UP 主，拥有十余年金融行业服务工作经验，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。

去年我们尝试过使用 Easysearch + 千问 2 大模型打造一个企业内部知识问答系统，今年又有更加给力的大模型出现了--DeepSeek，性能对标 OpenAI o1 正式版。而且 Easysearch 对比去年也有了不少进步，是时候让我们升级下问答系统了。

DeepSeek

2025 年 1 月 20 日，人工智能领域迎来里程碑式突破！深度求索（DeepSeek）正式发布新一代推理大模型 DeepSeek-R1，不仅实现与 OpenAI 最新 o1 正式版的性能对标，更以全栈开放的生态布局引发行业震动。DeepSeek-R1 是首个遵循 MIT License 开源协议的高性能推理模型，完全开源，不限制商用，无需申请，极大地推动了 AI 技术的开放与共享。

下载模型

我们使用 ollama 下载运行 DeepSeek-R1，根据本地资源情况选择一个大小合适的版本：8b。

• 8b 蒸馏模型源自 Llama3.1-8B-Base
• 7b 蒸馏模型源自 Qwen-2.5 系列

这两个可能是个人用户使用最多的选择，大家资源充足的可以都下载下来对比下效果。

由于是升级，我们只需在原有程序基础上替换新版本的 Easysearch 和集成 DeepSeek 即可，Easysearch 升级成新版本 1.10.1，程序框架和 embedding 模型 (mxbai-embed-large:latest) 仍然保持不变。

数据准备

跟上次一样，使用 "INFINI 产品安装手册.PDF" 作为知识内容，通过程序将文档内容切片、转换成向量后写入 Easysearch 存储，然后结合大模型对其中的内容进行提问。

程序调整

程序代码需要调整 LLM 为 deepseek-r1:8b。另外本地主机资源有限，为节约时间，取消上个版本的用户问题改写功能(注释部分)。定义新的 retriever 和 qa_chain 直接将用户问题和 context 信息发送给大模型。

# # 实例化一个大模型工具
from langchain_community.chat_models import ChatOllama

llm = ChatOllama(model="deepseek-r1:8b")

# from langchain.prompts import PromptTemplate

# my_template = PromptTemplate(
#     input_variables=["question"],
#     template="""You are an AI language model assistant. Your task is
#     to generate 3 different versions of the given user
#     question in Chinese to retrieve relevant documents from a vector  database.
#     By generating multiple perspectives on the user question,
#     your goal is to help the user overcome some of the limitations
#     of distance-based similarity search. Provide these alternative
#     questions separated by newlines. Original question: {question}""",
# )

# 实例化一个MultiQueryRetriever
# retriever_from_llm = MultiQueryRetriever.from_llm(
#     retriever=docsearch.as_retriever(),
#     llm=llm,
#     prompt=my_template,
#     include_original=True)

retriever = docsearch.as_retriever()
# 实例化一个RetrievalQA链
qa_chain = RetrievalQA.from_chain_type(llm, retriever=retriever)

至此程序修改已经完成，原程序算上注释也不过 100 来行，大家感兴趣的可以去查看原博客。

效果测试

模拟用户提问：网关运行后监听哪个端口。

系统回答如下。

在回答中，可以看到 DeepSeek 的"思考"过程，另外回答结果也非常正确，文档中原文还是用的英语 INFINI Gateway 表示网关。

模拟用户提问：LOGGING_ES_ENDPOINT 有什么用。

系统回答如下。

文档原文内容如下。

好了，我对 DeepSeek 的表现很满意，至此知识问答系统就升级完了。

如有任何问题，请随时联系我，期待与您交流！

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://infinilabs.cn/docs/latest/easysearch

作者：杨帆，极限科技（INFINI Labs）高级解决方案架构师、《老杨玩搜索》栏目 B 站 UP 主，拥有十余年金融行业服务工作经验，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。

Easyearch 为了防止索引将磁盘空间完全占满，使用磁盘水位线进行磁盘空间控制。具体来说有三条磁盘水位线：low、high、flood。

低水位线

通过参数 cluster.routing.allocation.disk.watermark.low 进行设置，默认值 85%。也可设置成一个具体值，比如：400mb，代表须保留 400mb 空闲磁盘空间，否则就算超水位线。

一旦节点磁盘使用率超过了低水位线，Easysearch 集群不会将分片分配至该节点，但是不影响新建索引的主分片分配到该节点，新建索引的副本分配不能分配到该节点。

如果所有节点都超过高水位线，此时创建新索引会导致集群状态变成 yellow。

高水位线

通过参数 cluster.routing.allocation.disk.watermark.high 进行设置，默认值 90%。也可设置成一个具体值，比如：300mb，代表须保留 300mb 空闲磁盘空间，否则就算超水位线。

一旦节点磁盘使用率超过了高水位线，Easysearch 集群会尝试将分片移动到其他节点，不允许任何分片分配到该节点。

如果所有节点都超过高水位线，此时创建新索引会导致集群状态变成 red。

洪水位线

通过参数 cluster.routing.allocation.disk.watermark.flood_stage 进行设置，默认值 95%。也可设置成一个具体值，比如：200mb，代表须保留 200mb 空闲磁盘空间，否则就算超水位线。

一旦节点磁盘使用率超过了洪水位线，Easysearch 集群会为该节点上的所有索引添加只读锁，包括系统索引。只读锁会阻止新数据写入，当磁盘利用率低于高水位线时，只读锁会自动释放。

针对节点磁盘使用率，我们可以使用 INFINI Console 进行节点磁盘使用率告警，便于我们及时发现问题苗头，提前进行处理。有任何问题，欢迎加我微信沟通。

关于 Easysearch

INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。

官网文档：https://infinilabs.cn/docs/latest/easysearch

作者：杨帆，极限科技（INFINI Labs）高级解决方案架构师、《老杨玩搜索》栏目 B 站 UP 主，拥有十余年金融行业服务工作经验，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。

DataX

DataX 是阿里开源的一款离线数据同步工具，致力于实现包括关系型数据库(MySQL、Oracle 等)、HDFS、Hive、ODPS、HBase、FTP 等各种异构数据源之间稳定高效的数据同步功能。

本篇主要介绍 DataX 如何将数据写入到 Easysearch，对于各种数据源的连接不会做深入的探讨，感兴趣的小伙伴可以访问 DataX 的 Github 仓库查看详情。

下载与安装

DataX 无需安装，下载后解压即可使用。

系统需求：

1. JDK 1.8 及以上
2. Python2 或 3

创建任务配置文件

每个数据同步的操作可称为一个任务，任务的配置文件定义了数据源(reader)、数据目的(writer) ，以及任务的设置信息，如并发数、速度控制等。DataX 集成了如此多的数据源，如果靠纯手工编写任务配置显然不现实。官方也出了个命令可以根据指定的数据源和数据目的帮助大家生成任务配置。

python datax.py -r {YOUR_READER} -w {YOUR_WRITER}

测试配置文件

此次演示使用 streamreader 和 elasticsearchwriter 作为数据源和数据目的，任务配置如下：

{
  "job": {
    "content": [
      {
        "reader": {
          "name": "streamreader",
          "parameter": {
            "sliceRecordCount": 10000,
            "column": [
              {
                "type": "long",
                "value": "10"
              },
              {
                "type": "string",
                "value": "hello，你好，世界-DataX"
              },
              {
                "type": "string",
                "value": "hello，你好，Easysearch"
              }
            ]
          }
        },
        "writer": {
          "name": "elasticsearchwriter",
          "parameter": {
            "endpoint": "http://localhost:9200",
            "accessId": "admin",
            "accessKey": "1ef0c661d8562aaa06be",
            "index": "yf-test",
            "column": [
              { "name": "no", "type": "long" },
              { "name": "content", "type": "keyword" },
              { "name": "content2", "type": "keyword" }
            ]
          }
        }
      }
    ],
    "setting": {
      "speed": {
        "channel": 50
      }
    }
  }
}

streamreader 是一个从内存读取数据的插件， 它主要用来快速生成期望的数据并对写入插件进行测试。

我们用 streamreader 构造了 10000 个文档，文档含三个字段，任务启动了 50 个 channel 进行数据发送，结果就是共计发送 50w 个文档。

elasticssearchwriter 指定了 Easysearch 的连接信息：

• endpoint: Easysearch 的地址和端口
• accessId: 用户名
• accessKey: 密码
• index: 写入索引名
• column: 对 reader 发来数据的 schema 定义
• batchsize: 默认 1000

这次我们 Easysearch 开启的 http 服务，因为 DataX 的 elasticsearchwriter 无法跳过证书验证。对于必须使用 https 的场景，可使用 INFINI Gateway 代理 ES 服务，提供 http 通道给离线数据同步专用。

⚠️ 注意：

不同的 reader、writer 对 sliceRecordCount 和 channel 会有不同的行为。

Easysearch

本次测试使用的 Easysearch 版本是 1.9.0，需要注意是 Easysearch 要开启兼容性参数：

elasticsearch.api_compatibility: true

否则创建索引报错退出。(实际索引创建成功了但是 mapping 信息是空的)

运行任务

编辑好任务配置文件后，下一步就是执行任务。

python3 datax.py yf-test.json

写入数据时索引不存在，Datax 根据 schema 定义创建了索引。

OK 任务执行完毕，写入 50w 个文档耗时 10 秒。

如果有其他问题欢迎与我联系。

本文将探讨如何使用 INFINI Gateway 阻止不合理的查询发送到 Elasticsearch，此方法同样适用于 Opensearch 和 Easysearch 。

在以往处理 Elasticsearch OOM（内存溢出）问题的经验中，我们发现许多案例是由于查询操作导致节点出现 OOM 的情况。经过调查，这些案例主要分为两类：一类是由于查询吞吐量超出了集群的处理能力，另一类则是在执行某些不合理的查询时触发了 OOM。

具体来说：

• 查询吞吐量过高：当查询请求的频率或复杂度超过了集群的处理能力时，可能会导致节点内存耗尽，从而引发 OOM。
• 执行不合理查询：某些特殊类型的查询（例如涉及大量嵌套、深度分页或复杂的聚合操作）可能需要大量的内存资源，在执行过程中也可能导致 OOM。

通过识别并优化这些查询模式，可以有效减少 OOM 事件的发生。针对查询吞吐量过高的情况，可以参考之前的文章来管理查询吞吐。接下来的内容将介绍如何阻挡不合理查询，保护集群稳定。

不合理查询

不合理查询是指那些消耗过多系统资源（如 CPU、内存）、设计复杂、执行时间过长或需要大量计算资源的查询。这类查询不仅会导致高负载和资源耗尽，影响整个集群的稳定性和响应速度，还可能对用户体验产生负面影响。

典型的不合理查询包括但不限于：

• 嵌套聚合查询
• 使用复杂的正则表达式进行模糊匹配
• 深度分页查询（如 from: 10000, size: 10）
• 脚本查询（Script Query）
• 大规模嵌套聚合查询

为了防止这些查询对 Elasticsearch 集群造成影响，我们可以使用 INFINI Gateway 对这些查询进行阻断。

请求上下文

INFINI Gateway 运行环境中有非常多的信息可被利用，而请求上下文就是访问这些信息的入口。如请求来源、请求体信息等，都可使用关键字 _ctx 作为前缀访问相应的上下文信息。

HTTP 请求内置的 _ctx 上下文对象主要包括如下：

更多的上下文信息请访问文档。

context_filter

Context Filter 是 INFINI Gateway 提供的一种在线过滤器，能够根据请求上下文来过滤流量。通过定义一组匹配规则，可以灵活地对流量进行筛选。该过滤器支持多种匹配模式，包括：

• 前缀匹配
• 后缀匹配
• 模糊匹配
• 正则匹配

对于匹配到的请求，可以直接阻断（拒绝）并返回自定义的消息。因此，关键点就是要明确不合理请求的关键字信息。

使用步骤

1. 确定关键字信息：确定特殊查询请求中的关键特征或关键字。
2. 配置匹配规则：在 context_filter 中定义相应的匹配规则，选择合适的匹配模式（如前缀、后缀、模糊或正则匹配）。
3. 阻断请求：一旦匹配到这些关键字，INFINI Gateway 将自动阻断请求并返回指定的消息。

更多详细内容，请参阅相关 文档。

举个例子

阻止 wildcard 查询（模糊匹配查询），我们先看一个 wildcard 查询的样子。

GET yf-test-1shard/_search
{
  "query": {
    "wildcard": {
      "path.keyword": {
        "value": "/a*"
      }
    }
  }
}

上面的查询，会查询 path 字段，所有以 /a 开头的文档。

第一步：我们可确定关键字是 wildcard，为了进一步限制是 wildcard 查询里的情况，我们可将关键字确定为 wildcard":，因为有时候查询 url 里会有 expand_wildcards 字样。

第二步：编辑 INFINI Gateway 默认配置文件，增加 context_filter 匹配规则。

- name: default_flow
  filter:
    - context_filter:
        context: _ctx.request.to_string
        message: "Request blocked. Reason: Forbidden. Please contact the administrator at 010-111111."
        status: 403
        action: deny
        must_not:
          contain:
            - 'wildcard":'

通过上面的修改，我们在 INFINI Gatway 的默认处理流程开头添加了 context_filter 过滤器，阻止查询请求种带关键字 wildcard": 的查询，并返回消息"Request blocked. Reason: Forbidden. Please contact the administrator at 010-111111."

第三步，测试 wildcard 请求能否被阻断。

可以看到，INFINI Gateway 成功阻止了 wildcard 查询，并返回了我们定义的信息。通过此方法，我们可以阻断高消耗类查询被发送到 ES 集群，避免引发集群性能问题。对业务上合理的需求，我们可以进一步沟通，确定合理的方案。

关于极限网关（INFINI Gateway）

INFINI Gateway 是一个面向搜索场景的高性能数据网关，所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway，可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

开源地址：https://github.com/infinilabs/gateway，如有相关问题或建议，欢迎提交 PR 或 Issue ！

作者：杨帆，极限科技（INFINI Labs）高级解决方案架构师、《老杨玩搜索》栏目 B 站 UP 主，拥有十余年金融行业服务工作经验，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。

有给 ES 系统导入过数据的小伙伴都知道，给一个正在执行查询的 ES 集群导入数据，可能会影响查询的响应时间。如果导入的数据量还比较大，那请将“可能”两个字去掉。这种操作通常被限定在业务低谷期执行，如果一定要立即操作，则必须非常小心控制写入速度，避免影响到业务查询。

INFINI Easysearch 从 1.8.0 版本开始引入了写入限速功能，靠引擎自身能力对写入速度进行限制。不仅听着简单，实际用起来一点也不麻烦，我们赶紧实战一把。

测试环境

INFINI Easyssearch 1.9.0，单节点集群。

测试方法

loadgen 压测 bulk 写入，每个请求写 1000 个文档，每次测试固定写入 500w 个文档。

./loadgen-linux-amd64 -config ../config/write-yf-test.yml -d 3000 -l 5000

请求示例

{"index": {"_index": "yf-test-1shard","_id": "$[[uuid]]"}}
{"ip": "127.0.0.1", "time": "$[[now_utc_lite]]", "method": "GET","path": "/abc", "http_ver": "1.1", "status_code": "200","body_bytes": "3498","agent": "curl","agent_ver": "7.71.1"}

测试基线

单节点不限速写入测试

压测单个索引，3 主，0 副，写入速度 3.8w docs/s

压测单个索引，1 主，0 副，写入速度 2.5w docs/s

同时压测两个索引，写入速度分别是 3w docs/s 和 1.8w docs/s

节点级别限速

基于引擎层实现的限速功能，支持动态开启。比如我想将节点每秒写入的文档数，限制在 10000 个每秒，直接这样设置：

PUT _cluster/settings
{
  "transient": {
    "cluster.throttle.node.write": true
    "cluster.throttle.node.write.max_requests": 10000,
    "cluster.throttle.node.write.action": "retry"
  }
}

压测单个索引，1 主，0 副，写入速度 1w docs/s

压测单个索引，3 主，0 副，写入速度 1w docs/s

由于是限制整个节点的速度，不论索引分片如何，节点的写入上限被限制在了 10000 个文档每秒。节点上的所有分片共享节点的写入限额。

同时压测两个索引，整个节点写入速度还是 10000 个文档每秒。由于我的压测程序对两个索引的写入量是一样的，所以两个索引各占一半。实际上如果两个索引写入压力不一样，就会有高低。

节点级限速适合对节点写入极限比较清楚的条件下，想在节点层面保障集群稳定，不想细分到具体索引的场景。

索引级别限速

索引级的限速可以针对特定索引进行写入限速，避免响其他索引的读写。在之前的不限速测试中，同时写入两个索引的情况下，yf-test-3shard 能达到每秒近 3w docs/s 的写入速度，另一个索引 yf-test-1shard 能达到每秒近 1.8w docs/s 的写入速度。

接下来，我们只对 yf-test-3shard 进行限速。在索引的设置里配置相应的限流阈值：

PUT yf-test-3shard/_settings
{
    "index.throttle.write.max_requests": 2000,
    "index.throttle.write.action": "retry",
    "index.throttle.write.enable": true
}

限速设置在索引设置里查看到。

设置完限速后同时压测两个索引，yf-test-3shard 索引被限制在了 2000 docs/s 的速度，yf-test-1shard 则有更多的资源写入，达到了 2.3w docs/s 的写入速度，比之前不限速的时候稍高。

通过索引级限速功能，我们成功地限制了索引 yf-test-3shard 的写入速度，索引 yf-test-1shard 的写入并未受到影响。

分片级别限速

分片级限流功能，可限定单个分片允许最大写入速度。它不针对哪个索引，而是针对所有分片。比如我想限制每个分片每秒最多写 2000 个文档。

PUT _cluster/settings
{
  "transient": {
    "cluster.throttle.shard.write": true,
    "cluster.throttle.shard.write.max_requests": 2000,
    "cluster.throttle.shard.write.action": "retry"
  }
}

压测单个索引，1 主，0 副

1 个分片，写入速度 2000 个文档每秒。

压测单个索引，3 主，0 副

3 个分片，写入速度 6000 个文档每秒。

不论是哪个索引，全都限定一个分片 2000 的写入速度。我想这种限速比较适合一个集群中有高低配置混搭主机的场景，高配机器性能强悍，磁盘空间也大，分布的分片也多；低配主机性能和磁盘容量都有限，分布的分片数较少。你们说呢？

注意事项

节点级别限流是针对所有 DataNode。

分片级别限流只计算从协调节点分发到数据节点主分片的 bulk 请求。

节点级别和分片级别限流不冲突，可以同时启用。

限流功能不会限制系统索引流量，只针对业务索引。