在之前的文章中，我们介绍了如何使用索引生命周期策略来管理索引。如果要求索引根据其生命周期阶段自动在不同的节点之间迁移，还需要用到冷热架构。我们来看看具体如何实现。

冷热架构

冷热架构其实就是在 Easyearch 集群中定义不同属性的节点，这些节点共同组成冷热架构。比如给所有热节点一个 hot 属性，给所有冷节点一个 cold 属性。在 Easyearch 中分配节点属性是通过配置文件(easysearch.yml)来实现的，比如我要定义一个热节点和一个冷节点，我可以在对应节点的配置文件中添加如下行：

# 热节点添加下面的行
node.attr.temp: hot

# 冷节点添加下面的行
node.attr.temp: cold

有了这些属性，我们就可以指定索引分片在分配时，是落在 hot 节点还是 cold 节点。

查看节点属性

测试环境是个 2 节点的 Easysearch 集群。

比如我创建新索引 test-index，希望它被分配到 hot 节点上。

PUT test-index
{
  "settings": {
    "number_of_replicas": 0,
    "index.routing.allocation.require.temp": "hot"
  }
}

可以看到 test-index 索引的分片分配到 hot 节点 node-1 上。我们修改索引分配节点的属性，让其移动到 cold 节点 node-2 上。

PUT test-index/_settings
{
  "settings": {
    "index.routing.allocation.require.temp": "cold"
  }
}

生命周期与冷热架构

在上面的例子中，我们通过索引分配节点属性对索引“坐落”的节点进行了控制。在索引生命周期策略中也支持对该属性进行修改，实现索引根据生命周期阶段自动在不同的节点之间移动的目的。

比如我们定义一个简单的索引策略：

• 索引创建后进入 hot 阶段，此阶段的索引被分配到 hot 节点
• 创建索引 3 分钟后，索引进入 cold 阶段，此阶段索引分片移动到 cold 节点

创建策略

PUT _ilm/policy/ilm_test
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0m",
      },
      "cold": {
        "min_age": "3m",
        "actions": {
          "allocate" : {
            "require" : {
              "temp": "cold"
            }
          }
        }
      }
    }
  }
}

生命周期策略后台是定期触发的任务，为了更快的观测到效果，可以修改任务触发周期为每分钟 1 次。

PUT _cluster/settings
{
  "transient": {
    "index_lifecycle_management.job_interval":"1"
    }
}

创建索引模板

创建完索引生命周期策略，还需要索引模板把索引和生命周期策略关联起来。我们创建一个模板把所有 ilm_test 开头的索引与 ilm_test 生命周期策略关联，为了便于观察，指定索引没有副本分片。

PUT _template/ilm_test
{
    "order" : 100000,
    "index_patterns" : [
      "ilm_test*"
    ],
    "settings" : {
      "index" : {
        "lifecycle" : {
          "name" : "ilm_test"
        },
        "number_of_replicas" : "0",
        "routing.allocation.require.temp": "hot"
      }
    }
  }

创建索引

创建一个 ilm_test 开头的索引，应用上一步创建的索引模板。

POST ilm_test_1/_doc
{
  "test":"test"
}

查看索引分片分配情况。

目前索引存储在 node-1 节点，按计划 3 分钟后将会移动到 node-2 上。

至此我们已通过索引生命周期策略实现了索引分片的移动，其实支持的操作还有很多，比如: rollover、close、snapshot 等，详情请参阅官方文档。

有任何问题，欢迎加我微信沟通。

关于 Easysearch

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

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

背景问题

前阵子，社区有小伙伴在使用 Easysearch 的数据压缩功能时发现，在开启 source_reuse 和 ZSTD 后，一个字段的内容看不到了。

索引的设置如下：

