引言
在不断发展的数字环境中，搜索引擎在推动各种平台的搜索功能中扮演着越来越重要的角色。在流行的搜索引擎中， 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 ）。列存储方法专门设计用以加速搜索性能并降低大型数据集上的 RAM 消耗。相比之下，Manticore Search 的默认行存储在小型和中型数据集上表现出色。这种灵活性使 Manticore Search 成为各种应用的理想选择。
另一方面，Meilisearch 在处理较大数据集时表现不佳，因为我们无法在搜索引擎中加载 Hacker News 大型数据集 ，即使经过 2 天的加载。此外，Meilisearch 在加载文档时表现出性能下降。随着数据集的增长，加载每个后续文档批次所需的时间会增加。这个性能问题表明 Meilisearch 在数据可扩展性方面存在问题，这可能会对需要实时数据摄取或大型数据集索引的应用造成困扰。Meilisearch 在处理文档更新时采用单队列，可能导致瓶颈，进而随时间降低性能。
需要注意的是，Meilisearch 中的文档更新不会立即反映在搜索查询中。这是因为 Meilisearch 使用了异步任务队列来处理更新，确保即使在进行密集索引操作时，搜索性能仍然保持稳定。
在更新文档时，变更会被添加到任务队列中，并在后台由引擎处理。一旦任务完成，更新的数据便会在搜索结果中可用。处理时间可能因更新大小和服务器资源而异。要监控任务状态，您可以利用 任务 API ，该 API 提供有关任务进度和完成情况的信息。
Manticore 提供实时插入、替换和删除功能，允许变更在查询完成后立即可见。
总之，尽管 Meilisearch 提供快速高效的搜索能力，但请注意，文档更新可能不会因异步任务处理而立即在搜索结果中可见。
Search Performance
Meilisearch以其卓越的速度而闻名， 在许多情况下超越Elasticsearch 。然而，它的表现最明显是在处理小型数据集时。随着数据集大小的增加，Meilisearch的性能可能会下降。
Manticore Search对各种查询类型和数据集类型始终提供快速的查询性能，超越了Meilisearch和 Elasticsearch 。通过优化的行式和列式索引方法，Manticore确保了响应迅速的搜索体验，这对于在高性能应用中维护用户参与度至关重要。
相比之下，Meilisearch在高效处理大型数据集方面存在困难，并且在文档加载期间性能下降。因此，Manticore是那些不想担心数据集大小的用户的更优选择。
Benchmark Tests
Hacker News Small Dataset (Hacker News Comments)
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需要34倍的磁盘空间存储与Manticore Search相同的数据集。
就数据加载性能而言，耗时为：
- Meilisearch 31分钟
- Manticore 65秒
以完全完成数据加载。
Hacker News Large Dataset (116 million comments)
此测试涉及同一1.1百万条经过筛选的Hacker News评论数据集（来源： https://zenodo.org/record/45901/ ），但乘以100倍，结果约为 1.16亿文档 。基准测试涵盖全文和分析查询，使其成为评估搜索引擎在更大规模上能力的绝佳测试案例。
Meilisearch在两天内无法加载数据。随着数据库的增长，其插入性能下降。我们尝试优化它，但未能成功，因为所有批次，即使我们尝试使它们并行，也都进入了单个队列。因此，我们无法为Meilisearch的数加载实现任何改善。Meilisearch加载了只有38%的数据，已经消耗了超过850 GB的磁盘空间，花费了约2天。这与Manticore Search形成鲜明对比，后者使用大约100 GB的磁盘空间存储了整个数据集，并在2小时9分钟内用单个CPU核心加载（几乎是线性可扩展的）。
Meilisearch无法处理整个Hacker News大型数据集，凸显了其在管理和扩展更大数据集方面的挑战。Manticore Search在此基准测试中的优越表现强调了其处理大规模搜索需求的能力，使其更适合大型数据集的应用。
由于我们无法将数据加载到Meilisearch中，您可以在 此处 查看仅Manticore的结果。
10 million NGINX logs
此测试基于包含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分钟内完成。
您可以在 提供的链接 中找到详细的性能结果比较。请注意，许多空结果仅仅是因为Meilisarch无法处理某些类型的查询。因此，这些查询在基准测试过程中被跳过。
Manticore Search 和 Meilisearch 的特性对比
- 全文匹配
- ✅ Manticore: 超过 20 种全文操作符。反向搜索。
- ❌ Meilisearch: 非常简单：AND 和短语搜索。没有反向搜索。
- 搜索相关性
- 存储
- ✅ 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 具有方便的搜索预览 - 内置用户界面，可在实例中搜索数据。
- ❌ 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 之间的选择将取决于您的具体需求和项目要求。