Easysearch 版 analysis-ik 相比开源 IK 有一个重要的增强：支持多词典。简单说就是不同字段可以挂不同词库，可以叠加默认词典，也可以只用自定义词典。这是开源单词典 IK 做不到的。

功能实现初期，主要精力放在把能力跑通上。但在后来的一次写入压测中，我们发现 Easysearch 的写入吞吐和 Elasticsearch 有明显差距，最终定位到问题出在多词典的实现方式上——字段最终该用哪套词典，本来应该在分词前就算好，结果代码里把这个选择丢进了分词的热路径，每次分词都要反复切词典、重复扫同一段文本。

这篇文章记录的就是我们怎么一步步把性能拉回来、最终反超基线的过程。

问题怎么冒出来的

4 月 20 号，我们跑了一轮系统级写入压测。数据、mapping、settings、并发和 bulk 参数都一样，Elasticsearch 8.19.5 和 Easysearch 2.1.2 的写入吞吐差距大得有点不对劲：

当时服务器上跑的就是早期多词典版本。后面修性能，追的就是这个版本和开源单词典 IK 基线之间的差距。

这一步还不能直接确定问题就在分词器。但差距摆在这儿了，得继续往下排。我们先排除了几个常见干扰因素：

• refresh_interval
• 动态同义词 HTTP 服务
• mapping / settings 不一致
• 网络层和 bulk 客户端本身

采样结果很快把范围收窄了。Elasticsearch 那边热点比较分散，Easysearch 这边呢，分词链路里出现了异常集中的开销——分词过程中反复做词典选择和字典查找。

瓶颈不在 Lucene 写入链路本身，就在 analysis-ik 的多词典实现上。

根因分析

第一类问题出在实现模型上。多词典想表达的是”这个字段最终用哪套词典”，这件事完全可以在分词前算好。但早期代码里，硬是把它变成了运行时的事：

• “字段用哪个词典”变成了”运行时多轮扫描”——同一段文本对着多套词典各来一遍。
• 全局字典切换的动作放进了每字符的热路径。
• 结果就是同一段文本的扫描和查找成本翻了好几倍。

所以问题不是多词典天然慢，是实现把本该提前算好的东西塞进了热路径反复做。

第二类问题是后续优化过程中留下的额外开销。后面加的跨边界、停用词、长文本等测试本身不是性能问题的来源，它们的作用是把正确性边界补齐，确保每次优化不会改变分词结果。

最后通过性能分析确认，残留开销主要来自两处：缓存命中前还在做不必要的数据复制；诊断逻辑在生产热路径上产生了额外开销。修完之后这两处热点都从火焰图上消失了，说明性能回退确实来自真实的代码路径成本，不是测试抖动。

修复过程

整个修复分四个阶段。

第一阶段：把多词典从”运行时分发”收敛为”最终有效词典视图”

多词典能力保留，但不再让分词器在热路径里反复切词典、重复扫文本。改成在分词前就把字段最终生效的词典算好，分词过程只面对一个已经收敛好的词典视图。

说白了就是把模型拉回正确方向——多词典管表达能力，热路径只管分词。

第二阶段：逐步打掉热路径上的常数开销

留下来的每一项优化，都经过正式性能测试和采样分析验证。原则就一条：不改分词语义，只减少热路径上反复发生的查找、分配和判断。

第三阶段：补齐正确性护栏

正确性测试必须先到位，不然吞吐提升没有意义——万一分词结果变了，跑得再快也白搭。

这一轮重点覆盖了这些容易出问题的场景：

• 真跨边界场景
• 数字和量词合并，如 1号
• 自定义词典里的含符号词
• 补充平面字符跨边界稳定性
• 停用词过滤后的偏移量
• 长文本样本的稳定性
• 正式性能测试数据集的分词结果对齐

后面所有的吞吐数字，前提都是分词结果一致，避免把分词行为的变化误当成性能提升。

第四阶段：清理最后的残留开销

到 4 月 28 号，最后一轮修复集中处理两个地方：

• 词典视图命中缓存时直接返回，不再多做一次数据复制
• 诊断逻辑默认关掉，不让线上请求为调试能力买单