{
    ......
    "settings": {
      "index": {
        "codec": "ZSTD",
        "source_reuse": "true"
      }
    },
    "mappings": {
      "dynamic_templates": [
        {
          "message_field": {
            "path_match": "message",
            "mapping": {
              "norms": false,
              "type": "text"
            },
            "match_mapping_type": "string"
          }
        },
        {
          "string_fields": {
            "mapping": {
              "norms": false,
              "type": "text",
              "fields": {
                "keyword": {
                  "ignore_above": 256,
                  "type": "keyword"
                }
              }
            },
            "match_mapping_type": "string",
            "match": "*"
          }
        }
      ]
      ......
}

然后产生的一个多字段内容能被搜索到，但是不可见。

类似于下面的这个情况：

原因分析

我们先来看看整个字段展示经历的环节：

1. 字段写入索引的时候，不仅写了 text 字段也写了 keyword 字段。
2. keyword 字段产生倒排索引的时候，会忽略掉长度超过 ignore_above 的内容。
3. 因为开启了 source_reuse,_source 字段中与 doc_values 或倒排索引重复的部分会被去除。
4. 产生的数据文件进行了 ZSTD 压缩，进一步提高了数据的压缩效率。
5. 索引进行倒排或者 docvalue 的查询，检索到这个文档进行展示。
6. 展示的时候通过文档 id 获取 _source或者docvalues_fields的内容来展示文本，但是文本内容是空的。

其中步骤 4 中的 ZSTD 压缩，是作用于数据文件的，并不对数据内容进行修改。因此，我们来专注于其他环节。

问题复现

首先，这个字段索引的配置也是一个 es 常见的设置，并不会带来内容显示缺失的问题。

            "mapping": {
              "type": "text",
              "fields": {
                "keyword": {
                  "ignore_above": 256,
                  "type": "keyword"
                }
              }
            },

那么，source_reuse 就成了我们可以重点排查的环节。

source 发生了什么

source_reuse 的作用描述如下：

source_reuse： 启用 source_reuse 配置项能够去除 _source 字段中与 doc_values 或倒排索引重复的部分，从而有效减小索引总体大小，这个功能对日志类索引效果尤其明显。

source_reuse 支持对以下数据类型进行压缩：keyword，integer，long，short，boolean，float，half_float，double，geo_point，ip， 如果是 text 类型，需要默认启用 keyword 类型的 multi-field 映射。 以上类型必须启用 doc_values 映射（默认启用）才能压缩。

这是一个对 _source 字段进行产品化的功能实现。为了减少索引的存储体量，简单粗暴的操作是直接将_source字段进行关闭，利用其他数据格式去存储，在查询的时候对应的利用 docvalue 或者 indexed 去展示文本内容。

那么 _source关闭后，会不会也有这样的问题呢？

测试的步骤如下：

# 1. 创建不带source的双字段索引

PUT test_source
{
  "mappings": {
    "_source": {
      "enabled": false
    },
    "properties": {
      "msg": {
        "type": "text",
        "fields": {
          "keyword": {
            "ignore_above": 256,
            "type": "keyword"
          }
        }
      }
    }
  }
}

# 2. 写入测试数据

POST test_source/_doc/1
{"msg":"""[08-27 14:28:45] [DBG] [config.go:273] config contain variables, try to parse with environments
[08-27 14:28:45] [DBG] [config.go:214] load config files: []
[08-27 14:28:45] [INF] [pipeline.go:419] creating pipeline: pipeline_logging_merge
[08-27 14:28:45] [INF] [pipeline.go:419] creating pipeline: ingest_pipeline_logging
[08-27 14:28:45] [INF] [pipeline.go:419] creating pipeline: async_messages_merge
[08-27 14:28:45] [INF] [pipeline.go:419] creating pipeline: metrics_merge
[08-27 14:28:45] [INF] [pipeline.go:419] creating pipeline: request_logging_merge
[08-27 14:28:45] [INF] [pipeline.go:419] creating pipeline: ingest_merged_requests
[08-27 14:28:45] [INF] [pipeline.go:419] creating pipeline: async_ingest_bulk_requests
[08-27 14:28:45] [INF] [module.go:159] started module: pipeline
[08-27 14:28:45] [DBG] [module.go:163] all system module are started
[08-27 14:28:45] [DBG] [floating_ip.go:348] setup floating_ip, root privilege are required
[08-27 14:28:45] [DBG] [queue_config.go:121] init new queue config:e60457c6eae50a4eabbb62fc1001dccc,bulk_requests
[08-27 14:28:45] [DBG] [queue_config.go:121] init new queue config:e60457c6eae50a4eabbb62fc1001dccc,bulk_requests
[08-27 14:28:45] [DBG] [queue_config.go:121] init new queue config:e60457c6eae50a4eabbb62fc1001dccc,bulk_requests
[08-27 14:28:45] [DBG] [processor.go:139] generated new processors: indexing_merge
[08-27 14:28:45] [DBG] [pipeline.go:466] processing pipeline_v2: metrics_merge
[08-27 14:28:45] [DBG] [processor.go:139] generated new processors: when
[08-27 14:28:45] [DBG] [pipeline.go:466] processing pipeline_v2: ingest_merged_requests
[08-27 14:28:45] [DBG] [processor.go:139] generated new processors: indexing_merge
[08-27 14:28:45] [DBG] [pipeline.go:466] processing pipeline_v2: request_logging_merge
[08-27 14:28:45] [DBG] [processor.go:139] generated new processors: indexing_merge
[08-27 14:28:45] [DBG] [pipeline.go:466] processing pipeline_v2: async_messages_merge
[08-27 14:28:45] [DBG] [processor.go:139] generated new processors: bulk_indexing
[08-27 14:28:45] [DBG] [pipeline.go:466] processing pipeline_v2: ingest_pipeline_logging
[08-27 14:28:45] [DBG] [queue_config.go:121] init new queue config:1216c96eb876eee5b177d45436d0a362,gateway-pipeline-logs
[08-27 14:28:45] [DBG] [processor.go:139] generated new processors: bulk_indexing
[08-27 14:28:45] [DBG] [processor.go:139] generated new processors: indexing_merge
[08-27 14:28:45] [DBG] [pipeline.go:466] processing pipeline_v2: pipeline_logging_merge
[08-27 14:28:45] [DBG] [pipeline.go:466] processing pipeline_v2: async_ingest_bulk_requests
[08-27 14:28:45] [DBG] [badger.go:110] init badger database [queue_consumer_commit_offset]
[08-27 14:28:45] [INF] [floating_ip.go:290] floating_ip entering standby mode
[08-27 14:28:45] [DBG] [badger.go:110] init badger database [dis_locker]
[08-27 14:28:45] [DBG] [time.go:208] refresh low precision time in background
[08-27 14:28:45] [DBG] [domain_actions.go:278] elasticsearch metadata [backup] was not found
[08-27 14:28:45] [DBG] [bulk_indexing.go:355] metadata for [backup] is nil
[08-27 14:28:50] [INF] [module.go:178] started plugin: floating_ip
[08-27 14:28:50] [INF] [module.go:178] started plugin: force_merge
[08-27 14:28:50] [DBG] [network.go:78] network io stats will be included for map[]
[08-27 14:28:50] [INF] [module.go:178] started plugin: metrics
[08-27 14:28:50] [INF] [module.go:178] started plugin: statsd
[08-27 14:28:50] [DBG] [entry.go:100] reuse port 0.0.0.0:7005
[08-27 14:28:50] [DBG] [metrics.go:205] collecting network metrics
[08-27 14:28:50] [DBG] [metrics.go:174] collecting instance metrics
[08-27 14:28:50] [DBG] [elasticsearch.go:128] init elasticsearch proxy instance: prod
[08-27 14:28:50] [DBG] [filter.go:103] generated new filters: when, elasticsearch
[08-27 14:28:50] [DBG] [entry.go:142] apply filter flow: [*] [/_bulk] [ filters ]
[08-27 14:28:50] [DBG] [entry.go:142] apply filter flow: [*] [/{any_index}/_bulk] [ filters ]
[08-27 14:28:50] [DBG] [elasticsearch.go:128] init elasticsearch proxy instance: prod
[08-27 14:28:50] [DBG] [filter.go:103] generated new filters: request_path_limiter, elasticsearch
[08-27 14:28:50] [INF] [module.go:178] started plugin: gateway
[08-27 14:28:50] [DBG] [module.go:182] all user plugin are started
[08-27 14:28:50] [INF] [module.go:184] all modules are started
[08-27 14:28:50] [INF] [app.go:556] gateway is up and running now.
[08-27 14:28:50] [DBG] [domain_actions.go:278] elasticsearch metadata [backup] was not found
[08-27 14:28:50] [DBG] [bulk_indexing.go:355] metadata for [backup] is nil
[08-27 14:28:55] [DBG] [domain_actions.go:278] elasticsearch metadata [backup] was not found
[08-27 14:28:55] [DBG] [bulk_indexing.go:355] metadata for [backup] is nil
[08-27 14:29:00] [DBG] [metrics.go:205] collecting network metrics
[08-27 14:29:00] [DBG] [metrics.go:174] collecting instance metrics
[08-27 14:29:00] [DBG] [domain_actions.go:278] elasticsearch metadata [backup] was not found
[08-27 14:29:00] [DBG] [bulk_indexing.go:355] metadata for [backup] is nil
[08-27 14:29:05] [DBG] [domain_actions.go:278] elasticsearch metadata [backup] was not found
[08-27 14:29:05] [DBG] [bulk_indexing.go:355] metadata for [backup] is nil
[08-27 14:29:10] [DBG] [metrics.go:205] collecting network metrics
[08-27 14:29:10] [DBG] [metrics.go:174] collecting instance metrics
[08-27 14:29:10] [DBG] [domain_actions.go:278] elasticsearch metadata [backup] was not found"""}

# 3. 查询数据
GET test_source/_search

此时，可以看到，存入的文档检索出来是空的

_source 字段是用于索引时传递的原始 JSON 文档主体。它本身未被索引成倒排（因此不作用于 query 阶段），只是在执行查询时用于 fetch 文档内容。

对于 text 类型，关闭_source，则字段内容自然不可被查看。

而对于 keyword 字段，查看_source也是不行的。可是 keyword 不仅存储source，还存储了 doc_values。因此，对于 keyword 字段类型，可以考虑关闭_source,使用 docvalue_fields 来查看字段内容。

测试如下：

# 1. 创建测试条件的索引
PUT test_source2
{
  "mappings": {
    "_source": {
      "enabled": false
    },
    "properties": {
      "msg": {
        "type": "keyword"

      }
    }
  }
}

# 2. 写入数据
POST test_source2/_doc
{"msg":"1111111"}

# 3. 使用 docvalue_fields 查询数据
POST test_source2/_search
{"docvalue_fields": ["msg"]}

# 返回结果
{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "test_source2",
        "_type": "_doc",
        "_id": "yBvTj5kBvrlGDwP29avf",
        "_score": 1,
        "fields": {
          "msg": [
            "1111111"
          ]
        }
      }
    ]
  }
}

