OpenSearch vs Elasticsearch,谁更胜一筹?

开发 项目管理
OpenSearch搜索引擎是亚马逊自2021年1月以来维护的Elasticsearch的一个分支。在fork事件之前,它基本上是相同的代码库,这也是项目开始略有分歧的时候。

Elasticsearch

Elasticsearch是一个流行的搜索引擎,基于Apache Lucene项目(也是Apache Solr的父项目),自2010年以来已被许多人用于搜索和日志分析。它的设计具有高度可扩展性,可用于广泛的应用程序,从简单的搜索功能到复杂的数据分析。

Elasticsearch和Kibana作为Elastic Stack的一部分,都有一套强大的功能,包括支持全文搜索、企业搜索、真实的时间分析和地理空间查询。它曾经在Apache许可证下完全开源,直到2021年初竞争对手亚马逊开始创建自己的项目。Elasticsearch通常部署在自我管理或Elastic Cloud上。

什么是OpenSearch?

OpenSearch搜索引擎是亚马逊自2021年1月以来维护的Elasticsearch的一个分支。在fork事件之前,它基本上是相同的代码库,这也是项目开始略有分歧的时候。OpenSearch的一个关键特征是它对透明度和社区驱动开发的关注。

与Elasticsearch不同,OpenSearch由社区驱动的基金会管理。这意味着任何人都可以为OpenSearch的发展做出贡献。虽然这两个软件产品的代码库都是开放的,任何想要审查它的人都可以检查,但贡献代码和影响OpenSearch的方向比Elasticsearch更容易。它通常用作Amazon OpenSearch Service(以前称为Amazon Elasticsearch Service)的一部分。

在比较这两者时,我们将回顾Codebase作为牵引力和开发工作的信号,以及特性-因此您可以选择哪一个更适合您的需求。

代码库和发布

OpenSearch项目在7.10.2版本是最新版本时派生了Elasticsearch代码库,然后在OpenSearch代码库上进行了大量工作,以重命名项目并清理所有非Apache许可的代码(即X-Pack功能)。为了正确地比较两者所做的工作,我们统计了自2021年4月22日以来在主/主分支上进行的提交,这标志着OpenSearch在几个月前分叉后的第一个候选版本。

Elasticsearch仓库有近20 k次提交,其中6 k次提交到核心Elasticsearch(“服务器”文件夹),还有一些提交到卫星模块:

# total commits in repo since fork
➜  elasticsearch git:(master) git log --oneline --all --since='Apr 22 2021' | wc -l
19527
# total commits to the main codebase (server folder) since fork
➜  elasticsearch git:(master) git log --oneline --all --since='Apr 22 2021' -- server/ | wc -l
6130
# total commits to main modules (various surrounding functionality not under x-pack) since fork
# https://github.com/elastic/elasticsearch/tree/main/modules
➜  elasticsearch git:(master) git log --oneline --all --since='Apr 22 2021' -- modules/ | wc -l
1437
# just as means of comparison, the amount of work made on x-pack features is not negligible
➜  elasticsearch git:(master) git log --oneline --all --since='Apr 22 2021' -- x-pack/ | wc -l
7294

OpenSearch的核心代码提交减少了超过3倍,重要模块的工作量减少了14倍,其中包括脚本语言、重新索引功能、摄入管道处理器等:

➜  OpenSearch git:(main) git log --oneline --all --since='Apr 22 2021' | wc -l           
3727
➜  OpenSearch git:(main) git log --oneline --all --since='Apr 22 2021' -- server/ | wc -l
1966
# total commits to main modules (surrounding functionality not under x-pack) since fork
# https://github.com/opensearch-project/OpenSearch/tree/main/modules
➜  OpenSearch git:(main) git log --oneline --all --since='Apr 22 2021' -- modules/ | wc -l
470

因此,与Elasticsearch发布的版本(主要和次要)相比,OpenSearch发布的版本较少。

虽然提交的数量并不是代码质量或软件性能的直接证据,但很明显,Elasticsearch项目在核心上看到了更多的工作,这反过来肯定会转化为更好的性能,更多的功能,跟上最新版本的依赖项和Lucene功能等等-特别是当差异达到这种程度时。

功能比较

搜索、分析和仪表板的所有基本功能在这两种技术之间完全相同。毕竟,OpenSearch是从Elasticsearch的一个非常成熟的版本派生出来的。对于标准用例,从功能的角度来看,选择哪个搜索引擎并不重要。

项目之间的功能差异将是Elastic的X-Pack(免费或付费)下的任何内容,以及分叉后添加的所有功能。