这两处修完，Easysearch 版 IK 就不只是恢复到单词典版本附近了，在正式测试里已经明显领先。

用数据看恢复过程

为了不把系统级写入压测和分词器性能测试混在一起，下面只看几个关键节点。2026-04-20 的 docs/s 是系统级写入吞吐，后面的 tok/s 是单独的分词器吞吐。

这里说的”开源 IK 基线”就是开源 IK 的单词典实现对照版本。所有正式吞吐结论都建立在同一数据集、同一测试方法、分词结果一致的前提上。

整个过程就是：

• 先暴露出明显的性能退化
• 逐步缩小差距
• 追平，然后开始领先
• 最终在分词结果完全一致的前提下，正式反超

最早的本地复现数据很关键：服务器当时跑的多词典版本只有 613896.67 tok/s，单词典版本 1144843.77 tok/s。后面所有修复就是冲着这个差距去的。

三张图分别对应问题暴露、分词复现和修复结果：第一张展示服务器 bulk 写入吞吐的系统级差距；第二张展示多词典版本和单词典版本的本地分词差距；第三张展示分词结果对齐后，Easysearch 版 IK 怎么一步步追上来，最终实现 25%~30% 的分词性能提升。

为什么说 Easysearch 版 IK 现在更好

这次修复的价值不只是消灭了几个热点，更重要的是把多词典能力、分词正确性和性能测试体系一起补齐了。

1. 功能更强，性能代价可控

开源单词典 IK 模型简单，但表达能力也弱。Easysearch 的多词典能力要解决的是字段级词库隔离、自定义词典叠加这些实际需求。

关键问题是：能不能把这些能力的性能开销压到足够低。修复后的结果证明，可以。

2. 正确性护栏更完整

这轮补上的测试不只是几个短样例，覆盖了更容易翻车的边界条件：

• 真跨边界场景
• 长文本稳定性
• 自定义词典和符号词
• 数字量词合并
• 停用词过滤后的偏移量

这意味着以后再做性能优化，必须同时保证分词结果不变。想靠改分词行为换吞吐，测试会先拦住。

3. 性能测试体系更严格

这轮之后，Easysearch 对 analysis-ik 的正式性能结论统一按一套标准出：

• 同一数据集
• 同一测试方法
• smart 和 max_word 双模式
• 分词结果一致
• 有性能分析结果支撑

这套体系能避免两个常见坑：只看单轮吞吐波动就下结论，或者分词结果已经变了还在比性能。

小结

多词典能力在实现初期，主要精力放在功能补齐上——先把字段级词库隔离、自定义词典叠加这些能力跑通，性能优化是后面分阶段来的事，没办法一蹴而就。

这轮优化下来，核心思路其实就一条：把词典选择从分词热路径里挪出去，提前收敛好，让分词过程只面对最终的词典视图。再配合热点清理和正确性护栏，增强功能和更高性能完全可以兼得。

截至 2026 年 4 月 28 日，在本地 Mac 笔记本上的多轮 benchmark 中，Easysearch 版 IK 在 smart 模式大约领先开源单词典 IK 基线 25%~30%，max_word 模式大约领先 20% 左右，分词结果完全一致。具体数字每次跑会有波动，但趋势是稳定的。

这也是 Easysearch 版 IK 相对开源版更有价值的地方：不是多了几个配置项，而是在多词典能力、分词正确性和分词性能三个方面都给出了可验证的结果。

关于 Easysearch

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

官网：https://easysearch.cn

作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。

相关文章：

• 开源 IK 分词器
• IK 字段级别词典的升级之路
• IK 字段级别词典升级：IK reload API
• Easysearch 新功能： IK 字段级别词典

之前介绍 IK 字段级别字典 使用的时候，对于字典的更新只是支持词典库的新增，并不支持对存量词典库的修改或者删除。经过这段时间的开发，已经可以兼容词典库的更新，主要通过 IK reload API 来实现。

IK reload API

IK reload API 通过对词典库的全量重新加载来实现词典库的更新或者删除。用户可以通过下面的命令实现：