在如果是 text 类型，需要默认启用 keyword 类型的 multi-field 映射。 以上类型必须启用 doc_values 映射（默认启用）才能压缩。这句介绍里，也可以看到 source_reuse 的正常使用需要 doc_values。_那是不是一样使用 doc_values 进行内容展示呢？既然用于 docvalue_fields 内容展示，为什么还是内容看不了（不可见）呢？_

keyword 的 ignore_above

仔细看问题场景里 keyword 的配置，它使用了 ignore_above。那么，会不会是这里的问题？

我们将 ignore_above 配置带入上面的测试，这里为了简化测试，ignore_above 配置为 3。为区分问题现象，这里两条长度不同的文本进去，一条为 11,一条为1111111，可以作为参数作用效果的对比。

# 1. 创建测试条件的索引,ignore_above 设置为3
PUT test_source3
{
  "mappings": {
    "_source": {
      "enabled": false
    },
    "properties": {
      "msg": {
        "type": "keyword",
        "ignore_above": 3
      }
    }
  }
}

# 2. 写入数据，
POST test_source3/_doc
{"msg":"1111111"}

POST test_source3/_doc
{"msg":"11"}

# 3. 使用 docvalue_fields 查询数据
POST test_source3/_search
{"docvalue_fields": ["msg"]}

# 返回内容
{
  "took": 363,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "test_source3",
        "_type": "_doc",
        "_id": "yhvjj5kBvrlGDwP22KsG",
        "_score": 1
      },
      {
        "_index": "test_source3",
        "_type": "_doc",
        "_id": "yxvzj5kBvrlGDwP2Nav6",
        "_score": 1,
        "fields": {
          "msg": [
            "11"
          ]
        }
      }
    ]
  }
}

