在本文中，我们测试了 Manticore Search 和 Luwak 的渗透查询性能。
介绍
最近我们 测试了 Manticore Search 和 Elasticsearch 的渗透查询性能 。今天我们将关注 Luwak，这是一个基于 Lucene 搜索库的存储查询引擎。
在我们开发渗透查询时，我们查看了现有实现该功能的引擎。Flax（Luwak 的作者）在此处提供的基准测试促使我们测试 Manticore 与 Luwak 的性能，因为 Luwak 的表现优于 Elasticsearch。在最初的测试中，我们发现 Luwak 比我们的实现更快，这帮助我们识别了一些可以优化的点，并在某些情况下显著提升了 Manticore Search 中渗透查询的性能。
设置
基准测试由 Manticore Search 的高级核心开发人员之一 Stanislav Klinov 进行，他同时也是 Sphinx Search 的长期开发者。
最新版本的 Manticore Search
Luwak 1.5.0 与 HTTP 服务器分支 - https://github.com/tomatolog/luwak/tree/luwak-server
http://github.com/tomatolog/luwak_tests 用于数据和查询源以及通过 HTTP 向守护进程提交查询的脚本
我们采用了 luwak-server 分支，并将 luwak-1.5.0 分支合并，以同时拥有 HTTP 服务器和最新版本的 Luwak。
在之前的 Elasticsearch 测试中，我们仅使用了 4 个单词的查询（2 个 MUST 和 2 个 NOT）。现在我们尝试重现 Luwak（针对 Elasticsearch）在此处进行的 基准测试 的条件。我们关注了三种类型的存储查询：
7 个单词的查询，其中 5 个是 MUST，2 个是 NOT
120 个单词的查询，其中 100 个是 MUST，20 个是 NOT
20 个通配符单词的查询（每个由 4 个字符后缀组成）
我们的目标是使用单个和批量文档执行反向搜索。渗透查询由单个搜索工作者或多个工作者（以测试并发模式）触发。
渗透查询通过 HTTP API 执行，因此我们将包含 HTTP 服务器的 Luwak 分支与最新稳定代码合并。
测试
在不使用批量处理时，Luwak 表现稍好，但一旦开始批量处理文档，Manticore 就占据了优势。
100K 存储查询中 5x MUST + 2x NOT
当我们开始批量处理文档时，Luwak 的平均延迟增长更快。
为了对引擎施加压力，我们添加了多个并发搜索工作者来攻击引擎。Luwak 在 100 文档批量处理中表现稍好，因为 Manticore 变慢了，但仍然比 Luwak 慢约 2 倍。平均延迟遵循相同的模式：当文档被批量处理时，Luwak 的延迟更高。
100K 存储查询中 100x MUST + 20x NOT
这种情况对 Luwak 造成了很大压力。
5k 存储查询中 20 个 4 字符长度的通配符
在进行测试时，我们发现 Manticore 在使用带有通配符和批量文档的存储查询时存在性能问题（尚未修复）。随着在批量中添加多个文档，吞吐量下降。与之前的测试相比，Luwak 在非批量模式下表现不佳，但当我们批量处理文档时，它略微优于 Manticore。
当用并发工作者轰炸引擎时，没有明显的胜者。
在平均延迟方面，当搜索工作线程数量较低时，Luwak在某些情况下会稍微好一点，但差异并不明显。
结论
对于存储查询包含多个非通配符术语的情况，Luwak与Manticore表现相当的唯一情况是在非批量模式下。一旦我们对文档进行批量处理，Manticore在吞吐量方面明显优于Luwak，平均延迟通常仅为Luwak的一半。
Luwak最糟糕的情况是当存储查询包含超过一百个非通配符术语时。即使在非批量模式下，Manticore的速度也快了三倍以上，在处理10个批量文档时甚至能达到20倍的速度。当文档被批量处理进行匹配时，Luwak的延迟也非常高。
对于包含通配符术语的存储查询，没有明确的优胜者。在某些情况下，Luwak的表现略好一些。我们这边有一个已知的缺陷（Bloom拒绝过滤器未按预期工作），这影响了性能。Luwak的最佳情况是在20个文档批次和单个搜索工作线程运行时，此时它几乎快了两倍，但在其他情况下，性能提升要小得多，或者Manticore略胜一筹。