⚠️ 此页面为自动翻译，翻译可能不完美。

Manticore 2.8.2 vs 3.0 - 2x faster in some tests

正如您可能知道的，最近 Manticore 3.0 已发布 。

在此基准测试中，我们来看看它是否比 2.8 更好。测试环境如下：

  • 2016 年的 Hacker News 精选评论数据集 以 CSV 格式
  • 操作系统：Ubuntu 18.04.1 LTS (Bionic Beaver)，内核：4.15.0-47-generic
  • CPU：Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz，8 核
  • 32G 内存
  • 硬盘
  • Docker 版本 18.09.2
  • 索引和 searchd 的基础镜像 - Ubuntu:bionic
  • 压力测试工具 用于基准测试

两个版本的 Manticore 配置完全相同：

source full
{
  type = csvpipe
  csvpipe_command = cat /root/hacker_news_comments.prepared.csv|grep -v line_number
  csvpipe_attr_uint = story_id
  csvpipe_attr_timestamp = story_time
  csvpipe_field = story_text
  csvpipe_field = story_author
  csvpipe_attr_uint = comment_id
  csvpipe_field = comment_text
  csvpipe_field = comment_author
  csvpipe_attr_uint = comment_ranking
  csvpipe_attr_uint = author_comment_count
  csvpipe_attr_uint = story_comment_count
}

index full
{
  path = /root/idx_full
  source = full
  html_strip = 1
  mlock = 1
}

searchd
{
  listen = 9306:mysql41
  query_log = /root/query.log
  log = /root/searchd.log
  pid_file = /root/searchd.pid
  binlog_path =
  qcache_max_bytes = 0
}

索引

索引耗时 Manticore 3.0 为 1303 秒，Manticore 2.8.2 为 1322 秒：

Manticore 3.0:

indexing index 'full'...
collected 11654429 docs, 6198.6 MB
creating lookup: 11654.4 Kdocs, 100.0% done
creating histograms: 11654.4 Kdocs, 100.0% done
sorted 1115.7 Mhits, 100.0% done
total 11654429 docs, 6198580642 bytes
total <b>1303.470</b> sec, 4755444 bytes/sec, 8941.07 docs/sec
total 22924 reads, 16.605 sec, 238.4 kb/call avg, 0.7 msec/call avg
total 11687 writes, 13.532 sec, 855.1 kb/call avg, 1.1 msec/call avg

Manticore 2.8:

indexing index 'full'...
collected 11654429 docs, 6198.6 MB
sorted 1115.7 Mhits, 100.0% done
total 11654429 docs, 6198580642 bytes
total <b>1322.239</b> sec, 4687939 bytes/sec, 8814.15 docs/sec
total 11676 reads, 15.248 sec, 452.6 kb/call avg, 1.3 msec/call avg
total 9431 writes, 12.800 sec, 1065.3 kb/call avg, 1.3 msec/call avg

因此，使用此数据集和索引模式 3.0 的索引速度比 2.8 快约 1.5%。

性能测试

在测试之前，两个实例都进行了预热。

Manticore 3.0:

total 4.7G
drwx------ 2 root root 4.0K May 14 17:41 .
drwxr-xr-x 3 root root 4.0K May 14 17:40 ..
-rw-r--r-- 1 root root 362M May 14 17:24 idx_full.spa
-rw-r--r-- 1 root root 3.1G May 14 17:36 idx_full.spd
-rw-r--r-- 1 root root  90M May 14 17:36 idx_full.spe
-rw-r--r-- 1 root root  628 May 14 17:36 idx_full.sph
-rw-r--r-- 1 root root  29K May 14 17:24 idx_full.sphi
-rw-r--r-- 1 root root 6.5M May 14 17:36 idx_full.spi
-rw------- 1 root root    0 May 14 17:41 idx_full.spl
-rw-r--r-- 1 root root 1.4M May 14 17:24 idx_full.spm
-rw-r--r-- 1 root root 1.1G May 14 17:36 idx_full.spp
-rw-r--r-- 1 root root  59M May 14 17:24 idx_full.spt

Manticore 2.8:

total 4.6G
drwx------ 2 root root 4.0K May 16 18:38 .
drwxr-xr-x 3 root root 4.0K May 14 17:43 ..
-rw-r--r-- 1 root root 362M May 14 17:24 idx_full.spa
-rw-r--r-- 1 root root 3.1G May 14 17:36 idx_full.spd
-rw-r--r-- 1 root root  27M May 14 17:36 idx_full.spe
-rw-r--r-- 1 root root  601 May 14 17:36 idx_full.sph
-rw-r--r-- 1 root root 6.3M May 14 17:36 idx_full.spi
-rw-r--r-- 1 root root    0 May 14 17:24 idx_full.spk
-rw------- 1 root root    0 May 16 18:38 idx_full.spl
-rw-r--r-- 1 root root    0 May 14 17:24 idx_full.spm
-rw-r--r-- 1 root root 1.1G May 14 17:36 idx_full.spp
-rw-r--r-- 1 root root    1 May 14 17:36 idx_full.sps

测试 1 - 处理集合中前 1000 个术语所需时间

首先，我们运行一个简单的测试 - 遍历集合中前 1000 个高频术语并为每个术语查找所有文档需要多长时间：