OK! 问题终于复现了。我们再来看看作为关键因素的 ignore_above 参数是用来干嘛的。

ignore_above：任何长度超过此整数值的字符串都不应被索引。默认值为 2147483647。默认动态映射会创建一个 ignore_above 设置为 256 的 keyword 子字段。

也就是说，ignore_above 在（倒排）索引时会截取内容，防止产生的索引内容过长。

但是从测试的两个文本来看，面对在参数范围内的文档，docvalues 会正常创建，而超出参数范围的文本而忽略创建（至于这个问题背后的源码细节我们可以另外开坑再鸽，此处省略）。

那么，在 source_reuse 下，keyword 的 ignore_above 是不是起到了相同的作用呢？

我们可以在问题场景上去除 ignore_above，参数试试，来看下面的测试：

# 1. 创建测试条件的索引,使用 source_reuse，设置 ignore_above 为3
PUT test_source4
{
  "settings": {
    "index": {
      "source_reuse": "true"
    }
  },
  "mappings": {
    "properties": {
      "msg": {
        "type": "text",
        "fields": {
          "keyword": {
            "ignore_above": 3,
            "type": "keyword"
          }
        }
      }
    }
  }
}

# 2. 写入数据
POST test_source4/_doc
{"msg":"1111111"}

POST test_source4/_doc
{"msg":"11"}

# 3. 使用 docvalue_fields 查询数据
POST test_source4/_search

# 返回内容
{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "test_source4",
        "_type": "_doc",
        "_id": "",
        "_score": 1,
        "_source": {}
      },
      {
        "_index": "test_source4",
        "_type": "_doc",
        "_id": "zRv2j5kBvrlGDwP2_qsO",
        "_score": 1,
        "_source": {
          "msg": "11"
        }
      }
    ]
  }
}

可以看到，数据“不可见”的问题被完整的复现了。

小结

从上面一系列针对数据“不可见”问题的测试，我们可以总结以下几点：

1. 在 source_reuse 的压缩使用中，keyword 字段的 ignore_ablve 参数尽量使用默认值，不要进行过短的设置（这个 tip 已补充在 Easysearch 文档中）。
2. 在 source_reuse 是对数据压缩常见方法-关闭 source 字段的产品化处理，在日志压缩场景中有效且便捷，可以考虑多加利用。
3. keyword 的 ignore_above 参数，不仅超出长度范围不进行倒排索引，也不会写入 docvalues。

特别感谢：社区@牛牪犇群

更多 Easysearch 资料请查看 官网文档。

作者：金多安，极限科技（INFINI Labs）搜索运维专家，Elastic 认证专家，搜索客社区日报责任编辑。一直从事与搜索运维相关的工作，日常会去挖掘 ES / Lucene 方向的搜索技术原理，保持搜索相关技术发展的关注。
原文：https://infinilabs.cn/blog/2025/invisibility-in-easysearch-field/

INFINI Labs 产品更新发布！此次更新主要包括 Coco AI v0.8 新增窗口管理插件，新的插件类型 View，Linux 文件搜索以及更多的连接器；Easysearch v1.15 新增 UI 插件，提供了轻量级界面化管理功能，不再依赖第三方对集群进行管理，真正做到开箱即用，AI 插件正式提供混合搜索能力，结合了关键词搜索和语义搜索，以提升搜索相关性。

以下为详细更新介绍：

Coco AI v0.8

Coco AI 是一款完全开源、跨平台的企业级智能搜索与助手系统，专为现代企业打造。它通过统一搜索入口，连接企业内外部的异构数据源，融合大模型能力，帮助团队高效访问知识，智能决策协作。

Coco AI 本次详细更新记录如下：

Coco AI 客户端 v0.8

功能特性 (Features)

• 改进版本升级，跳过此版本的按钮
• 支持从本地安装插件
• 子插件的 JSON 现在也可以设置 platforms 字段
• 插件设置页面现在可以卸载插件
• 新增插件设置项 'hide_before_open'
• App 搜索索引 app 的名字，现在索引多种语言的 app 名字，英文、中文以及系统语言
• Debug 模式下，支持 context menu
• 为 Linux (GNOME/KDE) 实现文件搜索
• 实现 MacOS 窗口管理插件
• 新增插件类型 View
• 对于文件搜索的结果，现在可以打开文件所在的文件夹

问题修复 (Bug Fixes)

• 修复更新检查失败的问题
• 修复 web 组件，登录状态的问题
• 修复快捷键无法打开插件商店的问题
• 修复设置插件快捷键在 Windows 上崩溃的问题
• 修复无法通过 "coco://" deeplink 登录的问题
• MacOS 文件搜索，确保 mdfind 进程不会成为僵尸进程
• 修复设置窗口打开是空白的问题
• 尽最大努力，确保用户添加的 search path 中的文件会被 indexer 索引
• 修复 MacOS 某些 app 设置空的 CFBundleDisplayName/CFBundleName 导致 app 名字为空的问题

改进优化 (Improvements)

