与替代方案的比较
网络上有许多搜索引擎,包括开源的和其他类型的。 决定哪个搜索解决方案最适合您的项目非常重要,但也非常困难。 在本文中,我们将介绍 Meilisearch 和其他搜索引擎之间的差异
-
在比较表中,我们概述了 Meilisearch 和其他搜索引擎之间的总体差异
-
在方法比较中,我们重点介绍 Meilisearch 如何与目前市场上最大的两个解决方案ElasticSearch 和Algolia 相比较
-
最后,我们将在本文的最后深入分析更广泛的搜索引擎格局
注意
请注意,下面描述的许多搜索产品都在不断发展——就像 Meilisearch 一样。 这些只是我们自己的印象,可能无法反映最近的变化。 如果有任何不准确之处,请随时打开issue 或 pull request。
比较表
总体概述
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
源代码许可 | MIT (完全开源) | 闭源 | GPL-3 (完全开源) | SSPL (非开源) |
构建于 | Rust 了解为什么我们相信 Rust. | C++ | C++ | Java |
数据存储 | 磁盘内存映射——不受 RAM 限制 | 受 RAM 限制 | 受 RAM 限制 | 带 RAM 缓存的磁盘 |
功能
集成和 SDK
注意:我们仅列出每个不同搜索引擎的内部团队官方支持的库。
找不到您希望我们支持的客户端? 提交您的想法或为其投票 😇
SDK | Meilisearch | Algolia | Typesense | Elasticsearch |
---|---|---|---|---|
REST API | ✅ | ✅ | ✅ | ✅ |
JavaScript 客户端 | ✅ | ✅ | ✅ | ✅ |
PHP 客户端 | ✅ | ✅ | ✅ | ✅ |
Python 客户端 | ✅ | ✅ | ✅ | ✅ |
Ruby 客户端 | ✅ | ✅ | ✅ | ✅ |
Java 客户端 | ✅ | ✅ | ✅ | ✅ |
Swift 客户端 | ✅ | ✅ | ✅ | ❌ |
.NET 客户端 | ✅ | ✅ | ✅ | ✅ |
Rust 客户端 | ✅ | ❌ | 🔶 开发中 | ✅ |
Go 客户端 | ✅ | ✅ | ✅ | ✅ |
Dart 客户端 | ✅ | ✅ | ✅ | ❌ |
Symfony | ✅ | ✅ | ✅ | ❌ |
Django | ❌ | ✅ | ❌ | ❌ |
Rails | ✅ | ✅ | 🔶 开发中 | ✅ |
官方 Laravel Scout 支持 | ✅ | ✅ | ❌ 作为独立模块提供 | ❌ 作为独立模块提供 |
Instantsearch | ✅ | ✅ | ✅ | ✅ |
Autocomplete | ✅ | ✅ | ✅ | ✅ |
Docsearch | ✅ | ✅ | ✅ | ❌ |
Strapi | ✅ | ✅ | ❌ | ❌ |
Gatsby | ✅ | ✅ | ✅ | ❌ |
Firebase | ✅ | ✅ | ✅ | ❌ |
配置
文档架构
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
无架构 | ✅ | ✅ | 🔶 需要 id 字段,并且必须是字符串 | ✅ |
嵌套字段支持 | ✅ | ✅ | ✅ | ✅ |
嵌套文档查询 | ❌ | ❌ | ❌ | ✅ |
自动文档 ID 检测 | ✅ | ❌ | ❌ | ❌ |
原生文档格式 | JSON 、NDJSON 、CSV | JSON | NDJSON | JSON 、NDJSON 、CSV |
压缩支持 | Gzip、Deflate 和 Brotli | Gzip | ❌ 将有效负载读取为 JSON,这可能导致文档损坏 | Gzip |
相关性
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
容错 | ✅ | ✅ | ✅ | 🔶 需要由模糊查询指定 |
可排序的排名规则 | ✅ | ✅ | 🔶 可以更改字段权重,但无法更改排名规则的顺序。 | ❌ |
自定义排名规则 | ✅ | ✅ | ✅ | 🔶 函数评分查询 |
查询字段权重 | ✅ | ✅ | ✅ | ✅ |
同义词 | ✅ | ✅ | ✅ | ✅ |
停用词 | ✅ | ✅ | ❌ | ✅ |
自动语言检测 | ✅ | ✅ | ❌ | ❌ |
支持所有语言 | ✅ | ✅ | ✅ | ✅ |
排名得分详细信息 | ✅ | ✅ | ❌ | ✅ |
安全
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
API 密钥管理 | ✅ | ✅ | ✅ | ✅ |
租户令牌和多租户索引 | ✅ 多租户支持 | ✅ | ✅ | ✅ 基于角色 |
搜索
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
占位符搜索 | ✅ | ✅ | ✅ | ✅ |
多索引搜索 | ✅ | ✅ | ✅ | ✅ |
联合搜索 | ✅ | ❌ | ❌ | ✅ |
精确短语搜索 | ✅ | ✅ | ✅ | ✅ |
地理搜索 | ✅ | ✅ | ✅ | ✅ |
排序依据 | ✅ | 🔶 每个索引仅限于一条 sort_by 规则。 每个排序字段和排序顺序可能需要重复索引 | ✅ 每个搜索查询最多 3 个排序字段 | ✅ |
筛选 | ✅ 支持使用类似 SQL 语法的复杂筛选查询。 | 🔶 不支持跨多个字段的 OR 操作 | ✅ | ✅ |
分面搜索 | ✅ | ✅ | ✅ 分面字段必须可搜索 当必须返回超过 1000 万个分面值时,分面可能需要几秒钟的时间 | ✅ |
不同属性 按字段值删除重复文档 | ✅ | ✅ | ✅ | ✅ |
分组 按字段值将文档分组 | ❌ | ✅ | ✅ | ✅ |
AI驱动的搜索
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
语义搜索 | ✅ | 🔶 高级计划下 | ✅ | ✅ |
混合搜索 | ✅ | 🔶 高级计划下 | ✅ | ✅ |
嵌入生成 | ✅ OpenAI HuggingFace REST 嵌入器 | 未公开 | OpenAI GCP Vertex AI | ❌ |
提示模板 | ✅ | 未公开 | ❌ | ❌ |
向量存储 | ✅ | 未公开 | ✅ | ✅ |
Langchain 集成 | ✅ | ❌ | ✅ | ✅ |
GPU 支持 | ✅ CUDA | 未公开 | ✅ CUDA | ❌ |
可视化
部署
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
自托管 | ✅ | ❌ | ✅ | ✅ |
平台支持 | ARM x86 x64 | 不适用 | 🔶 ARM(需要在 macOS 上使用 Docker) x86 x64 | ARM x86 x64 |
官方一键部署 | ✅ DigitalOcean Platform.sh Azure Railway Koyeb | ❌ | 🔶 仅适用于云托管解决方案 | ❌ |
官方云托管解决方案 | Meilisearch Cloud | ✅ | ✅ | ✅ |
高可用性 | 通过 Meilisearch Cloud 提供 | ✅ | ✅ | ✅ |
运行时依赖 | 无 | 不适用 | 无 | 无 |
向后兼容性 | ✅ | 不适用 | ✅ | ✅ |
升级路径 | 升级时自动重新索引文档 | 不适用 | 升级时自动重新索引文档 | 升级时自动重新索引文档,最多跨一个主要版本 |
限制
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
最大索引数 | 无限制 | 1000,可通过联系支持增加限制 | 无限制 | 无限制 |
最大索引大小 | 80TiB | 128GB | 受 RAM 约束 | 无限制 |
每个属性的最大字数 | 无限制 | 无限制 | 无限制 | 无限制 |
最大文档大小 | 无限制 | 100KB,可配置 | 无限制 | 默认 100KB,可配置 |
社区
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
主项目的 GitHub 星数 | 42K | 不适用 | 17K | 66K |
主项目的贡献者人数 | 179 | 不适用 | 38 | 1,900 |
公共 Discord/Slack 社区规模 | 2,100 | 不适用 | 2,000 | 16K |
支持
Meilisearch | Algolia | Typesense | Elasticsearch | |
---|---|---|---|---|
状态页面 | ✅ | ✅ | ✅ | ✅ |
免费支持渠道 | 即时消息/聊天框(延迟 2-3 小时), 电子邮件, 公共 Discord 社区, GitHub 问题和讨论 | 即时消息/聊天框, 公共社区论坛 | 即时消息/聊天框(延迟 24-48 小时), 公共 Slack 社区, GitHub 问题。 | 公共 Slack 社区, 公共社区论坛, GitHub 问题 |
付费支持渠道 | 支持是免费的! | 电子邮件 | 电子邮件, 电话, 私有 Slack | 网络支持, 电子邮件, 电话 |
方法比较
Meilisearch vs Elasticsearch
Elasticsearch 被设计为后端搜索引擎。尽管它不适合此目的,但它通常用于为最终用户构建搜索栏。
Elasticsearch 可以处理搜索大量数据和执行文本分析。为了使其有效地用于最终用户搜索,您需要花费时间了解 Elasticsearch 的内部工作原理,以便能够自定义和调整它以满足您的需求。
与 Elasticsearch(一种为大量日志数据设计的通用搜索引擎,例如,面向后端的搜索)不同,Meilisearch 旨在提供针对最终用户的性能卓越的即时搜索体验(例如,面向前端的搜索)。
如果您想提供完整的即时搜索体验,Elasticsearch 有时会太慢。与 Meilisearch 相比,它在返回搜索结果时通常会慢得多。
如果您需要一个简单易用的工具来部署容错搜索栏,Meilisearch 是一个完美的选择。它提供前缀搜索功能,使搜索对用户直观,并开箱即用地即时返回具有出色相关性的结果。
有关其与 Meilisearch 比较的更详细分析,请参阅我们关于 Elasticsearch 的博客文章。
Meilisearch vs Algolia
Meilisearch 的灵感来自 Algolia 的产品及其背后的算法。我们确实研究了他们博客文章中描述的大部分算法和数据结构,以便实现我们自己的算法和数据结构。因此,Meilisearch 是一种基于 Algolia 的工作和最近研究论文的新型搜索引擎。
Meilisearch 提供类似的功能,并且与其竞争对手一样快地达到相同的相关性级别。
如果您是目前正在考虑切换到 Meilisearch 的 Algolia 用户,您可能会对我们的迁移指南感兴趣。
主要相似之处
Algolia 和 Meilisearch 之间最显着的一些相似之处是
- 功能,例如边输入边搜索、容错、分面等。
- 针对即时搜索体验的快速结果(响应 < 50 毫秒)
- 无模式索引
- 支持所有 JSON 数据类型
- 异步 API
- 类似的查询响应
主要区别
与 Algolia 相反,Meilisearch 是开源的,可以分叉或自托管。
此外,Meilisearch 是用 Rust 编写的,这是一种现代系统级编程语言。Rust 提供速度、可移植性和灵活性,这使得我们的搜索引擎在虚拟机、容器甚至 Lambda@Edge 内的部署实现无缝操作。
定价
Algolia 的定价模式 基于保留的记录数和执行的 API 操作数。对于中小型企业来说,它的价格可能高得令人望而却步。
Meilisearch 是一个开源搜索引擎,可通过 Meilisearch Cloud 或自托管获得。与 Algolia 不同,Meilisearch 定价 基于存储的文档数和执行的搜索操作数。但是,Meilisearch 提供更慷慨的免费套餐,允许存储更多文档以及更公平的搜索使用定价。Meilisearch 还为更大的用例提供 Pro 套餐,以实现更可预测的定价。
快速浏览搜索引擎格局
开源
Lucene
Apache Lucene 是一个免费开源的搜索库,用于索引和搜索全文文档。它由 Doug Cutting 于 1999 年创建,Doug Cutting 之前曾在 Xerox 的 Palo Alto Research Center (PARC) 和 Apple 编写搜索引擎。Lucene 用 Java 编写,旨在构建诸如 Google 和 DuckDuckGo 之类的网络搜索应用程序,后者仍然对某些类型的搜索使用 Lucene。
此后,Lucene 已被划分为多个项目
- Lucene 本身:全文搜索库。
- Solr:具有强大 REST API 的企业搜索服务器。
- Nutch:一个依赖于 Apache Hadoop 的可扩展且可伸缩的网络爬虫。
由于 Lucene 是许多开源或闭源搜索引擎背后的技术,因此它被认为是参考搜索库。
Sonic
Sonic 是一个用 Rust 编写的轻量级且无模式的搜索索引服务器。Sonic 不能被视为开箱即用的解决方案,与 Meilisearch 相比,它不保证相关性排名。它不存储文档,而是包含一个带有 Levenshtein 自动机的倒排索引。这意味着任何查询 Sonic 的应用程序都必须使用返回的 ID 从外部数据库检索搜索结果,然后应用一些相关性排名。
它能够在少量 MB 的 RAM 上运行,这使其成为数据库工具的简约且资源高效的替代方案,而数据库工具的扩展成本可能太高。
Typesense
与 Meilisearch 一样,Typesense 是一种针对速度优化的轻量级开源搜索引擎。为了更好地了解它与 Meilisearch 的比较,请参阅我们关于 Typesense 的博客文章。
Lucene 衍生产品
Lucene-Solr
Solr 是 Apache Lucene 的一个子项目,由 Yonik Seeley 于 2004 年创建,如今已成为全球最广泛使用的搜索引擎之一。Solr 是一个用 Java 编写并基于 Lucene 构建的搜索平台。换句话说,Solr 是 Lucene Java API 的 HTTP 包装器,这意味着您可以通过使用它来利用 Lucene 的所有功能。此外,Solr 服务器与 Solr Cloud 相结合,提供分布式索引和搜索功能,从而确保高可用性和可扩展性。数据被共享,但也自动复制。此外,Solr 不仅仅是一个搜索引擎;它通常用作文档结构的 NoSQL 数据库。文档存储在集合中,这些集合可与关系数据库中的表相媲美。
由于其可扩展的插件架构和可自定义的功能,Solr 是一种具有无数用例的搜索引擎,尽管由于它可以索引和搜索文档和电子邮件附件,因此它特别受企业搜索的欢迎。
Bleve & Tantivy
Bleve 和 Tantivy 是搜索引擎项目,分别用 Golang 和 Rust 编写,灵感来自 Apache Lucene 及其算法(例如,tf-idf,term frequency-inverse document frequency 的缩写)。与 Lucene 一样,两者都是用于任何搜索项目的库;但是,它们不是即用型 API。
开源
Elasticsearch
Elasticsearch 是一个基于 Lucene 库的搜索引擎,最常用于全文搜索。 它提供了一个通过 HTTP 以 JSON 格式访问的 REST API。 其关键选项之一,称为索引分片,使您能够将索引划分为物理空间,以提高性能并确保高可用性。 Lucene 和 Elasticsearch 都是为处理大量数据流、分析日志和运行复杂查询而设计的。 您可以对匹配指定查询的文档执行操作和分析(例如,计算所有名为“Thomas”的用户的平均年龄)。
如今,Lucene 和 Elasticsearch 在搜索引擎领域占据主导地位。 它们都是用于许多不同搜索用例的可靠解决方案,也可用于构建您自己的推荐引擎。 它们是优秀的通用产品,但需要正确配置才能获得与 Meilisearch 或 Algolia 相似的结果。
闭源
Algolia
Algolia 是一家以 SaaS 模式提供搜索引擎的公司。 它的软件是闭源的。 在早期阶段,Algolia 提供了可以嵌入到应用程序中的移动搜索引擎,面临着从头开始实现搜索算法的挑战。 从一开始,就决定构建一个直接为最终用户服务的搜索引擎,特别是,在移动应用程序或网站内实现搜索。 Algolia 在过去几年中成功地证明了容忍拼写错误对于改善用户体验至关重要,并且同样,它对降低跳出率和提高转化率的影响。
除了 Algolia 之外,搜索引擎市场上还有多种 SaaS 产品可供选择。 其中大多数都使用 Elasticsearch 并微调其设置,以便获得定制和个性化的解决方案。
Swiftype
Swiftype 是一家专门从事网站搜索和分析的搜索服务提供商。 Swiftype 于 2012 年由 Matt Riley 和 Quin Hoxie 创立,自 2017 年 11 月起归 Elastic 所有。它是一个构建在 Elasticsearch 之上的端到端解决方案,这意味着它有能力利用 Elastic Stack。
Doofinder
Doofinder 是一项付费的站内搜索服务,旨在以极少的配置集成到任何网站中。 Doofinder 被在线商店用来增加销售额,旨在方便购买过程。
结论
每种搜索解决方案都最适合特定用例的限制。 由于每种类型的搜索引擎都提供一组独特的功能,因此比较它们的性能既不容易也不相关。 例如,比较 Elasticsearch 和 Algolia 在基于产品的数据库上的速度是不公平的。 对于非常大的基于全文的数据库也是如此。
因此,我们不能将自己与基于 Lucene 的或其他针对特定任务的搜索引擎进行比较。
在我们所涵盖的特定用例中,与 Meilisearch 最相似的解决方案是 Algolia。
虽然 Algolia 提供了最先进和最强大的搜索功能,但这种效率的代价是价格昂贵。 此外,他们的服务主要面向大型公司。
Meilisearch 致力于为所有类型的开发人员服务。 我们的目标是提供一种对开发者友好的工具,易于安装和部署。 因为为最终用户提供开箱即用的出色搜索体验对我们来说很重要,所以我们希望让每个人都能以最少的努力并且无需任何财务资源即可获得最佳搜索体验。
通常,当开发人员正在寻找集成到其应用程序中的搜索工具时,他们会选择 ElasticSearch 或效果较差的选择。 即使 Elasticsearch 不是最适合此用例,它仍然是一个很好的开源解决方案。 但是,它需要技术知识才能执行高级功能,因此需要更多时间来根据您的业务进行自定义。
我们的目标是成为开发人员的默认解决方案。