# 测试索引准备

PUT my-index-000001
{
  "settings": {
    "number_of_shards": 3,
    "analysis": {
      "analyzer": {
        "my_custom_analyzer": {
          "type": "custom",
          "tokenizer": "my_tokenizer"
        }
      },
      "tokenizer": {
        "my_tokenizer": {

          "type": "ik_smart",
          "custom_dict_enable": true,
          "load_default_dicts":false, # 这里不包含默认词库
          "lowcase_enable": true,
          "dict_key": "test_dic"
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "test_ik": {
        "type": "text",
        "analyzer": "my_custom_analyzer"
      }
    }
  }
}

# 原来词库分词效果，只预置了分词“自强不息”
GET my-index-000001/_analyze
{
  "analyzer": "my_custom_analyzer",
  "text":"自强不息，杨树林"
}

{
  "tokens": [
    {
      "token": "自强不息",
      "start_offset": 0,
      "end_offset": 4,
      "type": "CN_WORD",
      "position": 0
    },
    {
      "token": "杨",
      "start_offset": 5,
      "end_offset": 6,
      "type": "CN_CHAR",
      "position": 1
    },
    {
      "token": "树",
      "start_offset": 6,
      "end_offset": 7,
      "type": "CN_CHAR",
      "position": 2
    },
    {
      "token": "林",
      "start_offset": 7,
      "end_offset": 8,
      "type": "CN_CHAR",
      "position": 3
    }
  ]
}

# 更新词库
POST .analysis_ik/_doc
{
  "dict_key": "test_dic",
  "dict_type": "main_dicts",
  "dict_content":"杨树林"
}
# 删除词库，词库文档的id为coayoJcBFHNnLYAKfTML
DELETE .analysis_ik/_doc/coayoJcBFHNnLYAKfTML?refresh=true

# 重载词库
POST _ik/_reload
{}

# 更新后的词库效果
GET my-index-000001/_analyze
{
  "analyzer": "my_custom_analyzer",
  "text":"自强不息，杨树林"
}

{
  "tokens": [
    {
      "token": "自",
      "start_offset": 0,
      "end_offset": 1,
      "type": "CN_CHAR",
      "position": 0
    },
    {
      "token": "强",
      "start_offset": 1,
      "end_offset": 2,
      "type": "CN_CHAR",
      "position": 1
    },
    {
      "token": "不",
      "start_offset": 2,
      "end_offset": 3,
      "type": "CN_CHAR",
      "position": 2
    },
    {
      "token": "息",
      "start_offset": 3,
      "end_offset": 4,
      "type": "CN_CHAR",
      "position": 3
    },
    {
      "token": "杨树林",
      "start_offset": 5,
      "end_offset": 8,
      "type": "CN_WORD",
      "position": 4
    }
  ]
}

这里是实现索引里全部的词库更新。

也可以实现单独的词典库更新

POST _ik/_reload
{"dict_key":"test_dic”}

# debug 日志
[2025-07-09T15:30:29,439][INFO ][o.e.a.i.ReloadIK         ] [ik-1] 收到重载IK词典的请求，将在所有节点上执行。dict_key: test_dic, dict_index: .analysis_ik
[2025-07-09T15:30:29,439][INFO ][o.e.a.i.a.TransportReloadIKDictionaryAction] [ik-1] 在节点 [R6ESV5h1Q8OZMNoosSDEmg] 上执行词典重载操作，dict_key: test_dic, dict_index: .analysis_ik

这里传入的 dict_key 对应的词库 id。

对于自定义的词库存储索引，也可以指定词库索引的名称，如果不指定则默认使用 .analysis_ik

POST _ik/_reload
{"dict_index":"ik_index"}

# debug 日志
[2025-07-09T15:32:59,196][INFO ][o.e.a.i.a.TransportReloadIKDictionaryAction] [ik-1] 在节点 [R6ESV5h1Q8OZMNoosSDEmg] 上执行词典重载操作，dict_key: null, dict_index: test_ik
[2025-07-09T15:32:59,196][INFO ][o.w.a.d.ReloadDict       ] [ik-1] Reloading all dictionaries

注：

1. 更新或者删除词库重载后只是对后续写入的文档生效，对已索引的文档无效；
2. 因为用户无法直接更改 IK 内置的词库（即默认配置路径下的词库文件），因此 reload API 不会影响内置词库的信息。

相关阅读

• IK 字段级别词典的升级之路
• Easysearch 新功能： IK 字段级别词典

关于 IK Analysis

IK Analysis 插件集成了 Lucene IK 分析器，并支持自定义词典。它支持 Easysearch\Elasticsearch\OpenSearch 的主要版本。由 INFINI Labs 维护并提供支持。

该插件包含分析器：ik_smart 和 ik_max_word，以及分词器：ik_smart 和 ik_max_word

开源地址：https://github.com/infinilabs/analysis-ik

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

问题背景

今天早上，接到开发那边一个特殊的查询需求，在 Kibana 中搜索一个 json 类型日志中值为一个空大括号的键值对， 具体的日志示例如下：

{
    "clientIp": "10.111.121.51",
    "query": "{}",
    "serviceUrl": "/aaa/bbb/cc",
}

也就是说针对这个类型的日志过滤出 query 值为空的请求 "query": "{}", 开发同学测试了直接在 kibana 中查询这个字符串 "query": "{}" 根本查不到我们想要的结果。 我们使用的是 ELK 8.3 的全家桶， 这个日志数据使用的默认 standard analyzer 的分词器。

初步分析

我们先对这个要查询的字符串进行下分词测试：

GET /_analyze
{
"analyzer" : "standard",
"text": "\"query\":\"{}\""
}

结果不出所料，我们想要空大括号在分词的时候直接就被干掉了，仅保留了 query 这一个 token：

{
  "tokens": [{
    "token": "query",
    "start_offset": 1,
    "end_offset": 6,
    "type": "<ALPHANUM>",
    "position": 0
  }]
}

我们使用的 standard analyzer 在数据写入分词时直接抛弃掉{}等特殊字符，看来直接搜索 "query": "{}" 关键词这条路肯定是走不通。

换个思路

在网上搜索了一下解决的办法，有些搜索特殊字符的办法,但需要修改分词器，我们已经写入的日志数据量比较大，不太愿意因为这个搜索请求来修改分词器再 reindex。 但是我们的日志格式是固定的，serviceUrl 这个键值对总是在 query 后面的，那么我们可以结合前后文实现相同的 搜索效果：

GET /_analyze
{
"analyzer" : "standard",
"text": "\"query\":\"{}\",\"serviceUrl\""
}

可以看到这段被分为 2 个相邻的单词

{
"tokens": [{
"token": "query",
"start_offset": 1,
"end_offset": 6,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "serviceurl",
"start_offset": 14,
"end_offset": 24,
"type": "<ALPHANUM>",
"position": 1
}
]
}

那么通过搜索 query 和 serviceUrl 为相邻的 2 个字是完全可以实现 query 的值为空的同样的查询效果。 为了确认在我们已经写入的数据中 query 和 serviceurl 也是相邻的，我们通过 ES termvectors API 确认了已经在 es 中的数据和我们这里测试的情况相同：

GET /<index>/_termvectors/<_id>?fields=message

"query" : {
  "term_freq" : 1,
  "tokens" : [
    {
      "position" : 198,
      "start_offset" : 2138,
      "end_offset" : 2143
    }
  ]
},
"serviceurl" : {
  "term_freq" : 1,
  "tokens" : [
    {
      "position" : 199,
      "start_offset" : 2151,
      "end_offset" : 2161
    }
  ]
},

这里我们可以看到 query 在 message 字段里面出现一次，其 end_offset 和 serviceurl 的 start_offset 之前也是相差 8， 和我们测试的结果相同。 这个时候我们就将原来的查询需求，转化为了对 "query serviceurl" 进行按顺序的精准查询就行了， 使用 match_phrase 可以达到我们的目的。

GET /_search
"query": {
    "match_phrase": {
        "message": {
            "query": "query serviceurl",
            "slop" : 0

        }
    }
}

这里顺便说一下，slop 这个参数，slop=n 表示，表示可以隔 n 个字(英文词)进行匹配, 这里设置为 0 就强制要求 query 和 serviceurl 这 2 个单词必须相邻，0 也是 slop 的默认值，在这个请求中是可以省略的，这是为什么 match_phrase 是会获得精准查询的原因之一。 好了，我们通过 console 确定了有效的 query 之后，对于开发同学查看日志只需要在 Kibana 的搜索栏中直接使用双引号引起来的精确搜索 "query serviceurl" 就可以了。

继续深挖一下，ngram 分词器

虽然开发同学搜索的问题解决了，但我仍然不太满意，毕竟这次的问题我们的日志格式是固定的，如果我们一定要搜索到 "query": "{}" 这个应该怎么办呢？ 首先很明确，使用我们默认的 standard analyzer 不修改任何参数肯定是不行的，"{}" 这些特殊字符都直接被干掉了， 参考了网上找到的这篇文章，https://blog.csdn.net/fox_233/article/details/127388058 按照这个 ngram 分词器的思路，我动手对我们的需求进行了下测试

首先先看看我们使用 ngram 分词器的分词效果， 我们这里简化了一下，去掉了原来的双引号，以避免过多 \:

GET _analyze
{
  "tokenizer": "ngram",
  "text": "query:{}"
}

{
  "tokens" : [
    {
      "token" : "q",
      "start_offset" : 0,
      "end_offset" : 1,
      "type" : "word",
      "position" : 0
    },
    ...
    {
      "token" : "{",
      "start_offset" : 6,
      "end_offset" : 7,
      "type" : "word",
      "position" : 12
    },
    {
      "token" : "{}",
      "start_offset" : 6,
      "end_offset" : 8,
      "type" : "word",
      "position" : 13
    },
    {
      "token" : "}",
      "start_offset" : 7,
      "end_offset" : 8,
      "type" : "word",
      "position" : 14
    }
  ]
}

可以很明显的看到大括号被成功的分词了，果然是有戏。 直接定义一个 index 实战一下搜索效果

PUT specialchar_debug
{
  "settings": {
    "analysis": {
      "analyzer": {
        "specialchar_analyzer": {
          "tokenizer": "specialchar_tokenizer"
        }
      },
      "tokenizer": {
        "specialchar_tokenizer": {
          "type": "ngram",
          "min_gram": 1,
          "max_gram": 2
        }
      }
    }
  },
  "mappings": {
      "properties": {
        "text": {
          "analyzer": "specialchar_analyzer",
          "type": "text"
        }
      }
    }
}

插入几条测试数据：

PUT specialchar_debug/_doc/1
{  "text": "query:{},serviceUrl"
}

PUT specialchar_debug/_doc/2
{  "text": "query:{aaa},serviceUrl"
}

PUT specialchar_debug/_doc/3
{  "text": "query:{bbb}, ccc, serviceUrl"
}

我们再测试一下搜索效果，

GET specialchar_debug/_search
{
  "query": {
    "match_phrase": {
      "text": "query:{}"
    }
  }
}

结果完全是我们想要的，看来这个方案可行

"hits" : [
  {
    "_index" : "specialchar_debug",
    "_id" : "1",
    "_score" : 2.402917,
    "_source" : {
      "text" : "query:{},serviceUrl"
    }
  }
]

小结

对于日志系统，我们一直在使用 ES 默认的 standard analyzer 的分词器， 基本上满足我们生产遇到的 99% 的需求，但面对特殊字符的这种搜索请求，确实比较无奈。这次遇到的空键值对的需求，我们通过搜索 2 个相邻的键绕过了问题。 如果一定要搜索这个字符串的话，我们也可以使用 ngram 分词器重新进行分词再进行处理， 条条大路通罗马。

作者介绍

卞弘智，研发工程师，10 多年的 SRE 经验，工作经历涵盖 DevOps，日志处理系统，监控和告警系统研发，WAF 和网关等系统基础架构领域，致力于通过优秀的开源软件推动自动化和智能化基础架构平台的演进。