• 将 query_coco_fusion() 函数拆分
• 清理 tauri::AppHandle’s 类型的范型参数 R
• 检查各个安装渠道的 plugin.json 文件，确保合法
• 在 MacOS 上不再为窗口设置 CanJoinAllSpaces 的属性
• 修复 web 组件构建的问题
• 为第三方插件安装的过程上锁
• MacOS/iOS: 支持从 Assets.car 提取 app 图标，从而不再跳过它们
• 放宽 MacOS 文件搜索的条件，避免无法搜到的问题
• 确保 Coco app 在呼出时，不会拿 focus
• 对于 web 组件，跳过登录检查
• 对于 View 插件，处理 HTML 文件，使用 convertFileSrc()处理如下 2 个 tag："link[href]" and "img[src]"

Coco APP 相关截图

Coco AI 服务端 v0.8

重大变更(Breaking Changes)

• 更新语雀的文档 ID
• 重构数据源同步管理

功能特性 (Features)

• 支持通过路径层次方式访问数据源中的文档
• 处理文档搜索的 path_hierarchy 配置
• Confluence Wiki 连接器
• 为 Notion 连接器提取内容
• 新增网络存储连接器
• 新增 PostgreSQL 连接器
• 新增 MySQL 连接器
• 新增 GitHub 连接器
• 新增 飞书/Lark 连接器
• 新增 GitLab 连接器
• 新增 Salesforce 连接器
• 新增 Gitea 连接器
• 新增 MSSQL 连接器
• 新增 Oracle 连接器

问题修复 (Bug Fixes)

• 修正助手更新逻辑
• 生成唯一图标键以防止意外删除所有图标
• 在 Coco 服务器登录期间修改 access_token URL
• 修复 Web 小部件的权限问题
• 由于在搜索框中导入图标而导致的额外高度
• 全屏模式下页面滚动不工作
• 解决 API 令牌列表分页问题
• MSSQL 分页错误
• 修复 S3 连接器图标

改进优化 (Improvements)

• 移除未使用的 WebSocket API
• 为 Google Drive 添加缺失的根文件夹
• 更新创建/修改连接器页面上的默认连接器设置表单
• 调整数据源详情的标题
• 重构摘要处理器
• 为 Google Drive 添加缺失的文档
• 将 Easysearch 初始管理员密码更新为复杂规则
• 统一许可证头
• 更新默认数据源编辑页面
• 重构 OAuth 连接组件
• 将数据源列表的默认大小设置为 12
• 在设置中添加搜索设置
• 在集成全屏中支持页面模式
• 为列表项添加图标
• 重构非托管模式的 security API
• 支持通过路径层次方式访问 local_fs 连接器中的文档
• 支持通过路径层次方式访问 S3、网络驱动器、GitHub、GitLab 和 Gitee 连接器中的文档

Coco Server 相关截图

Easysearch v1.15

重大变更(Breaking Changes)

• 针对安全模块的角色名称进行规范，废弃不符合规范的角色
• 更新创建搜索管道的 API 的 json 结构和说明文档

功能特性 (Features)

• 新增 ui 插件，涵盖从集群，节点，索引，到分片等不同维度的监控和管理功能以及备份快照、跨集群复制、数据流、热点线程、限流限速配置等管理功能
• ai 插件正式提供混合搜索能力，结合了关键词搜索和语义搜索，以提升搜索相关性
• ai 插件正式提供混合搜索能力
• 允许动态的跨模板重用设置

改进优化 (Improvements)

• index-management 从 plugin 移动到 modules
• 精简证书错误时的日志输出
• 改进 search_pipeline 的统计指标
• 改进角色名称和描述
• 增加 数据流（Data streams）说明文档
• 更新搜索管道相关文档
• 去掉 ILM 配置索引的前缀，并兼容旧索引

Easysearch 新增的 UI 插件为 Easysearch 提供了轻量级界面化管理功能，不再依赖第三方对集群进行管理，真正做到开箱即用。 UI 相关截图如下：

更多详情请查看以下各产品的 Release Notes 或联系我们的技术支持团队！

• Coco AI App
• Coco AI Server
• INFINI Easysearch

期待反馈

欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（https://github.com/infinilabs） 中的对应项目中提交 Feature Request 或提交 Bug。

下载地址： https://infinilabs.cn/download

邮件：hello@infini.ltd

电话：(+86) 400-139-9200

Discord：https://discord.gg/4tKTMkkvVX

也欢迎大家微信扫码添加小助手（INFINI-Labs），加入用户群一起讨论交流。

关于极限科技（INFINI Labs）

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

官网：https://infinilabs.cn

极限科技诚招全职搜索运维工程师（Elasticsearch/Easysearch）！

欢迎搜索技术热爱者加入我们，共同打造高效、智能的搜索解决方案！

在招岗位介绍

岗位名称

搜索运维工程师（Elasticsearch/Easysearch）

Base：北京
薪资待遇：12-20K，五险一金，双休等

岗位职责

1. 负责客户现场的 Elasticsearch/Easysearch/OpenSearch 搜索引擎集群的日常维护、监控和优化，确保集群的高可用性和性能稳定;
2. 协助客户进行搜索引擎集群的部署、配置及版本升级;
3. 排查和解决 Elasticsearch/Easysearch/OpenSearch 集群中的各种技术问题，及时响应并处理集群异常;
4. 根据业务需求设计和实施搜索索引的调优、数据迁移和扩展方案;
5. 负责与客户沟通，提供技术支持及相关培训，确保客户需求得到有效满足;
6. 制定并实施搜索引擎的备份、恢复和安全策略，保障数据安全;
7. 与内部研发团队和外部客户进行协作，推动集群性能改进和功能优化。

岗位要求

