文章/答案/技术大牛

发布

社区首页 >专栏 >OpenSearch vs Elasticsearch

OpenSearch vs Elasticsearch

Tinywan

发布于 2024-07-31 04:21:57

35000

代码可运行

文章被收录于专栏：开源技术小栈开源技术小栈

运行总次数：0

代码可运行

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并使用其基本功能，然后一些。