在不断发展的数字环境中,搜索引擎在支持各种平台的搜索功能方面发挥着越来越重要的作用。在流行的搜索引擎中,美丽搜索和Manticore 搜索以其独特的产品脱颖而出。
但是,为您的项目选择合适的搜索引擎需要透彻了解它们的性能、用例和限制。本文旨在对 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 。
相比之下,美力搜索声称提供良好的搜索相关性,但没有可用的公共基准来证实这一说法。根据Hacker News上的讨论,美力搜索的用户提到了它的搜索相关性,但没有任何经验证据,很难客观地将其性能与 Manticore Search 进行比较。
总体而言,Manticore Search 使用经过验证的排名算法并参与了 BEIR 基准测试,这凸显了其致力于提供高度相关的搜索结果的承诺,使其成为各种应用程序的可靠选择。虽然美力搜索在全文搜索相关性方面也可能表现出色,但很难做出明确的声明,因为没有既定的基准,而且所使用的算法也不广为人知。
Manticore Search 展示了其通过使用行式和列式存储有效处理大型数据集的能力(例如17 亿文档出租车乘坐测试或简单的Craigslist.org )。列式方法专门设计用于加速搜索性能并降低大型数据集上的 RAM 消耗。相比之下,Manticore Search 的默认行存储在中小型数据集上提供了无与伦比的性能。这种灵活性使 Manticore Search 成为广泛应用的理想选择。
另一方面,美力搜索在处理更大的数据集时遇到了困难,因为我们无法将Hacker News 更大的数据集加载到搜索引擎中,即使在加载 2 天后也是如此。此外,美里搜索在加载文档时会出现性能下降。随着数据集的增长,加载每批后续文档所需的时间也会增加。此性能问题表明 Meilisearch 在数据可扩展性方面存在问题,并且对于需要实时数据摄取或大型数据集索引的应用程序可能会出现问题。 Meilisearch 在单个队列中处理文档更新,随着时间的推移,这可能会导致瓶颈和性能下降。
值得注意的是,美丽搜索中的文档更新不会立即反映在搜索查询中。这是因为美力搜索采用异步任务队列来处理更新,即使在密集的索引操作中也能确保搜索性能保持稳定。
更新文档时,更改将添加到任务队列并由引擎在后台处理。任务完成后,更新的数据将在搜索结果中可用。处理时间可能因更新大小和服务器资源而异。要监视任务状态,您可以使用Tasks API ,它提供有关任务进度和完成情况的信息。
rt、replace 和 delete 功能,允许更改在查询完成后立即可见。
总之,虽然美丽搜索提供了快速高效的搜索功能,但请记住,由于异步任务处理,文档的更新可能不会立即在搜索结果中可见。
Meilisearch 以其令人印象深刻的速度而闻名, 在许多情况下优于 Elasticsearch 。但是,在处理小型数据集时,其性能最为显着。随着数据集大小的增加,美丽搜索的性能可能会下降。
Manticore Search 始终如一地为各种查询类型和数据集类型提供快速查询性能,优于 Meilisearch 和Elasticsearch 。通过优化的行式和列式索引方法,Manticore 可确保响应式搜索体验,这对于保持用户参与高性能应用程序至关重要。
相比之下,美力搜索在高效处理大型数据集方面举步维艰,并且在文档加载期间性能下降。因此,Manticore 是那些不想担心数据集大小的人的最佳选择。
Hacker News 小型数据集基准收集了 110 万条带有数字字段的精选 Hacker News 评论(来源: https ://zenodo.org/record/45901/),突出了 Manticore Search 优于 Meilisearch 的搜索性能。该数据集包含来自评论和数字字段(例如赞成票、时间戳和用户 ID)的文本数据。基准测试涉及运行全文和分析查询以评估搜索引擎的能力。
也可以通过此链接验证基准测试结果。
不幸的是,美丽搜索无法执行多种类型的查询,例如聚合查询和带有否定全文搜索词的查询。
该基准测试的一个有趣方面是两个搜索引擎之间磁盘空间使用的显着差异:
[email protected] /perf/test_engines/tests/hn_small/manticore # du -sh idx 1.1G idx [email protected] /perf/test_engines/tests/hn_small/meilisearch # du -sh . 38G .
与 Manticore Search 相比,Meilisearch 需要多34 倍的磁盘空间来存储相同的数据集。
在数据加载性能方面,它需要:
以完全完成数据加载。
该测试涉及相同的 110 万条精心策划的 Hacker News 评论数据集(来源: https://zenodo.org/record/45901/ ),但乘以 100 倍,产生约1.16 亿份文档。该基准涵盖全文查询和分析查询,使其成为更大规模评估搜索引擎功能的优秀测试用例。
美力搜索2天无法加载数据。它的插入性能随着数据库的增长而下降。我们试图优化它但没有成功,因为所有批次,即使我们试图使它们并行,都进入了一个队列。因此,我们无法为美力搜索实现任何数据加载方面的改进。美里搜索用了大约 2 天时间才加载了 38% 的数据,这已经占用了超过 850 GB 的磁盘空间。这与 Manticore Search 形成鲜明对比,Manticore Search 使用大约 100 GB 的磁盘空间存储整个数据集,使用单个 CPU 内核(几乎可以线性扩展)加载需要 2 小时 9 分钟。
Meilisearch 无法处理整个 Hacker News 大型数据集,这凸显了它在管理和扩展更广泛的数据集合方面的挑战。 Manticore Search 在此基准测试中的卓越性能凸显了其处理大规模搜索需求的能力,使其成为具有更大数据集合的应用程序的更合适选择。
由于我们无法将数据加载到美丽搜索中,您可以在此处查看仅 Manticore 的结果。
本次测试基于包含 1000 万条 NGINX 日志的数据集。这个数据集的来源是Kaggle 。 Web 服务器日志记录各种事件,为网站访问者、用户行为、访问网站的爬虫、商业智能、安全问题等提供有价值的见解。该基准测试使用了一个精选的典型查询列表,随机 DevOps 工程师可能会运行这些查询。
Manticore Search 和 Meilisearch 在数据集的磁盘空间使用方面表现出显着差异。 Manticore Search 使用了 4.4 GB 的磁盘空间,而 Meilisearch 消耗了 69 GB,大约是 Manticore 的15 倍。尽管差异不如 Hacker News 小型数据集测试那么显着,但仍然值得注意,尤其是考虑到 Logs10m 数据集包含较少的文本数据。
美力搜索大约用了20分钟就填满了数据,而Manticore只用了6分钟。
您可以使用提供的链接找到性能结果的详细比较。请注意,许多空结果仅仅是因为 Meiliesarch 无法处理某些类型的查询。因此,这些查询在基准测试过程中被跳过。
小型项目:美丽搜索的轻量级特性和易于部署的特性使其适用于数据和搜索需求有限的小型项目,例如小型电子商务、个人网站、本地目录或简单的 Web 应用程序,这些应用程序需要快速加载数据,高级搜索功能和可扩展性不是关键因素。
在为您的项目选择搜索引擎时,考虑搜索相关性、可扩展性和性能等因素至关重要。 Manticore Search 脱颖而出,成为各种应用程序和用例的最佳选择,无论数据集大小如何,都能确保最佳的搜索性能和相关性。其高级搜索和分析功能使其成为需要高性能搜索功能的项目的可靠选择。
Meilisearch 适用于高级搜索功能和可扩展性不是关键因素的小型项目。
最终,在 Manticore Search 和 Meilisearch 之间做出选择将取决于您的具体需求和项目要求。
也发布在这里。