结果是：Manticore 2.8 为 77.61 秒，Manticore 3.0 为 71.79 秒。

因此，在此测试中，Manticore Search 3.0 比上一版本快 8%。

测试 2 - 按组划分的集合中前 1000 个高频术语（前 1-50，前 50-100 等）

现在让我们看看 3.0 在处理不同频率组的术语方面是否更好。下面您可以看到每个组中的一些随机示例：

1至5050至100100至150150至200200至250250至300
一很多我们的每个更少支付
与真的进入没有另一个理解
是其他仍然向下已经每个人
300至350350至400400至450450至500500至550550至600
搜索开发人员创建兴趣一般公司
原因整个给定尝试模型办公室
什么都没有名字朋友访问数量支付
600至650650至700700至750750至800800至850850至900
管理他们自己跨越pg纸张核心
相关市场营销学到观点挑选高度
去除非帖子风险强大交通
900至950950至1000
想法不错
界面年轻
回应英语


Manticore 2.8 在延迟方面平均比 3.0 快 0.4%，并且提供 0.5% 更高的吞吐量。这在误差范围内。

测试 3 - 从集合中按组分解的前 1000 个高频术语 + 组 1-100 中的 1 个术语

让我们看看当您有一个非常频繁的术语和另一个来自不同频率组的较不频繁的术语时它是如何工作的。示例如下：

1-5050-100100-150150-200200-250250-300
其他可以没有在...之上关于他的应该大s ever
没有是我的使用其他为什么曾经一天曾经给予他们让
这里一些已经知道s 在哪里如何确定已经大这里e
300-350350-400400-450450-500500-550550-600
谁开发者它书现在单一不访问在解决方案他们的称为
工作开始一个ycombinator从添加使用站点知道microsoft作为主要
在小时现在价值也给予哪个构建比力量的早期
600-650650-700700-750750-800800-850850-900
知道科学应该营销应该孩子的数字他们的驱动谁高度
如果同意一个分钟t帖子时间pg也极其可能主题
将相关有国家获取帖子http 教育也极其可能主题
900-950950-1000
任何党派在特别
仅响应可能计算机
人们firefox关于计算机


Manticore 3.0 的吞吐量平均提高了 86.3%，95 百分位延迟降低了 109.5%。

测试 4 - 从集合中按组分解的前 1000 个高频术语 + 从组 1-100 中的 1 个术语，两个术语均用引号括起以形成短语

1-5050-100100-150150-200200-250250-300
工作不你的我们仍然自己的我得到可以运行
我的非常你的工作使用获得这里糟糕然后曾经
但是那获取共同我首先现在每天上帮助然后制作
300-350350-400400-450450-500500-550550-600
它信息他们社区1 关心什么移动出快乐去观看
com 侧这个服务器com 位置在巨大如何停止s 写作
他看起来是 x时间成为的尝试应该来其他声音
600-650650-700700-750750-800800-850850-900
通过 api不要很快t 好奇是多个的修复事情绝对
三个中的使用即将到来那缺乏谁 ui有理解大多数主题
真的在谈论制作应用程序真的环境将 whoishiring在昂贵更多核心
900-950950-1000
仅仅框架它抱歉
工作资源想要好处
他们的资源s 进一步


Manticore v3 在吞吐量方面平均快 5.6%，在 95p 延迟方面平均低 25.1%。

测试 5 - 从 600-750 组中各取 2 个词，在不同并发量下的表现

此测试旨在展示在不同查询并发量下的吞吐量差异。几个随机示例：

查询示例： "talking view", "imagine 15", "curious term"


因此，版本 3 在所有并发量下平均快 18%，95p 延迟平均降低 15%。

测试 6 - 从不同组中取 3-5 个词

现在让我们检查更长查询的性能。

  • 从 100-200、400-500、800-900 组中各取 3 个词
  • 从 100-200、300-400、500-600、800-900 组中各取 4 个词
  • 从 100-200、300-400、500-600、800-900、900-1000 组中各取 5 个词

查询示例：

3 个词4 个词5 个词
doing under poorthese search awesome background

got reason results taken ad

always tried storiesworking again comment links

feel process situation faster bring

job text cardgoogle number network function

going days browser known salary


版本 3 再次胜出：吞吐量提高 104%，95p 延迟降低 113%。

测试 7：从 300-600 组中取 3 个 AND 词和从 300-400 组中取 1 个 NOT 词

现在我们在 3 个 AND 词中添加一个 NOT 词。


v3 的吞吐量提高 33.3%，95p 延迟降低 32%。

结论

新版本在所有测试中表现出显著更高的性能，除了测试 #2，但那里的差异在误差范围内（0.4-0.5%）。

该测试完全使用 Docker 容器化，并且 在我们的 GitHub 上开源 。详细结果可以在 此处 找到。如果您在自己的硬件上运行相同的测试或通过添加更多测试用例来贡献，我们将不胜感激，并请告知我们结果。
如果您发现任何问题或不准确之处，请随时告知我们。

感谢阅读！

Read also

安装Manticore Search

安装Manticore Search

© 2017-2025 Manticore Software Ltd. 条款 隐私政策