对于重要的功能,去一点点以上只是基本的-那些最终存在或将存在于两者。作为主要的例子,我们可以列出以下内容:

  • 数据流API由两者实现(尽管Elasticsearch刚刚发布了OpenSearch中没有的时间序列数据流)
  • 索引状态管理在OpenSearch中成为索引状态管理
  • 两者都有一些警报支持(尽管我们实际上建议使用ElastAlert2,而不是任何内置的警报解决方案)。
  • 两者都支持跨集群复制,在Elasticsearch中,这是一个高级层功能(不是免费的)。

在写这篇文章的时候,一些利基核心功能仍然是Elasticsearch独有的,比如geoshape和geohex网格聚合。

一些OpenSearch功能仅在托管服务Amazon OpenSearch Service上可用,另一方面,与Elastic Cloud不同,Elastic Cloud始终保持最新的Elasticsearch版本,Amazon的托管OpenSearch产品通常落后2-3个版本。

大多数主要差异存在于可用于各种用例的垂直解决方案堆栈(例如APM,SIEM等)。以下是Elasticsearch和OpenSearch之间的主要区别。

安全

Elasticsearch和OpenSearch中的安全功能是一个相当广泛的类别,涉及几个功能和问题。身份验证(允许用户进入)、授权和RBAC(基于角色的访问控制)、用户模拟、审计日志、静态和传输中的加密以及各种多租户问题。

Elasticsearch的所有内置安全功能都是X-Pack Basic许可证的一部分,并且仅限于基于Elasticsearch的用户目录。从7.0版开始,所有用户都可以免费使用。要使用LDAP、OpenID、SAML和更多付费许可进行身份验证,需要使用这些许可。这同样适用于其他安全功能,如IP过滤,文档和字段级安全等。

OpenSearch提供相同的安全功能和控制,但完全免费。OpenSearch的安全模块完全在开放环境下开发,具有所有必要的功能:Active Directory和LDAP、SAML、OpenID、访问控制功能(包括屏蔽和字段级安全性)、审计日志、加密支持等。

随着安全性的发展,Elasticsearch和OpenSearch完全处于同一水平,OpenSearch通过将所有这些完全免费作为开源内置模块提供而具有优势。

可搜索快照

创建“离线”搜索体验的能力,从而显著减少了使用较旧、访问频率较低的数据运行Elasticsearch集群所需的硬件数量,这对许多用例来说是一个真正的游戏规则改变者。

Elasticsearch已经实现了这个功能,并且已经广泛使用了一段时间;而OpenSearch最近刚刚发布了它,它仍然被标记为实验性的。然而,非常重要的是- Elasticsearch需要在高层(企业)上使用此功能的付费许可证,而在OpenSearch中,可搜索快照是一个完全免费的功能。

此功能由托管服务提供,在Elastic Cloud中称为“可搜索快照”或“冻结层搜索”,在Amazon OpenSearch Service中称为“Ultrawarm”。

机器学习

我们的建议是,不要仅仅因为Elasticsearch或OpenSearch不是专门为它构建的,就在其上运行机器学习和人工智能工作负载。当然,有时候它很方便,但它不是没有价格标签的。

Elasticsearch和OpenSearch应该被认为是服务层引擎。你应该准备好数据结构,这样无论是否涉及ML,都可以轻松地从它们中提供数据。例如,您可以使用向量字段(密集或稀疏向量)并使用kNN / ANN算法通过向量搜索查找类似文档。

另一种方法是使用重新评分方法,如LTR插件所做的,以提高评分能力。

Elasticsearch和OpenSearch都为机器学习工作负载和用例提供了内置的解决方案(或“应用程序”),在某些情况下可能会派上用场(例如Elastic Stack中的内置SIEM),但在我们看来-不是一般的,广泛的使用。

数据摄取

当分叉发生时,Elasticsearch已经在作为Elastic Stack的一部分发布的所有外围软件工具中强制执行了版本检查。Logstash、Beats和JavaScript、Java等客户端库都在检查Elasticsearch集群,以确认它确实是Elasticsearch而不是OpenSearch。这在项目的这些方面产生了显著的分歧-您不能在OpenSearch中使用现代的Logstash或Beats;因此,您需要找到替代方案。

Data Prepper技术是OpenSearch项目的一部分,旨在满足这一需求。

或者,有专门的连接器准备各种数据流技术,如Kafka连接Kafka,Flink接收器用于各种来源,等等。

客户端库

两者之间的一个显著差异是易于使用各种编码语言和平台,以及客户端库的成熟度。

Elasticsearch拥有几乎所有软件开发平台的客户端库- Ruby,JavaScript,.NET,Java,Python等等。虽然它是一个HTTP REST API,但有很多不同的API,有很多细节,一个好的客户端库能够提供良好的语法糖,并简化编写和维护与之交互的代码的过程。