1. 全日制本科及以上学历，2 年以上运维工作经验;
2. 拥有 Elasticsearch/Easysearch/OpenSearch 使用经验，熟悉搜索引擎的原理、架构和相关生态工具（如 Logstash、Kibana 等）;
3. 熟悉 Linux 操作系统的使用及常见性能调优方法;
4. 熟练掌握 Shell 或 Python 等至少一种脚本语言，能够编写自动化运维脚本;
5. 具有优秀的问题分析与解决能力，能够快速应对突发情况;
6. 具备良好的沟通能力和团队合作精神，能够接受客户驻场工作;
7. 提供 五险一金，享有带薪年假及法定节假日。

加分项

1. 计算机科学、信息技术或相关专业;
2. 具备丰富的大规模分布式系统运维经验;
3. 熟悉 Elasticsearch/Easysearch/OpenSearch 分片、路由、查询优化等高级功能;
4. 拥有 Elastic Certified Engineer 认证;
5. 具备大规模搜索引擎集群设计、扩展和调优经验;
6. 熟悉其他搜索引擎技术（如 Solr、Lucene）者优先;
7. 熟悉大数据处理相关技术（比如: Kafka 、Flink 等）者优先。

简历投递

1. 邮件：hello@infini.ltd（邮件标题请备注姓名 求职岗位）
2. 微信：INFINI-Labs （加微请备注求职岗位）

关于极限科技（INFINI Labs）

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

官网：https://infinilabs.cn

我们在做什么

极限科技（INFINI Labs）正在致力于以下几个核心方向：

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

2、打造下一代实时搜索引擎 INFINI Pizza INFINI Pizza 是一个分布式混合搜索数据库系统。我们的使命是充分利用现代硬件和人工智能的潜力，为企业提供量身定制的实时智能搜索体验。我们致力于满足具有挑战性的环境中高并发和高吞吐量的需求，同时提供无缝高效的搜索功能。详情参见：https://pizza.rs

3、为现代团队打造的统一搜索与 AI 智能助手 Coco AI Coco AI 是一款完全开源的统一搜索与 AI 助手平台，它通过统一搜索入口，连接企业内外部的异构数据源，融合大模型能力，帮助团队高效访问知识，智能决策协作。详情参见：https://coco.rs

4、积极参与全球开源生态建设 通过开源 Coco AI、Console、Gateway、Agent、Loadgen 等搜索领域产品和社区贡献，推动全球开源技术的发展，提升中国在全球开源领域的影响力。INFINI Labs Github 主页：https://github.com/infinilabs

5、提供专业服务 为客户提供包括搜索技术支持、迁移服务、定制解决方案和培训在内的全方位服务。

6、提供国产化搜索解决方案 针对中国市场的特殊需求，提供符合国产化标准的搜索产品和解决方案，帮助客户解决使用 Elasticsearch 时遇到的挑战。

极限科技（INFINI Labs）通过这些努力，旨在成为全球领先的实时搜索和数据分析解决方案提供商。

之前有博客介绍过通过 Reindex 的方法将 Elasticsearch 的数据迁移到 Easysearch 集群，今天再介绍一个方法，通过 极限网关（INFINI Gateway） 来进行数据迁移。

测试环境

迁移步骤

1. 选定要迁移的索引
2. 在目标集群建立索引的 mapping 和 setting
3. 准备 INFINI Gateway 迁移配置
4. 运行 INFINI Gateway 进行数据迁移

迁移实战

1. 选定要迁移的索引

在 Elasticsearch 集群中选择目标索引：infinilabs 和 test1，没错，我们一次可以迁移多个。

2. 在 Easysearch 集群使用源索引的 setting 和 mapping 建立目标索引。（略）
3. INFINI Gateway 迁移配置准备

去 github 下载配置，修改下面的连接集群的部分

  1 env:
  2   LR_GATEWAY_API_HOST: 127.0.0.1:2900
  3   SRC_ELASTICSEARCH_ENDPOINT: http://127.0.0.1:9200
  4   DST_ELASTICSEARCH_ENDPOINT: http://127.0.0.1:9201
  5 path.data: data
  6 path.logs: log
  7 progress_bar.enabled: true
  8 configs.auto_reload: true
  9
 10 api:
 11   enabled: true
 12   network:
 13     binding: $[[env.LR_GATEWAY_API_HOST]]
 14
 15 elasticsearch:
 16   - name: source
 17     enabled: true
 18     endpoint: $[[env.SRC_ELASTICSEARCH_ENDPOINT]]
 19     basic_auth:
 20       username: elastic
 21       password: goodgoodstudy
 22
 23   - name: target
 24     enabled: true
 25     endpoint: $[[env.DST_ELASTICSEARCH_ENDPOINT]]
 26     basic_auth:
 27       username: admin
 28       password: 14da41c79ad2d744b90c

pipeline 部分修改要迁移的索引名称，我们迁移 infinilabs 和 test1 两个索引。

 31 pipeline:
 32   - name: source_scroll
 33     auto_start: true
 34     keep_running: false
 35     processor:
 36       - es_scroll:
 37           slice_size: 1
 38           batch_size: 5000
 39           indices: "infinilabs,test1"
 40           elasticsearch: source
 41           output_queue: source_index_dump
 42           partition_size: 1
 43           scroll_time: "5m"

4. 迁移数据

./gateway-mac-arm64

#如果你保存的配置文件名称不叫 gateway.yml，则需要加参数 -config 文件名

数据导入完成后，网关 ctrl+c 退出。

至此，数据迁移就完成了。下一篇我们来介绍 INFINI Gateway 的数据比对功能。

