1. 拿ES管理Agent的记忆，一搞一个不吱声啊（需要梯子）
https://codeburst.io/building- ... b0ec2

2. 妹想到吧，ES 害自带安全预警呢（需要梯子）
https://medium.com/%40abbasmur ... f16eb

3. 听我给你讲讲ES 这么流行的核心原因（需要梯子）
https://medium.com/%40seymadog ... 45fa5

编辑：斯蒂文
更多资讯：[http://news.searchkit.cn](http://news.searchkit.cn/)

1、如何使用 LogsDB 降低 Elasticsearch 日志存储成本
https://elasticstack.blog.csdn ... 53896

2、使用 Elasticsearch + Jina embeddings 进行无监督文档聚类
https://elasticstack.blog.csdn ... 39667

3、重磅！Anthropic官方Harness发布了！
https://mp.weixin.qq.com/s/66SDrz5_MlBAPwL0xtMFyw

4、「纯干货」几万字都讲不明白的Memory架构与思考
https://mp.weixin.qq.com/s/bl77_Mb85C4AKe8h4__V6Q

5、创业者正在围绕OpenClaw生态做什么产品？
https://mp.weixin.qq.com/s/H2DuoMR3Svoq_djWXAzA3Q

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

1.jina-embeddings-v5-text：新的最先进水平小型多语言 embeddings
https://blog.csdn.net/UbuntuTo ... 19125

2.为什么电子商务 search 需要治理
https://blog.csdn.net/UbuntuTo ... 05279

3.使用 Jina-VLM 小型多语言视觉语言模型来和图片对话
https://blog.csdn.net/UbuntuTo ... 96461

4.在DeepSearch中用DeepSeek-R1来做动作决策会更好么？
https://zhuanlan.zhihu.com/p/1911441996985373763

5.亚马逊 OpenSearch 服务的矢量数据库功能详解
https://www.amazonaws.cn/blog- ... ined/

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

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

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

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

测试配置

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

| 参数 | 值 |
| :------------- | ------------------------: |
| 规则总数 | 15,000 |
| 文档总数 | 200,000 |
| 批次大小 | 10,000 / 批 |
| 重规则数量 | 2,500 条大 OR 热点规则 |
| 单条大 OR 规模 | 随机 50 ～ 500 个 OR 条件 |

测试结果

| 路径 | 用时 |
| :------------------------- | ------------: |
| 纯写入 plain_bulk | 6.025535s |
| 在线规则引擎 rules_only | 11.684568s |
| Percolate Query 搜索阶段 | 254.304583s |

具体指标：

- 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 纯匹配（JNI 离线） | `5.046934s` |
| Percolate Query 搜索阶段 | `254.304583s` |



这组数据说明两点：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 倍查询吞吐](https://infinilabs.cn/blog/202 ... ntage/)
- [Easysearch 2.0.0 性能测试](https://infinilabs.cn/blog/202 ... ments/)
- [Easysearch 时序数据的基于时间范围的合并策略](https://infinilabs.cn/blog/202 ... earch/)
- [Easysearch Rollup 相比 OpenSearch Rollup 的优势分析](https://infinilabs.cn/blog/202 ... ollup/)
- [Easysearch Rollup 使用指南](https://infinilabs.cn/blog/202 ... ollup/)

1、告别向量模型！TreeSearch 让文档检索回归本质
https://mp.weixin.qq.com/s/k2HHfziaAoQUF_FVWfrRMg

2、同样 1.5万 条重规则，Percolate Query 比 Easysearch 慢 21.8 倍——Heavy-OR 场景实测
https://infinilabs.cn/blog/202 ... mark/

3、如何比较两个 Elasticsearch 索引并找出缺失的文档
https://my.oschina.net/u/3343882/blog/19575330

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