自从分叉以来,大多数客户端库在尝试将它们连接到OpenSearch集群时都会抛出错误;随着时间的推移,这些技术自然会出现分歧,因此即使是核心和当前共享的API也会在两者之间发展和变化。因此OpenSearch需要开发和维护自己的客户端库。

不幸的是,这是OpenSearch的一个大弱点。我们尝试使用的各种客户端库都是最小的,缺乏,甚至有bug和文档漏洞。它们并不是完全不可用,但它们通常接近于不可用。有时直接使用简单的HTTP客户端库比使用OpenSearch的客户端库更容易。

许可和限制

当然,我们不能在没有讨论房间里的大象的情况下比较两者,这就是许可模式。Elasticsearch以前是在Apache许可证下发布的,这是一个非常宽松的许可证。这也是OpenSearch当前的许可证-但Elasticsearch现在是在一个不同的,不太宽松的许可证下发布的,许多人认为这不是开源许可证。

我和团队都不是律师--我们更喜欢保持高度的技术性,这是我们能够提供的真实的价值。但更多的时候,我们会被问到做X是合法的还是违反了Elastic的许可证。

要点是新许可证禁止将Elasticsearch API作为托管服务提供。如果你只是使用Elasticsearch作为你的应用程序的后端-你很好去。但是有很多灰色地带,比如将Elasticsearch嵌入作为一个整体销售的更大解决方案的一部分,暴露一些可以被视为Elasticsearch API的API(例如通过API进行搜索)等等。我们很多客户都希望零风险,特别是如果他们不需要Elasticsearch的任何特殊功能-他们选择使用OpenSearch并使用其基本功能,然后一些。

支持和文档

OpenSearch是一个开源项目,这意味着没有官方支持。OpenSearch的托管服务,如Amazon OpenSearch Service、Aiven等,将负责为您运行硬件和软件,但不负责您如何使用它。

Elasticsearch背后的公司Elastic Co确实通过其标准订阅许可证或通过Elastic Cloud上的托管产品提供支持。但同样,这种支持将是有限的,并不总是提供最好的定制建议,如何使用该技术,以最好地满足您的需求。

当文档不够时,当您需要一个真正的专家作为您值得信赖的顾问时,我们已经确立了我们作为Elasticsearch和OpenSearch支持的世界领导者的名字。除了咨询和迁移服务,我们还提供24/7生产支持,以帮助处理紧急事务,并始终保持集群的健康运行。

还可以查看Pulse-我们的自动化顾问解决方案,用于主动监控和支持。

结论

简单地总结一下OpenSearch和Elasticsearch的比较--只要你不直接向客户提供Elasticsearch,或者不属于这样做的法律的灰色区域,你就可以安全地使用Elasticsearch和OpenSearch。

对于所有基本和主流的用例,Elasticsearch和OpenSearch之间没有任何区别。这些用例包括文本搜索、日志分析、仪表板等,这两种技术的用途完全相同。

由于广泛的客户端库支持,Elasticsearch很可能更容易从任何地方集成,并且由于非常活跃的开发团队,Elasticsearch也将更快地赶上bug和问题。

另一方面,OpenSearch很可能操作起来更便宜,如果你正在寻找一些超越基本功能的东西,比如一个成熟的SIEM,那么肯定是这样。这些解决方案的Elastic Stack实现很可能会更加成熟,但它们也会付出巨大的代价。

对于自我管理-这些可能是你的决定因素。如果你正在寻找一个托管的解决方案,有更多的选择有OpenSearch,显而易见的原因。

责任编辑:武晓燕 来源: 开源技术小栈
相关推荐

2014-03-06 15:07:41

青橙小米

2022-07-20 08:16:54

Lombokjava工具

2020-01-18 14:55:03

架构运维技术

2010-05-28 11:21:17

2020-03-06 09:21:28

PWA原生应用Web

2018-06-12 10:09:41

编程语言PythonJava

2017-06-08 15:38:41

2020-02-02 15:42:22

PythonC++编程语言

2022-08-24 08:00:00

Node.isJavaScriptDeno

2018-08-15 08:33:33

编程Go语言开发

2017-01-11 14:38:39

编程语言Java

2023-08-09 18:08:35

ChatGPTStackOverflow

2017-11-13 15:38:03

VMwareOpenStack混合云

2018-10-12 13:54:26

2019-01-04 09:59:14

KafkaRabbitMQMQ

2024-07-30 09:12:15

2010-07-27 14:36:31

Flex Array

2013-02-19 13:13:33

SurfaceiPad

2010-05-21 16:36:09

GoogleCode

2013-03-19 10:27:43

服务器选型x86小型机
点赞
收藏

51CTO技术栈公众号