Manticore 2.8.2 vs 3.0 - 在某些测试中速度提高了2倍

正如您所知，最近发布了 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 RAM
  • HDD
  • Docker 版本 18.09.2
  • 用于索引和搜索的基础镜像 - Ubuntu:bionic
  • 用于基准测试的 stress-tester

这两个版本的 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
}

索引

索引耗时 1303 秒用于 Manticore 3.0 和 1322 秒用于 Manticore 2.8.2：

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 曾经
没有我的使用其他为什么有天有给予他们让
这里一些已经知道s 在哪里如何确定已经大这里 e
300-350350-400400-450450-500500-550550-600
谁 开发者它书现在单身无法访问在解决方案他们称之为
工作开始一个ycombinator从添加使用网站知道微软大多数情况下
在小时现在价值也给出哪个构建比力量早期的
600-650650-700700-750750-800800-850850-900
知道科学应该营销应该孩子数字他们的驱动谁高度
如果同意一个分钟t帖子时间pg那里选择有机会
会相关有国家获取帖子http教育也极其可以主题
900-950950-1000
任何党派特别在
唯一回应可以计算机
人火狐关于计算机


Manticore 3.0显示平均吞吐量提高86.3%，95p延迟降低109.5%。

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

1-5050-100100-150150-200200-250250-300
"工作不""你他们的""我们仍然""自己的""我得到""可以运行"
"我的为""非常""你的工作""使用获得""这里不好""然后永远"
"但是那个""获取 com""我第一次""现在天""向上帮助""然后制作"
300-350350-400400-450450-500500-550550-600
"它信息""他们社区""1 关心""什么移动""外快乐""去看"
"com 侧""这个服务器""com 位置""在巨大""如何停止""s 写的"
"他看起来""是 x""时间变成""尝试过""应该来""其他声音"
600-650650-700700-750750-800800-850850-900
"通过 api""不快""t 好奇""是多个""的修复""事情绝对"
"的三""使用即将到来""那缺乏""谁 ui""ve 理解""大多数主题"
"真的在谈话""制作应用程序""真的环境""将谁在招聘""在昂贵""更多核心"
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 terms4 terms5 terms
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 术语和 1 个 NOT 术语（不来自 300-400）

现在让我们向 3 个 AND 添加一个 NOT 术语。


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

结论

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

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

感谢您的阅读！

Read also

安装Manticore Search

安装Manticore Search

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