--- title: "同样 15,000 条重规则，Percolate Query 比 Easysearch 慢 21.8 倍——Heavy-OR 场景实测" date: 2026-04-14 lastmod: 2026-04-14 description: "同样 15,000 条 heavy-OR 规则和 200,000 条文档，Easysearch 在线规则引擎用时 11.68 秒，Percolate Query 仅搜索阶段就耗时 254.30 秒，慢了 21.8 倍。" tags: ["Easysearch", "Rules", "Percolator", "performance"] summary: "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." --- **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` |

同样 15,000 条规则 + 200,000 条文档

Easysearch 11.68s 在线规则引擎全流程 Percolate Query 254.30s 只算搜索阶段 Percolate Query 比 Easysearch 慢了 21.8 倍 仅搜索阶段就多花 242.62 秒
具体指标： - Easysearch 在线规则引擎全流程：`11.68s` - Percolate Query 搜索阶段：`254.30s` - 差值：`242.62s` - 倍数：`21.76 倍` - 每批（10,000 文档）平均耗时：Easysearch 约 `0.49s`，Percolate Query 约 `12.69s` --- ## 开启规则引擎的增量成本 规则匹配会对写入链路产生多少额外开销，是评估在线规则引擎可行性的重要指标之一。

开启规则引擎的写入增量

纯写入 6.03s plain_bulk 基线 开启规则引擎 11.68s 基线 6.03s + 新增 5.66s 规则引擎新增成本 仅 5.66s Percolate 搜索阶段同期耗时 254.30s
与之对比，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 纯匹配 5.05s Java JNI 离线直调 Percolate Query 254.30s 搜索阶段 只看匹配引擎本体 慢了 50.4 倍 254.30 ÷ 5.05 = 50.39
这组数据说明两点：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：，再联系售前申请试用 License 并获取开通指引。