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 字段级别词典

从"用搜索"到"造搜索"

搜索系统的需求千差万别。标准功能覆盖不了所有场景——行业特定的分词规则、定制化的业务逻辑、与外部系统的深度集成……

以往，这类定制需求需要依赖厂商支持。从 Easysearch 2.1.2 开始，你可以自己动手了。

随着构建依赖库正式发布到 Maven 中央仓库，Easysearch 的插件开发能力正式对外开放。这意味着 Easysearch 不再是一个黑盒产品，而是一个可扩展、可定制的搜索平台。你可以基于官方接口开发自定义插件，像使用原生功能一样使用它们。

插件能做什么

Easysearch 提供三类核心扩展点，覆盖搜索系统的关键环节：

1. 分析器插件（AnalysisPlugin）

自定义分词器、Token 过滤器、字符过滤器。适用于：

• 电商 SKU 的型号规格解析
• 医疗、法律等领域的专业术语分词
• 特殊符号或空格的规范化处理

注册后直接在索引设置中使用，与原生分析器完全等同。

2. REST/API 插件（ActionPlugin）

新增自定义 HTTP 接口。适用于：

• 封装业务查询逻辑，对外暴露简化 API
• 对接企业内部权限中心或监控系统
• 暴露插件自身的管理接口（如状态检查）

3. Ingest 插件（IngestPlugin）

在文档写入前进行字段转换。适用于：

• 自定义业务字段转换（如根据业务规则计算衍生字段）
• 数据标准化（统一日期格式、大小写转换）
• 富文本提取或元数据生成

5 分钟上手

我们准备了官方模板仓库，让你从克隆到运行只需几条命令：

# 克隆模板
git clone https://github.com/infinilabs/easysearch-plugin-template.git my-plugin
cd my-plugin

# 修改包名和类名，编写你的逻辑
# ...

方式一：开发调试——直接运行

# 构建插件并运行
./gradlew run

# 验证插件
curl -s "http://localhost:9200/_cat/plugins?v" | grep my-plugin

方式二：构建后安装到外部集群

# 构建插件
./gradlew build

# 安装到 Easysearch
bin/easysearch-plugin install file:///$(pwd)/build/distributions/my-plugin-0.1.0.zip

# 启动验证
bin/easysearch
curl -s "http://localhost:9200/_cat/plugins?v" | grep my-plugin

完整的开发指南请参考插件开发文档。

设计哲学

Easysearch 插件系统的设计遵循三个原则：

渐进式扩展——从最简单的 Plugin 类开始，按需实现 AnalysisPlugin、ActionPlugin 等接口，不必一次性掌握全部 API。

与原生同等——插件注册的分析器、处理器与系统原生组件在使用方式上完全一致，用户无需关心实现来源。

版本安全——插件加载时校验 easysearch.version，版本不匹配会拒绝加载，避免运行时异常。

从插件到生态

插件开发不只是技术能力的开放，更是产品理念的转变。

你可以将开发的插件发布到 GitHub Releases，通过 URL 直接安装：

bin/easysearch-plugin install https://github.com/yourname/my-plugin/releases/download/v0.1.0/my-plugin-0.1.0.zip

我们也欢迎社区贡献。如果你有通用的插件想法，欢迎与我们交流。

结语

搜索系统的最后一公里，只有业务开发者最清楚该怎么走。

Easysearch 2.1.2 的插件开发能力，让你能够自主掌控搜索系统的"最后一公里"。从"用搜索"到"造搜索"，现在你可以让你的搜索系统真正"为你所用"。

关于 Easysearch

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

官网：https://easysearch.cn

INFINI Agent v1.31.0 带来了本版本最重要的特性——Easysearch 安装向导。用户无需手动编辑任何配置文件，通过图形界面即可完成 Easysearch 集群的安装、配置和日常管理。

Easysearch 安装向导

一键拉起新集群

向导支持开发模式和生产模式两种方式创建 Easysearch 节点。用户只需填写集群名称、节点名称、监听地址、端口、数据目录等基本信息，向导便会自动完成软件下载、JDK 配置、安全证书生成、参数配置、插件安装、节点启动等全部步骤，并实时展示每一步的进度，支持随时暂停和恢复。

一键加入已有集群

通过粘贴现有集群提供的 Token，向导可自动从目标集群拉取证书、版本、插件等配置信息，完成新节点的安装和接入，全程无需手动复制任何证书文件。

安装前环境预检

向导在开始安装前会对当前机器进行全面检测，帮助用户提前发现潜在问题：

• 操作系统和 CPU 架构是否受支持
• 内存是否满足推荐要求
• 端口是否已被占用
• 数据目录磁盘空间是否充足、路径是否可写
• 系统参数（文件描述符限制、内核 max_map_count 等）是否满足 Easysearch 运行需求
• TLS 证书填写后实时校验有效性，包括证书链完整性和过期时间

TLS 安全证书灵活配置

支持三种证书配置方式，满足不同安全需求：

• 自动生成：向导一键生成自签名证书，无需任何证书知识
• 手动上传（共享）：为 HTTP 和节点通信层提供同一套证书
• 手动上传（分离）：为 HTTP 层和节点通信层分别提供独立证书

完整的服务生命周期管理

集群建好后，向导提供持续的管理能力：

• 启动、停止、重启 Easysearch 节点

