1、一文读懂 AI Search：从 RAG 到 DeepSearch
https://mp.weixin.qq.com/s/FpQErQRFaPTPqQd1LzkPVQ

2、搜索百科（4）：OpenSearch — 开源搜索的新选择
https://infinilabs.cn/blog/202 ... earch

3、SeaTunnel 迁移 MySQL 数据到 Easysearch 之批量导入（Batch）
https://blog.csdn.net/yangmf20 ... 24909

4、Elasticsearch向量检索（KNN）千万级耗时长问题分析与优化方案
https://blog.csdn.net/star1210 ... 61432

5、Easysearch 可视化升级：无需额外部署 UI 软件
https://blog.csdn.net/weixin_3 ... 15314

编辑：Fred
更多资讯：http://news.searchkit.cn

1、理解 Elasticsearch 中的分块策略
https://elasticstack.blog.csdn ... 72259

2、从 Uptime 到 Synthetics 在 Elastic 中的迁移手册
https://elasticstack.blog.csdn ... 84573

3、你的第一个 Elastic Agent：从单个查询到 AI 驱动的聊天
https://elasticstack.blog.csdn ... 14746

4、Elasticsearch 插件用于 UBI：在 Kibana 中分析用户数据
https://elasticstack.blog.csdn ... 59534

5、MCP 工具：自主代理的攻击向量与防御建议
https://elasticstack.blog.csdn ... 68195

编辑：Muse
更多资讯：http://news.searchkit.cn

长假快乐！
1. 手把手教你做个图片搜索引擎（爬梯）
https://medium.com/%40asirabde ... 6f309
2. 索引刷新的最差实践们（不是（爬梯）
https://blog.palantir.com/defe ... 52ff1
3. ES适合当数据库用吗？（爬梯）
https://www.paradedb.com/blog/ ... abase
 
编辑：斯蒂文
更多资讯：http://news.searchkit.cn
 


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 相关截图如下：
  
  
  
  图1：集群登录
  
  图2：集群概览
  
  图3：节点管理
  
  图4：索引管理
  
  图5：分片管理
  
  图6：开发工具
  
  图7：生命周期-新增策略
  
  图8：备份管理-新增备份策略
  
  
  更多详情请查看以下各产品的 Release Notes 或联系我们的技术支持团队！
  
  
• [Coco AI App](https://docs.infinilabs.com/co ... notes/)
  
• [Coco AI Server](https://docs.infinilabs.com/co ... notes/)
  
• [INFINI Easysearch](https://docs.infinilabs.com/ea ... earch/)
  
  

  期待反馈
  

  
  欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 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>;

## 背景问题

前阵子，社区有小伙伴在使用 [Easysearch](https://infinilabs.cn/products/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 资料请查看 [官网文档](https://docs.infinilabs.com/easysearch)。

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

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

冷热架构

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

```plain

热节点添加下面的行

node.attr.temp: hot

冷节点添加下面的行

node.attr.temp: cold
<br /> <br /> 有了这些属性，我们就可以指定索引分片在分配时，是落在 hot 节点还是 cold 节点。<br /> <br /> **查看节点属性**<br /> <br /> 测试环境是个 2 节点的 Easysearch 集群。<br /> <br /> ![](<a href="https://infinilabs.cn/img/blog/2025/easysearch-hot-warm-arch/1.pn" rel="nofollow" target="_blank">https://infinilabs.cn/img/blog ... /1.pn</a>g)<br /> <br /> 比如我创建新索引 test-index，希望它被分配到 hot 节点上。<br /> <br /> plain
PUT test-index
{
"settings": {
"number_of_replicas": 0,
"index.routing.allocation.require.temp": "hot"
}
}
<br /> <br /> ![](<a href="https://infinilabs.cn/img/blog/2025/easysearch-hot-warm-arch/2.pn" rel="nofollow" target="_blank">https://infinilabs.cn/img/blog ... /2.pn</a>g)<br /> <br /> 可以看到 test-index 索引的分片分配到 hot 节点 node-1 上。我们修改索引分配节点的属性，让其移动到 cold 节点 node-2 上。<br /> <br /> plain
PUT test-index/_settings
{
"settings": {
"index.routing.allocation.require.temp": "cold"
}
}
```


生命周期与冷热架构

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

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

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

  创建策略
  

  
  plain<br /> PUT _ilm/policy/ilm_test<br /> {<br /> "policy": {<br /> "phases": {<br /> "hot": {<br /> "min_age": "0m",<br /> },<br /> "cold": {<br /> "min_age": "3m",<br /> "actions": {<br /> "allocate" : {<br /> "require" : {<br /> "temp": "cold"<br /> }<br /> }<br /> }<br /> }<br /> }<br /> }<br /> }<br />
  
  生命周期策略后台是定期触发的任务，为了更快的观测到效果，可以修改任务触发周期为每分钟 1 次。
  
  plain<br /> PUT _cluster/settings<br /> {<br /> "transient": {<br /> "index_lifecycle_management.job_interval":"1"<br /> }<br /> }<br />
  
  

  创建索引模板
  

  
  创建完索引生命周期策略，还需要索引模板把索引和生命周期策略关联起来。我们创建一个模板把所有 ilm_test 开头的索引与 ilm_test 生命周期策略关联，为了便于观察，指定索引没有副本分片。
  
  plain<br /> PUT _template/ilm_test<br /> {<br /> "order" : 100000,<br /> "index_patterns" : [<br /> "ilm_test*"<br /> ],<br /> "settings" : {<br /> "index" : {<br /> "lifecycle" : {<br /> "name" : "ilm_test"<br /> },<br /> "number_of_replicas" : "0",<br /> "routing.allocation.require.temp": "hot"<br /> }<br /> }<br /> }<br />
  
  

  创建索引
  

  
  创建一个 ilm_test 开头的索引，应用上一步创建的索引模板。
  
  plain<br /> POST ilm_test_1/_doc<br /> {<br /> "test":"test"<br /> }<br />
  
  查看索引分片分配情况。
  
  
  
  目前索引存储在 node-1 节点，按计划 3 分钟后将会移动到 node-2 上。
  
  
  
  
  
  至此我们已通过索引生命周期策略实现了索引分片的移动，其实支持的操作还有很多，比如: rollover、close、snapshot 等，详情请参阅官方[文档](https://docs.infinilabs.com/ea ... D%259C)。
  
  有任何问题，欢迎加我微信沟通。
  
  
  
  

  关于 Easysearch
  

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