引言
在不断变化的数字环境中，搜索引擎在各种平台的搜索功能中发挥着越来越关键的作用。在流行的搜索引擎中， Meilisearch 和 Manticore Search 凭借其独特的功能脱颖而出。然而，为您的项目选择合适的搜索引擎需要深入了解其性能、使用场景和限制。本文旨在比较 Meilisearch 和 Manticore Search，重点分析其功能集以及在三个真实世界基准测试中的数据摄入和搜索性能：1000万 NGINX 日志、Hacker News 110万文档数据集和 Hacker News 1.16亿文档数据集，所有数据集均可在 DB Benchmarks 获取。所有性能测试脚本、配置和数据集均 公开可用 并可复现。
全文搜索相关性
Manticore 和 Meilisearch 都将自己定位为全文搜索引擎。全文搜索引擎的关键要素是它们在搜索过程中如何对文档进行排序。
选择合适的搜索排序算法对于确保用户能够精确且全面地找到所需信息至关重要。在全文搜索相关性的背景下，理解这些算法的工作原理及其如何贡献于提供准确且有意义的搜索结果非常重要。
Manticore Search 在控制搜索排序方面非常灵活，提供了数十个排序因素；然而，默认情况下，它采用经典的 BM25 算法及其衍生算法。 BM25 是一种成熟的信息检索算法，它基于词频和逆文档频率计算文档的相关性。
BEIR（信息检索基准测试和评估）基准的 持续拉取请求 展示了 Manticore Search 对搜索相关性的承诺。BEIR 是一个评估框架，用于衡量信息检索系统在各种任务（如文档检索和问答）中的性能。BEIR 基准的结果可在此处找到： https://docs.google.com/spreadsheets/d/1_ZyYkPJ_K0st9FJBrjbZqX14nmCCPVlE_y3a_y5KkYI/edit#gid=0 。
相比之下，Meilisearch 声称提供良好的搜索相关性，但目前没有公开的基准测试来支持这一说法。根据 Hacker News 上的一次讨论，Meilisearch 用户提到了其搜索相关性，但由于缺乏实证数据，很难客观地将其性能与 Manticore Search 进行比较。
总体而言，Manticore Search 使用经过验证的排序算法并参与 BEIR 基准测试，突显了其致力于提供高度相关搜索结果的承诺，使其成为各种应用的可靠选择。虽然 Meilisearch 可能在全文搜索相关性方面也表现出色，但由于缺乏已建立的基准测试且使用的算法不为人知，很难做出明确的结论。
索引大小和数据摄入
Manticore Search 通过使用行式和列式存储来展示其有效处理大型数据集（例如 17亿条出租车行程测试 或简单地 Craigslist.org ）的能力。列式方法专门设计用于加速大型数据集的搜索性能并降低内存消耗。相比之下，Manticore Search 的默认行式存储在小型和中型数据集上提供了无与伦比的性能。这种灵活性使 Manticore Search 成为各种应用的理想选择。
另一方面，Meilisearch 在处理大型数据集时遇到困难，因为我们甚至在加载 Hacker News 更大数据集 两天后仍无法将其加载到搜索引擎中。此外，Meilisearch 在加载文档时会出现性能下降。随着数据集的增长，加载每个后续文档批次所需的时间会增加。这种性能问题表明 Meilisearch 在数据可扩展性方面存在问题，可能对需要实时数据摄入或大型数据集索引的应用程序造成问题。Meilisearch 通过单个队列处理文档更新，这可能导致瓶颈并随着时间推移降低性能。
需要特别注意的是，Meilisearch 中的文档更新不会立即反映在搜索查询中。这是因为 Meilisearch 使用异步任务队列来处理更新，即使在密集的索引操作期间也能确保搜索性能保持稳定。
当更新文档时，更改会被添加到任务队列中，并由引擎在后台处理。一旦任务完成，更新后的数据将在搜索结果中可用。处理时间会根据更新大小和服务器资源而有所不同。要监控任务状态，可以使用 Tasks API ，它提供有关任务进度和完成情况的信息。
Manticore 提供实时插入、替换和删除功能，允许更改在查询完成后立即可见。
总之，虽然 Meilisearch 提供了快速且高效的搜索功能，但请记住，由于异步任务处理，文档更新可能不会立即在搜索结果中显示。
搜索性能
Meilisearch 以其出色的速度而闻名， 在许多情况下优于 Elasticsearch 。然而，当处理小数据集时，其性能最为明显。随着数据集大小的增加，Meilisearch 的性能可能会下降。
Manticore Search 一致提供各种查询类型和数据集类型的快速查询性能，优于 Meilisearch 和 Elasticsearch 。通过优化的逐行和列式索引方法，Manticore 确保了响应式的搜索体验，这对于在高性能应用程序中保持用户参与度至关重要。
相比之下，Meilisearch 在处理大数据集时效率低下，并且在加载文档期间会遭受性能下降。因此，对于那些不想担心数据集大小的人来说，Manticore 是更优的选择。
基准测试
Hacker News 小型数据集（Hacker News 评论）
Hacker News 小型数据集基准测试包含 110 万个精选的 Hacker News 评论（来源： https://zenodo.org/record/45901/ ），这些评论包含数字字段，突显了 Manticore Search 相比 Meilisearch 更高的搜索性能。该数据集包含评论的文本数据以及如点赞数、时间戳和用户 ID 等数字字段。基准测试包括运行全文和分析查询以评估搜索引擎的能力。
基准测试结果也可以通过 此链接 验证。
不幸的是，Meilisearch 无法执行许多类型的查询，例如聚合查询和包含负向全文搜索术语的查询。
这个基准测试的一个有趣方面是两个搜索引擎在磁盘空间使用上的显著差异：
root@perf3 /perf/test_engines/tests/hn_small/manticore # du -sh idx
1.1G idx
root@perf3 /perf/test_engines/tests/hn_small/meilisearch # du -sh .
38G .
Meilisearch 存储相同数据集所需的磁盘空间是 Manticore Search 的 34 倍。
在数据加载性能方面，耗时：
- Meilisearch 31 分钟
- Manticore 65 秒
才能完全完成数据加载。
Hacker News 大型数据集（1.16 亿条评论）
此测试使用相同的 110 万个精选 Hacker News 评论数据集（来源： https://zenodo.org/record/45901/ ），但乘以 100 倍，结果约为 1.16 亿条文档 。基准测试涵盖全文和分析查询，使其成为评估搜索引擎在更大规模上能力的绝佳测试用例。
Meilisearch 在 2 天内无法加载数据。随着数据库的增长，其插入性能下降。我们尝试优化它但未成功，因为即使我们尝试让批次并行处理，所有批次仍进入单个队列。因此，我们无法在 Meilisearch 的数据加载上实现任何改进。Meilisearch 大约用了 2 天时间仅加载了 38% 的数据，这已经消耗了超过 850 GB 的磁盘空间。这与 Manticore Search 形成鲜明对比，后者使用约 100 GB 的磁盘空间存储整个数据集，并使用单个 CPU 核心在 2 小时 9 分钟内完成加载（这几乎线性可扩展）。
Meilisearch 无法处理整个 Hacker News 大型数据集，突显了其在管理和扩展更大数据集方面的挑战。Manticore Search 在此基准测试中的卓越性能证明了其处理大规模搜索需求的能力，使其成为具有更大数据集的应用程序的更合适选择。
由于我们无法将数据加载到 Meilisearch 中，您可以在此处查看仅 Manticore 的结果 here 。
1000 万 NGINX 日志
此测试基于包含 1000 万 NGINX 日志的数据集。该数据集的来源是 Kaggle 。Web 服务器日志记录各种事件，为网站访问者、用户行为、访问网站的爬虫、商业智能、安全问题等提供有价值的见解。基准测试使用了一组精选的典型查询，这些查询是随机 DevOps 工程师可能运行的。
Manticore Search 和 Meilisearch 在该数据集的磁盘空间使用上表现出显著差异。Manticore Search 使用了 4.4 GB 的磁盘空间，而 Meilisearch 消耗了 69 GB，这大约是 Manticore 的 15 倍。尽管与 Hacker News 小型数据集测试相比，这种差异不那么显著，但仍然值得注意，特别是考虑到 Logs10m 数据集包含的文本数据更少。
Meilisearch 填充数据大约需要 20 分钟，而 Manticore 仅用了 6 分钟。
您可以通过 提供的链接 查看性能结果的详细比较。请注意，许多空结果仅仅是由于 Meilisearch 无法处理某些类型的查询。因此，这些查询在基准测试过程中被跳过了。
Manticore Search 和 Meilisearch 的功能对比
- 全文匹配
- ✅ Manticore：拥有20多个全文操作符。Percolate搜索（反向搜索）。
- ❌ Meilisearch：非常简单：AND和短语搜索。没有Percolate搜索。
- 搜索相关性
- 存储
- ✅ Manticore：自有行式存储适用于小/中型数据集，自有列式存储具有较低的RAM需求，适合大型数据集。
- ❌ Meilisearch： LMDB ，具有其所有优点、缺点和后果：例如，对于9.1 MB的数据集，需要205GB的虚拟内存似乎很奇怪。
- 索引大小和数据加载
- ✅ Manticore通过列式和行式索引方法支持大型数据集。轻松从MySQL、PostgreSQL、MS SQL和任何支持ODBC、XML和CSV的其他数据库同步数据。真正的实时事务插入、替换和删除。二进制日志。原地属性值更新。
- ❌ Meilisearch在处理大型数据集时存在困难，并在文档加载期间经历性能下降。您可以上传CSV和JSON。仅支持异步添加文档。没有原地更新。
- 模式
- ✅ Manticore：自动模式。自动ID。默认情况下所有属性均可过滤、排序和分组。
- ❌ Meilisearch：自动模式。ID可以从文档中自动选择。默认情况下所有字段均可全文搜索，但属性不可过滤或排序。在将数据加载到索引之前必须决定模式，以避免完全重新索引。
- 搜索性能
- ✅ Manticore在搜索性能方面优于Meilisearch。
- ❌ Meilisearch不太适合需要快速且可扩展搜索功能的应用程序。
- 高可用性
- ✅ Manticore：复制，支持远程代理的分布式表，以及多种高可用性策略。
- ❌ Meilisearch：没有复制，没有分布式搜索，没有镜像。
- 拼写容错
- ✅ Meilisearch提供更简单的拼写容错。
- ❌ Manticore可以处理拼写容错，但需要在应用程序中付出更高的努力。
- 搜索预览
- ✅ Meilisearch具有有用的搜索预览功能——一个内置的UI，用于在实例中搜索数据。
- ❌ Manticore没有此功能。
- 分词
- ✅ Manticore：高度灵活的分词：分词字符、混合字符、忽略字符、正则表达式分词规则等，词形变化、停用词、同义词、创建分词插件的选项，基于词干提取器和词形还原器的多种语言的形态学。
- ❌ Meilisearch：分词器取决于语言：大多数语言使用Unicode分词器，中文、日文、希伯来文和泰语使用特定分词器。同义词。停用词。
- 认证
- ✅ Meilisearch：内置认证。
- ❌ Manticore：没有内置认证。
- 接口
- ✅ Manticore：以SQL为主，可以使用MySQL客户端连接。HTTP JSON接口。二进制接口用于极低的响应时间。客户端支持：PHP、Python、JavaScript、Java、C#、Elixir、Golang。
- ❌ Meilisearch：HTTP JSON接口。客户端支持：JavaScript、Python、PHP、Java、Ruby、Golang、C#、Rust、Swift、Dart。
- 用例
- ✅ Manticore：日志搜索、电子商务平台、内容丰富的网站、企业应用。
- ❌ Meilisearch：数据量和搜索需求有限的小型项目。
用例
Manticore Search的用例
- 电子商务平台： Manticore Search可以高效管理大型产品目录，通过其 高级分面功能 为客户提供相关搜索结果。这提高了转化率并增强了整体购物体验，使其成为电子商务平台高度需要的功能。
- 内容丰富的网站： Manticore Search可以索引和搜索大量内容库，如新闻网站、博客或知识库。通过适当的全文排名，它确保用户能够快速有效地找到所需信息，从而提高用户参与度。
- 企业应用： Manticore Search的可扩展性和高级搜索功能使其非常适合大规模企业应用，包括客户关系管理（CRM）系统、文档管理系统和内部网络门户，在这些系统中，准确且高效的搜索功能至关重要。
- 日志搜索： Manticore Search非常适合日志搜索，因为它可以高效处理和搜索大量日志。其速度和性能使其成为日志分析和监控的绝佳选择。
Meilisearch的用例
小型项目：Meilisearch的轻量级特性和易于部署使其适合数据量和搜索需求有限的小型项目，如小型电子商务、个人网站、本地目录或简单的Web应用程序，在这些项目中，快速数据加载、高级搜索功能和可扩展性不是关键因素。
结论
在为您的项目选择搜索引擎时，必须考虑搜索相关性、可扩展性和性能等因素。Manticore Search在各种应用和用例中脱颖而出，无论数据集大小，都能确保最佳的搜索性能和相关性。其高级搜索和分析功能使其成为需要高性能搜索功能的项目的可靠选择。
Meilisearch适合小型项目，其中高级搜索功能和可扩展性不是关键因素。
最终，在Manticore Search和Meilisearch之间做出选择将取决于您的具体需求和项目要求。