• 在线安装和卸载插件

• 在线编辑配置，包括 easysearch.yml、JVM 参数、日志配置、证书配置

• 在线日志排查：内置日志阅读器，支持查看节点日志文件列表，并提供类似 tail -f 的自动滚动功能，无需登录服务器即可快速定位报错。”

网络受限环境支持

针对无法直接访问外网的环境，向导支持配置 HTTP 代理，所有软件包（Easysearch、JDK、插件）均可通过代理下载，并提供连通性测试功能。

获取新版本

INFINI Agent v1.31.0 已正式发布，欢迎升级体验：

• 下载地址
• 用户手册

15,000 条 heavy-OR 规则，200,000 条文档，同一台机器：Easysearch 在线规则引擎全流程 11.68 秒，Percolate Query 仅搜索阶段就跑了 254.30 秒——慢了 21.8 倍。

在"规则先存、文档后到"这类场景下，Percolate Query 的延迟会随规则数量和复杂度的增长快速恶化。规则涨到数千条后，每批文档匹配的耗时可以从秒级攀升至几分钟。这类问题换索引参数、调批次大小、精简 DSL，都治标不治本，根子在执行模型本身。

本文通过一组 heavy-OR 基准测试，量化两种方案的实际差距。

测试配置

测试在同一台主机上运行，使用同一套规则文本和文档样本。Percolate Query 的查询条件由相同规则翻译而来，保证两侧规则语义一致。

测试结果

具体指标：

• Easysearch 在线规则引擎全流程：11.68s
• Percolate Query 搜索阶段：254.30s
• 差值：242.62s
• 倍数：21.76 倍
• 每批（10,000 文档）平均耗时：Easysearch 约 0.49s，Percolate Query 约 12.69s

开启规则引擎的增量成本

规则匹配会对写入链路产生多少额外开销，是评估在线规则引擎可行性的重要指标之一。

与之对比，Percolate Query 仅搜索阶段就需要 254.30s。换言之，Easysearch 在线规则引擎把规则匹配叠加进写入流程，新增成本约为 Percolate Query 搜索耗时的 1/44.9。

只看匹配引擎本体

上一组数据（11.68s vs 254.30s）包含了 Easysearch 的在线写入、bulk 解析和索引处理等通用开销。为了单独衡量规则匹配引擎自身的性能，我们用 Java 直调 JNI 做了一次离线 match，绕过写入链路，只跑规则匹配逻辑。

这组数据说明两点：Easysearch 的性能优势并非来自写入链路的整合效率，即便剔除通用写入成本，规则匹配引擎本体与 Percolate Query 之间依然存在约 50 倍的差距。

为什么 Percolate Query 会慢

根因在执行模型，OR 条件多只是放大器。

每批文档到达时，Percolate Query 都要走完这套流程：

1. 把文档放进临时内存索引
2. 基于规则中的 terms 筛选候选规则
3. 对候选规则逐条验证

以本次测试为例，各阶段耗时分布如下：

• 规则翻译：9.560294s
• 规则导入：7.451857s
• percolate 搜索：254.304583s

搜索阶段是每批文档都必须重新支付的代价。

Heavy-OR 规则在这套流程里两头放大：规则覆盖面广，候选集更难剪掉；单条规则条件多，逐条验证也更重。

Easysearch 规则引擎把规则提前编译好，文档到达后直接匹配，不走这套每批重建的流程，差距就在这里。

适用场景

以下场景对规则匹配的吞吐和延迟要求较高，是 Easysearch 在线规则引擎的典型适用范围：

• 内容审核：规则持续增长且复杂度高，需要稳定的处理吞吐，对单批延迟敏感。
• 舆情监测：热点词、别名、邻近词组合多，规则天然形成大 OR 结构，是 Percolate Query 最容易触及性能瓶颈的场景。
• 广告定向：人群包条件不断叠加，文档流量高，规则匹配需要足够轻量，避免影响整条投放链路。
• 告警规则：延迟直接影响告警有效性，规则命中需要尽量贴近文档写入时刻。
• 实时反欺诈：规则复杂、变更频繁、吞吐高，要求文档到达后立即完成判断。

小结

在本次 heavy-OR 基准测试中：

• 相同规则集（15,000 条）和文档量（200,000 条），Easysearch 在线规则引擎全流程耗时 11.68s，Percolate Query 仅搜索阶段耗时 254.30s，相差 21.8 倍。
• 开启规则引擎带来的写入链路增量成本为 5.66s，约为 Percolate Query 搜索阶段耗时的 1/44.9。
• 剔除写入通用开销后，规则匹配引擎本体的差距约为 50 倍。

如果你的业务已经有 Percolate Query 延迟随规则增长持续上升的问题，不用看 demo 数据——把你线上最重的那批规则拿出来，跑一次就知道差距在哪。

规则引擎功能当前需要试用 License。你可以先下载 Easysearch：https://infinilabs.cn/download，再联系售前申请试用 License 并获取开通指引。

关于 Easysearch

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

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

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

相关文章：

• Easysearch ZSTD 基准测试：高压缩率下实现近 5 倍查询吞吐
• Easysearch 2.0.0 性能测试
• Easysearch 时序数据的基于时间范围的合并策略
• Easysearch Rollup 相比 OpenSearch Rollup 的优势分析
• Easysearch Rollup 使用指南