同样 15,000 条重规则，Percolate Query 比 Easysearch 慢 21.8 倍 —— Heavy-OR 场景实测
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_bulk6.025535s在线规则引擎 rules_only11.684568sPercolate Query 搜索阶段254.304583shttps://infinilabs.cn/img/blog/2026/easysearch-rules-engine-vs-percolate-query-heavy-or-benchmark/1.png
详细指标：
[*]Easysearch 在线规则引擎全流程：11.68s
[*]Percolate Query 搜索阶段：254.30s
[*]差值：242.62s
[*]倍数：21.76 倍
[*]每批（10,000 文档）均匀耗时：Easysearch 约 0.49s，Percolate Query 约 12.69s
开启规则引擎的增量本钱
规则匹配会对写入链路产生多少额外开销，是评估在线规则引擎可行性的紧张指标之一。
https://infinilabs.cn/img/blog/2026/easysearch-rules-engine-vs-percolate-query-heavy-or-benchmark/2.png
与之对比，Percolate Query 仅搜索阶段就须要 254.30s。换言之，Easysearch 在线规则引擎把规则匹配叠加进写入流程，新增本钱约为 Percolate Query 搜索耗时的 1/44.9。
只看匹配引擎本体
上一组数据（11.68s vs 254.30s）包罗了 Easysearch 的在线写入、bulk 剖析和索引处理惩罚等通用开销。为了单独衡量规则匹配引擎自身的性能，我们用 Java 直调 JNI 做了一次离线 match，绕过写入链路，只跑规则匹配逻辑。
路径用时Easysearch 纯匹配（JNI 离线）5.046934sPercolate Query 搜索阶段254.304583shttps://infinilabs.cn/img/blog/2026/easysearch-rules-engine-vs-percolate-query-heavy-or-benchmark/3.png
这组数听分析两点：Easysearch 的性能上风并非来自写入链路的整合服从，即便剔除通用写入本钱，规则匹配引擎本体与 Percolate Query 之间依然存在约 50 倍的差距。
为什么 Percolate Query 会慢
根因在实行模子，OR 条件多只是放大器。
每批文档到达时，Percolate Query 都要走完这套流程：
[*]把文档放进暂时内存索引
[*]基于规则中的 terms 筛选候选规则
[*]对候选规则逐条验证
以本次测试为例，各阶段耗时分布如下：
[*]规则翻译：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 数据——把你线上最重的那批规则拿出来，跑一次就知道差距在哪。
页:
[1]