最近 我们发布了 Manticore 3.0.0 ，其中包含许多改进，包括一些新的优化，提高了性能。在本文中，我们希望将新版本的性能与 Sphinx 3.1.1 的性能进行比较。
TL;DR
Manticore 表现出：
- 在某些情况下，搜索性能大约提高了 2 倍，尤其是在较长查询时
- 在其他所有测试中，性能较低，但仍优于 Sphinx
- 除了索引时间，Sphinx 快 2%
测试环境
正如 我们之前对 Manticore 2.7 与 Sphinx 3 进行基准测试时 ，我们将使用来自 Hacker News 的 1160 万用户评论数据集进行基准测试。
基准测试是在以下条件下进行的：
- Hacker News 精选评论数据集 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 二进制文件从网站下载，因为没有开源代码可供构建
- 压力测试工具 用于基准测试
Manticore 和 Sphinx 的配置相同：
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:
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>1263.497 sec</b>, 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:
indexing index 'full'...
collected 11654429 docs, 6198.6 MB
sorted 1115.7 Mhits, 100.0% done
total 11654429 docs, 6.199 Gb
total <b>1236.9</b> sec, 5.011 Mb/sec, 9422 docs/sec
因此，在这个数据集和索引模式下，Manticore 的索引速度比 Sphinx 慢约 2%。
性能测试
在测试之前，两个实例都进行了预热。索引文件如下：
Manticore:
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:
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 个术语的文档需要多长时间：
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 秒。
因此，在这个测试中，Manticore Search 比 Sphinx Search 快 8.59%。
测试 2 - 按组划分的集合中前 1000 个常见术语（前 1-50，前 50-100 等）
现在让我们看看 Sphinx 和 Manticore 在处理前 1000 个常见术语的子组时有何不同。
为了更好地理解这些查询，这里有一些每个组的随机查询示例：
| 1-50 | 50-100 | 100-150 | 150-200 | 200-250 | 250-300 |
| 关于 | 获取 | 事物 | 使用 | 不同 | 高 |
| 我的 | 工作 | 是 | 关闭 | 系统 | 构建 |
| 更多 | 事物 | 似乎 | 确定 | 没有 | 下一个 |
| 300-350 | 350-400 | 400-450 | 450-500 | 500-550 | 550-600 |
| 天 | 价值 | 20 | 想要 | 价格 | 本身 |
| 编写 | 服务器 | 关心 | 网站 | g | 文件 |
| 没有 | 电话 | 故事 | 最近 | 模型 | 存储 |
| 600-650 | 650-700 | 700-750 | 750-800 | 800-850 | 850-900 |
| 招聘 | 智能 | 欢迎 | 选择 | 被采用 | 主题 |
| 客户 | 愿望 | 想要 | pg | 细节 | 核心 |
| iphone | 原因 | 环境 | 通常 | css | 想知道 |
| 900-950 | 950-1000 | ||||
| 完整 | 关键词 | ||||
| 资源 | 晚 | ||||
| 想法 | ipad |
Manticore 在 95 百分位延迟方面比 Sphinx 快 6.8%，在吞吐量方面快 12.2%。
测试 3 - 从集合中按组分解的前 1000 个高频术语 + 从 1-100 组中选取 1 个术语
让我们看看当您有一个非常频繁的术语和另一个不太频繁的术语时，它的工作方式。例如：
| 1-50 | 50-100 | 100-150 | 150-200 | 200-250 | 250-300 |
| 更多是 | 那已被 | 方式正在 | 一个关闭 | 只是启动 | 已经支付 |
| 它们作为 | 可能其他 | 可以d | 认为自己的 | 真的其他 | 如果设计 |
| 关于是 | 制作然后 | 是等等 | 从应用程序 | 到一点 | 在尚未 |
| 300-350 | 350-400 | 400-450 | 450-500 | 500-550 | 550-600 |
| 只是或者 | 一个互联网 | 谁网络 | 你位置 | 将程序 | t基本上 |
| 不离开 | 通过社交 | t过去 | 一个站点 | 一个几个 | 有公司 |
| 1写 | 有意味着 | 大多数家伙 | 不重要 | 有空间 | 如果基本上 |
| 600-650 | 650-700 | 700-750 | 750-800 | 800-850 | 850-900 |
| 方式程序员 | 看到标题 | 因为词语 | 认为mac | 大多数昂贵 | 时间改变 |
| 是困难 | 我成功 | com客户 | 是听到 | 在极端 | 被食物 |
| 他们的周 | 比yc | 因为精细 | 也桌面 | 为理解 | 大多数流量 |
| 900-950 | 950-1000 | ||||
| 如果派对 | 真的公平 | ||||
| 当认真 | 这里服务器 | ||||
| 认为速度 | 是失去 |
哇，Manticore 的吞吐量比 Sphinx 快 106%，在 95 百分位延迟方面平均快 91.8%。
测试 4 - 从集合中按组分解的前 1000 个高频术语 + 1 个来自组 1-100 的术语，两个术语都用引号括起来以形成短语
| 1-50 | 50-100 | 100-150 | 150-200 | 200-250 | 250-300 |
| "他们全部" | "也认为" | "那段代码" | "我们的应用" | "来自给予" | "由用户" |
| "http 你" | "像被" | "是我们的" | "作为文章" | "使用制作" | "真的至少" |
| "由某些" | "使用工作" | "做得好" | "我应用" | "可能不同" | "如果理解" |
| 300-350 | 350-400 | 400-450 | 450-500 | 500-550 | 550-600 |
| "其他开发者" | "通过构建" | "想创建" | "有前端" | "任何政府" | "他们考虑" |
| "有想法" | "我python" | "谁给予" | "已经完全" | "有价格" | "开始启动" |
| "方式facebook" | "被编辑" | "上链接" | "使用位置" | "真的处理" | "现在早期" |
| 600-650 | 650-700 | 700-750 | 750-800 | 800-850 | 850-900 |
| "已经几周" | "上工程" | "已经询问" | "s p" | "谁css" | "有加号" |
| "制作api" | "我们预期" | "真的愿意" | "t 步骤" | "因为强大" | "为流量" |
| "是笔记" | "会自己" | "http 学位" | "http 桌面" | "不否则" | "很多食物" |
| 900-950 | 950-1000 | ||||
| "s 带来" | "非常需要" | ||||
| "这个选择" | "所有例子" | ||||
| "现在带来" | "成为论点" |
在这里，Manticore 的平均吞吐量提高了 11.8%，95百分位延迟降低了 21.2%。
测试 5 - 从 600-750 组中各取 2 个词在不同并发量下的表现
此测试旨在展示不同查询并发量下的吞吐量差异。我们得到以下结果：
在所有并发量下，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 办公室绝对英语 |
Manticore 的吞吐量高出 77.6%，95% 分位延迟降低了 81.4%。
测试 7：从 300-600 组中取 3 个 AND 术语和从 300-400 组中取 1 个 NOT 术语
在此测试中，我们在 3 个术语的查询中添加了一个 NOT 术语：
吞吐量 - 高出 66.6%，95% 分位延迟 - 降低 57%。
结论
Sphinx 在 21 分钟的索引过程中表现出几秒更好的索引性能。
至于搜索性能，我们认为这更为重要，Manticore 3.0.0 在所有测试中都表现出更高的吞吐量和更低的延迟。 整个测试完全使用 Docker 容器化，并且
在我们的 GitHub 上开源
。详细结果可以在
此处
找到。如果您在自己的硬件上运行相同的测试或添加不同的测试套件并告知我们结果，我们将不胜感激。
如果您正在考虑迁移到 Manticore 3，请阅读 这篇文章 。我们理解您的索引可能很大，为了简化迁移过程，有一个新工具 index_converter 可以轻松将您现有的 Sphinx 2 / Manticore 2 索引转换为新的 Manticore 3 索引格式。
如果您有任何问题、疑问或评论，请随时联系我们：
- 在 twitter
- 通过电子邮件发送至 [email protected]
- 在我们的 论坛 上发帖
- 在我们的 社区 Slack 上与我们聊天
- 在我们的 GitHub 上的错误跟踪器 上抱怨一切多么糟糕