有任何问题，欢迎加我微信沟通。

关于极限网关（INFINI Gateway）

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

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

大家好，我是 INFINI Labs 的石阳。

欢迎关注 《搜索百科》 专栏！每天 5 分钟，带你速览一款搜索相关的技术或产品，同时还会带你探索它们背后的技术原理、发展故事及上手体验等。

上一篇我们围观了 “流量明星” Elasticsearch — 从食谱搜索到 PB 级明星产品，从 Apache 2.0 到 SSPL 协议风波；今天我们来聊聊它的“分叉兄弟” OpenSearch。

引言

2021 年，当 Elasticsearch 宣布将其许可证从 Apache 2.0 变更为 SSPL/Elastic License 时，整个搜索社区为之震动。这一变更直接催生了一个新的开源分支 — OpenSearch。这个由 AWS 主导的项目不仅在短短几年内迅速发展成熟，更成为了许多企业在云原生环境下搜索解决方案的新选择。

OpenSearch 概述

OpenSearch 是从 Elasticsearch 7.10.2 分支而来的开源搜索与分析套件，由 AWS 主导开发并贡献给开源社区。OpenSearch 包括 OpenSearch（搜索引擎）和 OpenSearch Dashboards（可视化界面），完全兼容 Apache 2.0 协议，旨在为用户提供一个真正开源、社区驱动的搜索与分析解决方案。

• 首次发布：2021 年 4 月
• 最新版本：3.2.0（截止 2025 年 9 月）
• 开源协议：Apache License 2.0
• 主导企业：Amazon Web Services (AWS)
• 官方网址：https://opensearch.org/
• GitHub 仓库：https://github.com/opensearch-project

诞生故事：开源协议争议的产物

时间回到 2021 年 1 月，Elastic 公司宣布 Elasticsearch 从 7.11 版本起不再使用 Apache 2.0 协议，而改为 Elastic License 与 SSPL。这一决定立刻在社区和产业界引发巨大争议。

AWS（亚马逊云）作为 Elasticsearch 的重要用户与云服务提供商，不愿意被 Elastic 的商业条款所限制，随即牵头将 Elasticsearch 7.10 版本 fork 出来，并与 Kibana 一起重命名为 OpenSearch 与 OpenSearch Dashboards。

从此，开源世界分裂成了两条路线：

1. Elastic 官方的 Elasticsearch + Kibana（带有商业许可）。
2. 社区驱动的 OpenSearch + OpenSearch Dashboards（继续遵循 Apache 2.0 协议）。

这个分叉，既是开源协议之争的产物，也是云厂商与开源公司之间博弈的缩影。虽然初期被质疑过“是否真开源”，但经过数年的迭代，OpenSearch 已形成了相对独立的开发节奏和用户群体，插件和生态也逐渐丰富。

技术架构与特性

OpenSearch 是一个基于 Apache Lucene 的分布式搜索与分析引擎。在将数据添加到 OpenSearch 后，可以对其执行各种功能完备的全文搜索操作：按字段搜索、跨多个索引搜索、提升字段权重、按得分排序结果、按字段排序结果以及对结果进行聚合。

OpenSearch 的核心架构由集群、节点、索引、分片和文档组成。最高层是 OpenSearch 集群，它是由多个节点组成的分布式网络，每个节点会根据其类型负责不同的集群操作。数据节点负责存储索引（即文档的逻辑分组），并处理数据写入、搜索和聚合等任务。

每个索引会被划分为多个分片，分片包含主数据和副本数据。分片会分布在多台机器上，从而实现水平扩展，提升性能并高效利用存储资源。

OpenSearch vs Elasticsearch：详细对比

快速开始：5 分钟部署 OpenSearch

1. 使用 Docker 部署

# 拉取 OpenSearch 镜像
docker pull opensearchproject/opensearch:3.2.0

# 启动 OpenSearch 节点
docker run -d --name opensearch-node \
  -p 9200:9200 -p 9600:9600 \
  -e "discovery.type=single-node" \
  -e "plugins.security.disabled=true" \
  opensearchproject/opensearch:3.2.0

# 拉取 OpenSearch Dashboards
docker pull opensearchproject/opensearch-dashboards:3.2.0

# 启动 Dashboards
docker run -d --name opensearch-dashboards \
  -p 5601:5601 \
  -e "OPENSEARCH_HOSTS=http://opensearch-node:9200" \
  opensearchproject/opensearch-dashboards:3.2.0

2. 验证安装

# 检查集群状态
curl -X GET "http://localhost:9200/"

出现如下结果说明安装成功。

3. 创建索引和搜索

# 索引文档
curl -X POST "http://localhost:9200/my-first-index/_doc" -H 'Content-Type: application/json' -d'
{
  "title": "OpenSearch 入门指南",
  "content": "这是我在 OpenSearch 中的第一个文档",
  "timestamp": "2025-09-18T10:00:00"
}'

# 执行搜索
curl -X GET "http://localhost:9200/my-first-index/_search" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match": {
      "content": "第一个文档"
    }
  }
}'

4. 访问控制台

打开浏览器访问 http://localhost:5601 即可使用 OpenSearch Dashboards 界面。

结语

OpenSearch 的出现，是开源社区的一次“自救”。它不仅延续了 Elasticsearch 的核心功能，还代表了另一种治理模式：由云厂商和社区共同维护，保证了开源协议的延续。

