同样 15,000 条重规则，Percolate Query 比 Easysearch 慢 21.8 倍

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 数据——把你线上最重的那批规则拿出来，跑一次就知道差距在哪。