# Benchmark: Manticore 3 vs Sphinx 3 - now even faster 最近 [我们发布了 Manticore 3.0.0](https://manticoresearch.com/blog/manticore-search-3-0-0-is-now-available/)，其中包含许多改进，包括一些新的优化，提高了性能。在本文中，我们希望将新版本的性能与 Sphinx 3.1.1 的性能进行比较。 ### TL;DR Manticore 表现出： - 在某些情况下，**搜索性能大约提高了 2 倍，尤其是在较长查询时** - 在其他所有测试中，**性能较低，但仍优于 Sphinx** - 除了索引时间，Sphinx 快 2% ### 测试环境 正如 [我们之前对 Manticore 2.7 与 Sphinx 3 进行基准测试时](https://manticoresearch.com/blog/manticore-2-7-5-vs-sphinx-3-1-1/)，我们将使用来自 Hacker News 的 1160 万用户评论数据集进行基准测试。 基准测试是在以下条件下进行的： - [Hacker News 精选评论数据集](https://zenodo.org/record/45901/export/xd#.XEqiuc8zaU0) 2016 年的 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 - 硬盘 - Docker 版本 18.09.2 - 索引和 searchd 的基础镜像 - Ubuntu:bionic - Manticore Search 在 Docker 中构建，Sphinx 二进制文件从网站下载，因为没有开源代码可供构建 - [压力测试工具](http://github.com/Ivinco/stress-tester) 用于基准测试 Manticore 和 Sphinx 的配置相同： ```ini 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 为 1263 秒**，**Sphinx 为 1237 秒**： Manticore: ```bash 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 1263.497 sec, 4905890 bytes/sec, 9223.94 docs/sec total 22924 reads, 1.484 sec, 238.4 kb/call avg, 0.0 msec/call avg total 11687 writes, 11.773 sec, 855.1 kb/call avg, 1.0 msec/call avg ``` Sphinx: ```bash indexing index 'full'... collected 11654429 docs, 6198.6 MB sorted 1115.7 Mhits, 100.0% done total 11654429 docs, 6.199 Gb total 1236.9 sec, 5.011 Mb/sec, 9422 docs/sec ``` 因此，在这个数据集和索引模式下，**Manticore 的索引速度比 Sphinx 慢约 2%**。 ## 性能测试 --- 在测试之前，两个实例都进行了预热。索引文件如下： Manticore: ```bash root@bench# ls -lah /var/lib/docker/volumes/64746c338de981014c7c1ea93d4c55f55e13de63ac9e49c2d31292bb239a82b6/_data total 4.7G drwx------ 2 root root 4.0K May 14 09:03 . drwxr-xr-x 3 root root 4.0K May 14 09:01 .. -rw-r--r-- 1 root root 362M May 13 17:22 idx_full.spa -rw-r--r-- 1 root root 3.1G May 13 17:31 idx_full.spd -rw-r--r-- 1 root root 90M May 13 17:31 idx_full.spe -rw-r--r-- 1 root root 628 May 13 17:31 idx_full.sph -rw-r--r-- 1 root root 29K May 13 17:22 idx_full.sphi -rw-r--r-- 1 root root 6.5M May 13 17:31 idx_full.spi -rw------- 1 root root 0 May 14 09:03 idx_full.spl -rw-r--r-- 1 root root 1.4M May 13 17:22 idx_full.spm -rw-r--r-- 1 root root 1.1G May 13 17:31 idx_full.spp -rw-r--r-- 1 root root 59M May 13 17:22 idx_full.spt ``` Sphinx: ```bash root@bench /var/lib/docker/volumes # ls -lah /var/lib/docker/volumes/bd28586b5102ff91d4c367f612e2f7b1fe0a066917c8e0b4636d203dd3ba5b0b/_data total 4.6G drwx------ 3 root root 4.0K May 14 09:04 . drwxr-xr-x 3 root root 4.0K May 14 09:03 .. -rw-r--r-- 1 root root 362M May 13 19:09 idx_full.spa -rw-r--r-- 1 root root 3.1G May 13 19:17 idx_full.spd -rw-r--r-- 1 root root 27M May 13 19:17 idx_full.spe -rw-r--r-- 1 root root 648 May 13 19:17 idx_full.sph -rw-r--r-- 1 root root 6.3M May 13 19:17 idx_full.spi -rw-r--r-- 1 root root 8 May 13 19:09 idx_full.spj -rw-r--r-- 1 root root 1.4M May 13 19:09 idx_full.spk -rw------- 1 root root 0 May 14 09:04 idx_full.spl -rw-r--r-- 1 root root 1.1G May 13 19:17 idx_full.spp ``` ### 测试 1 - 处理集合中前 1000 个术语所需的时间 首先，我们运行一个简单的测试 - 查找包含集合中前 1000 个术语的文档需要多长时间： ```bash for n in `head -1000 hn_top.txt|awk '{print $1}'`; do mysql -P9306 -hhn_$engine -e "select * from full where match('@(comment_text,story_text,comment_author,story_author) $n') limit 10 option max_matches=1000" > /dev/null done ``` 结果是：Sphinx 为 77.61 秒，Manticore 为 71.46 秒。 ![](./benchmark_manticore3_vs_sphinx3/at1-2899952845-1558009631666.png) **因此，在这个测试中，Manticore Search 比 Sphinx Search 快 8.59%。** ### 测试 2 - 按组划分的集合中前 1000 个常见术语（前 1-50，前 50-100 等） 现在让我们看看 Sphinx 和 Manticore 在处理前 1000 个常见术语的子组时有何不同。 为了更好地理解这些查询，这里有一些每个组的随机查询示例：
1-5050-100100-150150-200200-250250-300
关于获取事物使用不同高
我的工作是关闭系统构建
更多事物似乎确定没有下一个
300-350350-400400-450450-500500-550550-600
天价值20想要价格本身
编写服务器关心网站g文件
没有电话故事最近模型存储
600-650650-700700-750750-800800-850850-900
招聘智能欢迎选择被采用主题
客户愿望想要pg细节核心
iphone原因环境通常css想知道
900-950950-1000
完整关键词
资源晚
想法ipad
![](./benchmark_manticore3_vs_sphinx3/95p-latency-of-top-1000-frequent-terms-from-Hacker-News-collection-by-term-groups-top-1-50-top-50-100-etc.-ms.png) ![](./benchmark_manticore3_vs_sphinx3/Throughput-of-top-1000-frequent-terms-from-Hacker-News-collection-by-term-groups-top-1-50-top-50-100-etc..png) **Manticore 在 95 百分位延迟方面比 Sphinx 快 6.8%，在吞吐量方面快 12.2%。** ### 测试 3 - 从集合中按组分解的前 1000 个高频术语 + 从 1-100 组中选取 1 个术语 让我们看看当您有一个非常频繁的术语和另一个不太频繁的术语时，它的工作方式。例如：
1-5050-100100-150150-200200-250250-300
更多是那已被方式正在一个关闭只是启动已经支付
它们作为可能其他可以d认为自己的真的其他如果设计
关于是制作然后是等等从应用程序到一点在尚未
300-350350-400400-450450-500500-550550-600
只是或者一个互联网谁网络你位置将程序t基本上
不离开通过社交t过去一个站点一个几个有公司
1写有意味着大多数家伙不重要有空间如果基本上
600-650650-700700-750750-800800-850850-900
方式程序员看到标题因为词语认为mac大多数昂贵时间改变
是困难我成功com客户是听到在极端被食物
他们的周比yc因为精细也桌面为理解大多数流量
900-950950-1000
如果派对真的公平
当认真这里服务器
认为速度是失去
![](./benchmark_manticore3_vs_sphinx3/95-latency-of-top-1000-frequent-terms-from-Hacker-News-colleciton-by-groups-1-term-from-group-1-100-ms.png) ![](./benchmark_manticore3_vs_sphinx3/Throughput-of-top-1000-frequent-terms-from-Hacker-News-colleciton-by-groups-1-term-from-group-1-100.png) **哇，Manticore 的吞吐量比 Sphinx 快 106%，在 95 百分位延迟方面平均快 91.8%。** ### 测试 4 - 从集合中按组分解的前 1000 个高频术语 + 1 个来自组 1-100 的术语，两个术语都用引号括起来以形成短语
1-5050-100100-150150-200200-250250-300
"他们全部""也认为""那段代码""我们的应用""来自给予""由用户"
"http 你""像被""是我们的""作为文章""使用制作""真的至少"
"由某些""使用工作""做得好""我应用""可能不同""如果理解"
300-350350-400400-450450-500500-550550-600
"其他开发者""通过构建""想创建""有前端""任何政府""他们考虑"
"有想法""我python""谁给予""已经完全""有价格""开始启动"
"方式facebook""被编辑""上链接""使用位置""真的处理""现在早期"
600-650650-700700-750750-800800-850850-900
"已经几周""上工程""已经询问""s p""谁css""有加号"
"制作api""我们预期""真的愿意""t 步骤""因为强大""为流量"
"是笔记""会自己""http 学位""http 桌面""不否则""很多食物"
900-950950-1000
"s 带来""非常需要"
"这个选择""所有例子"
"现在带来""成为论点"
![](./benchmark_manticore3_vs_sphinx3/95p-latency-of-top-1000-frequent-terms-from-Hacker-News-colleciton-by-groups-1-term-from-group-1-100-both-terms-enclosed-in-quotes-to-make-a-phrase-ms.png) ![](./benchmark_manticore3_vs_sphinx3/Throughput-of-top-1000-frequent-terms-from-Hacker-News-colleciton-by-groups-1-term-from-group-1-100-both-terms-enclosed-in-quotes-to-make-a-phrase.png) **在这里，Manticore 的平均吞吐量提高了 11.8%，95百分位延迟降低了 21.2%。** ### 测试 5 - 从 600-750 组中各取 2 个词在不同并发量下的表现 此测试旨在展示不同查询并发量下的吞吐量差异。我们得到以下结果： ![](./benchmark_manticore3_vs_sphinx3/95p-latency-of-2-terms-each-from-group-600-750-under-different-concurrencies-ms.png) ![](./benchmark_manticore3_vs_sphinx3/Throughput-of-2-terms-each-from-group-600-750-under-different-concurrencies.png) **在所有并发量下，Manticore 的平均速度提高了 31%，并且 95百分位延迟降低了 28%。** ### 测试 6 - 从不同组中选取 3-5 个词 此测试旨在展示更长查询（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 个术语
工作自我发布使用感谢第二 12切换开始 b 12 个位置
每个站点缺失围绕学校模型链接切换 github 类别讨厌最近
他的避免通过工作数量效果切换 facebook 办公室绝对英语
![](./benchmark_manticore3_vs_sphinx3/95p-latency-of-3-5-terms.png) ![](./benchmark_manticore3_vs_sphinx3/Throughput-of-3-5-terms.png) **Manticore 的吞吐量高出 77.6%，95% 分位延迟降低了 81.4%。** ### 测试 7：从 300-600 组中取 3 个 AND 术语和从 300-400 组中取 1 个 NOT 术语 在此测试中，我们在 3 个术语的查询中添加了一个 NOT 术语： ![](./benchmark_manticore3_vs_sphinx3/95p-latency-of-3-AND-terms-from-groups-300-600-and-1-NOT-from-300-400.png) ![](./benchmark_manticore3_vs_sphinx3/Throughput-of-3-AND-terms-from-groups-300-600-and-1-NOT-from-300-400.png) **吞吐量 - 高出 66.6%，95% 分位延迟 - 降低 57%。** # 结论 Sphinx 在 21 分钟的索引过程中表现出几秒更好的索引性能。 **至于搜索性能，我们认为这更为重要，Manticore 3.0.0 在所有测试中都表现出更高的吞吐量和更低的延迟。** 整个测试完全使用 Docker 容器化，并且 [在我们的 GitHub 上开源](https://github.com/manticoresoftware/benchmarks/tree/53aa3b1c7f905319e854c537baf8524c6b919404/hn_sphinx_manticore)。详细结果可以在 [此处](https://docs.google.com/spreadsheets/d/1rYveMSw7P5Ll0OjSIhGOABf1WraIlFTkEs5NGGASFHI/edit?usp=sharing) 找到。如果您在自己的硬件上运行相同的测试或添加不同的测试套件并告知我们结果，我们将不胜感激。 如果您正在考虑迁移到 Manticore 3，请阅读 [这篇文章](https://manticoresearch.com/blog/migrating-indexes-to-version-3/)。我们理解您的索引可能很大，为了简化迁移过程，有一个新工具 [index_converter](https://docs.manticoresearch.com/latest/html/command_line_tools_reference/index_converter_command_reference.html#index-converter-command-reference) 可以轻松将您现有的 Sphinx 2 / Manticore 2 索引转换为新的 Manticore 3 索引格式。 如果您有任何问题、疑问或评论，请随时联系我们： - 在 [twitter](https://twitter.com/manticoresearch) - 通过电子邮件发送至 - 在我们的 [论坛](https://forum.manticoresearch.com) 上发帖 - 在我们的 [社区 Slack](http://slack.manticoresearch.com) 上与我们聊天 - 在我们的 [GitHub 上的错误跟踪器](https://github.com/manticoresoftware/manticore) 上抱怨一切多么糟糕