# Percolate queries: Manticore Search vs Luwak

在本文中，我们测试了 Manticore Search 和 Luwak 的渗透查询性能。

### 介绍


最近我们[测试了 Manticore Search 和 Elasticsearch 的渗透查询性能](https://manticoresearch.com/blog/percolate-queries-manticoresearch-vs-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://github.com/tomatolog/luwak_tests) 用于数据和查询源以及通过 HTTP 向守护进程提交查询的脚本

 - <http://github.com/Ivinco/stress-tester> 用于运行基准测试



我们采用了 luwak-server 分支，并将 luwak-1.5.0 分支合并，以同时拥有 HTTP 服务器和最新版本的 Luwak。

在之前的 Elasticsearch 测试中，我们仅使用了 4 个单词的查询（2 个 MUST 和 2 个 NOT）。现在我们尝试重现 Luwak（针对 Elasticsearch）在此处进行的[基准测试](http://www.flax.co.uk/blog/2015/07/27/a-performance-comparison-of-streamed-search-implementations/)的条件。我们关注了三种类型的存储查询：

 - 7 个单词的查询，其中 5 个是 MUST，2 个是 NOT

 - 120 个单词的查询，其中 100 个是 MUST，20 个是 NOT

 - 20 个通配符单词的查询（每个由 4 个字符后缀组成）



我们的目标是使用单个和批量文档执行反向搜索。渗透查询由单个搜索工作者或多个工作者（以测试并发模式）触发。

渗透查询通过 HTTP API 执行，因此我们将包含 HTTP 服务器的 Luwak 分支与最新稳定代码合并。
  
  
### 测试


在不使用批量处理时，Luwak 表现稍好，但一旦开始批量处理文档，Manticore 就占据了优势。
  
  
#### 100K 存储查询中 5x MUST + 2x NOT


<iframe frameborder="0" height="371" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=1313028442&format=interactive" width="600"></iframe>

当我们开始批量处理文档时，Luwak 的平均延迟增长更快。
<iframe frameborder="0" height="371" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=737927507&format=interactive" width="600"></iframe>
为了对引擎施加压力，我们添加了多个并发搜索工作者来攻击引擎。Luwak 在 100 文档批量处理中表现稍好，因为 Manticore 变慢了，但仍然比 Luwak 慢约 2 倍。

<iframe frameborder="0" height="437" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=1304475308&format=interactive" width="739"></iframe>

平均延迟遵循相同的模式：当文档被批量处理时，Luwak 的延迟更高。

<iframe frameborder="0" height="371" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=680962058&format=interactive" width="600"></iframe>
  
  
#### 100K 存储查询中 100x MUST + 20x NOT


这种情况对 Luwak 造成了很大压力。
<iframe frameborder="0" height="371" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=768996929&format=interactive" width="600"></iframe>

<iframe frameborder="0" height="371" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=707176452&format=interactive" width="600"></iframe>

<iframe frameborder="0" height="371" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=719871225&format=interactive" width="600"></iframe>

 
  
  
#### 5k 存储查询中 20 个 4 字符长度的通配符


在进行测试时，我们发现 Manticore 在使用带有通配符和批量文档的存储查询时存在性能问题（尚未修复）。随着在批量中添加多个文档，吞吐量下降。与之前的测试相比，Luwak 在非批量模式下表现不佳，但当我们批量处理文档时，它略微优于 Manticore。

<iframe frameborder="0" height="371" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=542380013&format=interactive" width="600"></iframe>

当用并发工作者轰炸引擎时，没有明显的胜者。

<iframe frameborder="0" height="371" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=1409638853&format=interactive" width="600"></iframe>

在平均延迟方面，当搜索工作线程数量较低时，Luwak在某些情况下会稍微好一点，但差异并不明显。
<iframe frameborder="0" height="371" scrolling="no" seamless="" src="https://docs.google.com/spreadsheets/d/e/2PACX-1vTvi_kblR21lazWsNFaOvdWFhs61JJbvXBiIspvE5GfyoD_kieukXA_rv-I7_iX3HY1pdxizR-iDS8G/pubchart?oid=1446110726&format=interactive" width="600"></iframe>
  
  
### 结论


对于存储查询包含多个非通配符术语的情况，Luwak与Manticore表现相当的唯一情况是在非批量模式下。一旦我们对文档进行批量处理，Manticore在吞吐量方面明显优于Luwak，平均延迟通常仅为Luwak的一半。

Luwak最糟糕的情况是当存储查询包含超过一百个非通配符术语时。即使在非批量模式下，Manticore的速度也快了三倍以上，在处理10个批量文档时甚至能达到20倍的速度。当文档被批量处理进行匹配时，Luwak的延迟也非常高。

对于包含通配符术语的存储查询，没有明确的优胜者。在某些情况下，Luwak的表现略好一些。我们这边有一个已知的缺陷（Bloom拒绝过滤器未按预期工作），这影响了性能。Luwak的最佳情况是在20个文档批次和单个搜索工作线程运行时，此时它几乎快了两倍，但在其他情况下，性能提升要小得多，或者Manticore略胜一筹。