Rules
同样 15,000 条重规则，Percolate Query 比 Easysearch 慢 21.8 倍 —— Heavy-OR 场景实测
Easysearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 139 次浏览 • 14 小时前
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 - 差值：
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 都要走完这套流程：
- 把文档放进临时内存索引
- 基于规则中的 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 数据——把你线上最重的那批规则拿出来，跑一次就知道差距在哪。
规则引擎功能当前需要试用 License。你可以先下载 Easysearch：https://infinilabs.cn/download，再联系售前申请试用 License 并获取开通指引。
关于 Easysearch
INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。
官网文档：https://docs.infinilabs.com/easysearch
作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。
相关文章：
同样 15,000 条重规则，Percolate Query 比 Easysearch 慢 21.8 倍 —— Heavy-OR 场景实测
Easysearch • INFINI Labs 小助手 发表了文章 • 0 个评论 • 139 次浏览 • 14 小时前
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 - 差值：
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 都要走完这套流程：
- 把文档放进临时内存索引
- 基于规则中的 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 数据——把你线上最重的那批规则拿出来，跑一次就知道差距在哪。
规则引擎功能当前需要试用 License。你可以先下载 Easysearch：https://infinilabs.cn/download，再联系售前申请试用 License 并获取开通指引。
关于 Easysearch
INFINI Easysearch 是一个分布式的搜索型数据库，实现非结构化数据检索、全文检索、向量检索、地理位置信息查询、组合索引查询、多语种支持、聚合分析等。Easysearch 可以完美替代 Elasticsearch，同时添加和完善多项企业级功能。Easysearch 助您拥有简洁、高效、易用的搜索体验。
官网文档：https://docs.infinilabs.com/easysearch
作者：张磊，极限科技（INFINI Labs）搜索引擎研发负责人，对 Elasticsearch 和 Lucene 源码比较熟悉，目前主要负责公司的 Easysearch 产品的研发以及客户服务工作。
相关文章：