在搜索技术的版图里，Elasticsearch 与 OpenSearch 的分叉，注定会成为一个重要的历史节点。未来，两者可能会继续竞争，也可能各自发展出独特的生态。

🚀 下期预告

下一篇我们将介绍 OpenSearch 的另一个兄弟 Easysearch，一个衍生自开源协议 Apache 2.0 的 Elasticsearch 7.10.2 版本的轻量级搜索引擎，作为一个 ES 国产替代方案，看看它如何以其极致的速度和易用性在国内搜索领域占据一席之地。

💬 三连互动

1. 您是否考虑过从 Elasticsearch 迁移到 OpenSearch？
2. 在开源协议方面，您更倾向于哪种模式？Apache 2.0 还是 Elastic 的多重许可？
3. 对于云厂商与开源项目之间的关系，您有什么看法？

对搜索技术感兴趣的朋友，也欢迎加我微信（ID：lsy965145175）备注“搜索百科”，拉你进  搜索技术交流群，一起探讨与学习！

✨ 推荐阅读

• 搜索百科（3）：Elasticsearch — 搜索界的"流量明星"
• 搜索百科（2）：Apache Solr — 企业级搜索的开源先锋
• 搜索百科（1）：Lucene — 打开现代搜索世界的第一扇门

🔗 参考资源

• OpenSearch 官方文档
• OpenSearch 与 Elasticsearch 功能对比

原文：https://infinilabs.cn/blog/2025/search-wiki-4-opensearch/

近年来，随着数据安全与自主可控需求的不断提升，越来越多的企业开始关注国产化的搜索与日志分析解决方案。作为极限科技推出的国产 Elasticsearch 替代产品，Easysearch 凭借其对搜索场景的深入优化、轻量级架构设计以及对 ES 生态的高度兼容，成为众多企业替代 Elasticsearch 的新选择。

我们在近期与用户的交流中，整理出了大家最关心的八大问题，并将它们浓缩为一篇技术解读，希望帮助你快速了解 Easysearch 的优势与定位。

用户最关心的八大问题

1. Easysearch 对数据量的支撑能力如何，能应对 PB 级数据存储吗？

答：完全可以。Easysearch 支持水平扩展，通过增加节点即可线性提升存储与计算能力。在实际应用中，已成功支撑 PB 级日志与检索数据。同时，其存储压缩率相比 Elasticsearch 7.10.2 平均高出 2.5~3 倍，显著节省硬件成本。

2. 在高并发写入场景下，Easysearch 和 ES 的性能差异有多大？

答：在相同硬件配置下，使用 Nginx 日志进行 bulk 写入压测，Easysearch 在多种分片配置下的写入性能相比 Elasticsearch 7.10.2 提升 40%-70%，更适合高并发写入场景。

3. 是否支持中文分词？需要额外插件吗？

答：中文分词一直是 Elasticsearch 用户的「必装插件」。而在 Easysearch 中，中文分词是开箱即用的，同时支持 ik、pinyin 等主流分词器，还能自定义词典，方便电商、内容平台等场景。

4. 从 ES 迁移到 Easysearch 是否复杂？会影响业务吗？

答：迁移往往是国产替代的最大顾虑。为此，Easysearch 提供了 极限网关 工具，支持全量同步和实时增量同步。迁移过程中业务可继续读写，只需短暂切换连接地址，几乎无感知。

5. 监控与运维工具是否完善？是否支持 Kibana？

答：Easysearch 提供完整的监控与运维体系。从 Easysearch 1.15.x 版本起自带 Web UI 管理控制台（类似简化版 Kibana），支持索引管理、查询调试、权限控制等功能。同时还提供 INFINI Console 实现多集群管理与深度监控等。也可以通过配置让 Kibana 连接 Easysearch（部分高级功能可能受限）。

6. 小型团队技术能力有限，用 Easysearch 运维难度高吗？

答：Easysearch 的一大设计理念就是降低运维门槛。Easysearch 提供一键部署脚本，减少手动配置参数，支持自动分片均衡与故障节点恢复，无需专职运维人员也能稳定运行，非常适合技术资源有限的团队。

7. Easysearch 是否支持数据备份与恢复？操作复杂吗？

答：支持快照（Snapshot），可备份到本地磁盘或对象存储（S3、OSS 等）。恢复时仅需执行快照恢复命令，满足企业级数据安全需求。

8. 对比 ES，Easysearch 在使用体验上最大的不同是什么？

答：Easysearch 保持与 Elasticsearch 类似的接口与查询 DSL，用户几乎无学习成本即可上手。同时，它针对国产化环境和搜索场景做了优化，运维更轻量，成本更可控。

结语：Easysearch，国产化搜索的新选择

作为一款国产自主可控的搜索与日志分析引擎，Easysearch 不仅继承了 Elasticsearch 的核心能力，更在性能、易用性、资源效率和中文支持等方面进行了深度优化。对于希望实现国产化替代、降低运维成本、提升系统性能的企业来说，Easysearch 是一个值得认真考虑的新选择。

如果你正在评估 Elasticsearch 的替代方案，不妨从 Easysearch 开始，体验更轻量、更高效的搜索新架构。

如需了解更多技术细节与使用案例，欢迎访问官方文档与社区资源：

1. Easysearch 官网文档
2. Elasticsearch VS Easysearch 性能测试
3. 使用 Easysearch，日志存储少一半
4. Kibana OSS 7.10.2 连接 Easysearch
5. 自建 ES 集群通过极限网关无缝迁移到云上
6. INFINI Console 一站式的数据搜索分析与管理平台