OpenSearch Elasticsearch 谁更胜一筹 vs

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 -l19527# total commits to the main codebase (server folder) since fork➜elasticsearch git:(master) git log --oneline --all --since='Apr 22 2021' -- server/ | wc -l6130# total commits to main modules (various surrounding functionality not under x-pack) since fork#➜elasticsearch git:(master) git log --oneline --all --since='Apr 22 2021' -- modules/ | wc -l1437# 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 -l7294

OpenSearch的中心代码提交缩小了超越3倍，关键模块的上班量缩小了14倍，其中包含脚本言语、从新索引配置、摄入管道处置器等：

➜OpenSearch git:(main) git log --oneline --all --since='Apr 22 2021' | wc -l3727➜OpenSearch git:(main) git log --oneline --all --since='Apr 22 2021' -- server/ | wc -l1966# total commits to main modules (surrounding functionality not under x-pack) since fork#➜OpenSearch git:(main) git log --oneline --all --since='Apr 22 2021' -- modules/ | wc -l470

因此，与Elasticsearch颁布的版本（关键和无所谓）相比，OpenSearch颁布的版本较少。

虽然提交的数量并不是代码品质或软件性能的间接证据，但很清楚，Elasticsearch名目在中心上看到了更多的上班，这反上来必需会转化为更好的性能，更多的配置，跟上最新版本的依赖项和Lucene配置等等-特意是当差异到达这种水平时。

配置比拟

搜查、剖析和仪表板的一切基本配置在这两种技术之间齐全相反。毕竟，OpenSearch是从Elasticsearch的一个十分成熟的版本派生进去的。关于规范用例，从配置的角度来看，选用哪个搜查引擎并不关键。

名目之间的配置差异将是Elastic的X-Pack（收费或付费）下的任何内容，以及分叉后增加的一切配置。

关于关键的配置，去一点点以上只是基本的-那些最终存在或将存在于两者。作为关键的例子，咱们可以列出以下内容：

在写这篇文章的时刻，一些利基中心配置依然是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名目标一局部，旨在满足这一需求。

客户端库

两者之间的一个清楚差异是易于经常使用各种编码言语敌对台，以及客户端库的成熟度。

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，显而易见的要素。