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

冷热架构

冷热架构其实就是在 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