OpenSearch vs Elasticsearch · Spring Boot 技术栈

## 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](https://www.elastic.co/guide/en/elasticsearch/reference/current/data-stream-apis.html)由两者实现（尽管Elasticsearch刚刚发布了OpenSearch中没有的[时间序列数据流](https://www.elastic.co/guide/en/elasticsearch//reference/master/tsds.html)） * 索引状态管理在OpenSearch中成为索引状态管理 * 两者都有一些警报支持（尽管我们实际上建议使用[ElastAlert2](https://elastalert2.readthedocs.io/en/latest/)，而不是任何[内置的警报解决方案](https://bigdataboutique.com/blog/alerting-with-elasticsearch-and-the-elastic-stack-video-jpaoum)）。 * 两者都支持跨集群复制，在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的安全模块](https://github.com/opensearch-project/security#readme)完全在开放环境下开发，具有所有必要的功能：[Active Directory和LDAP](https://opensearch.org/docs/latest/security-plugin/configuration/ldap/)、SAML、OpenID、访问控制功能（包括屏蔽和字段级安全性）、审计日志、加密支持等。随着安全性的发展，Elasticsearch和OpenSearch完全处于同一水平，OpenSearch通过将所有这些完全免费作为开源内置模块提供而具有优势。 ## 可搜索快照创建“离线”搜索体验的能力，从而显著减少了使用较旧、访问频率较低的数据运行Elasticsearch集群所需的硬件数量，这对许多用例来说是一个真正的游戏规则改变者。 Elasticsearch已经实现了这个功能，并且已经广泛使用了一段时间;而OpenSearch最近刚刚发布了它，它仍然被标记为实验性的。然而，非常重要的是- Elasticsearch需要在高层（企业）上使用此功能的**付费许可证**，而在[OpenSearch中，可搜索快照](https://opensearch.org/docs/latest/tuning-your-cluster/availability-and-recovery/snapshots/searchable_snapshot)是**一个完全免费的功能**。此功能由托管服务提供，在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](https://github.com/opensearch-project/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](https://bigdataboutique.com/partners/amazon-opensearch-service)、Aiven等，将负责为您运行硬件和软件，但不负责您如何使用它。 Elasticsearch背后的公司Elastic Co确实通过其标准订阅许可证或通过Elastic Cloud上的托管产品提供支持。但同样，这种支持将是**有限的，并不总是提供最好的定制建议，如何使用该技术，以最好地满足您的需求**。当文档不够时，当您需要一个真正的专家作为您值得信赖的顾问时，我们已经确立了我们作为Elasticsearch和OpenSearch支持的世界领导者的名字。除了咨询和迁移服务，我们还提供24/7生产支持，以帮助处理紧急事务，并始终保持集群的健康运行。还可以查看[Pulse](https://bigdataboutique.com/solutions/pulse)\-我们的自动化顾问解决方案，用于主动监控和支持。 ## 结论简单地总结一下OpenSearch和Elasticsearch的比较--只要你不直接向客户提供Elasticsearch，或者不属于这样做的法律的灰色区域，你就可以安全地使用Elasticsearch和OpenSearch。对于所有基本和主流的用例，Elasticsearch和OpenSearch之间没有任何区别。这些用例包括文本搜索、日志分析、仪表板等，这两种技术的用途完全相同。由于广泛的客户端库支持，Elasticsearch很可能**更容易从任何地方集成**，并且由于**非常活跃的开发团队，Elasticsearch**也将更快地赶上bug和问题。另一方面，OpenSearch很可能操作起来**更便宜**，如果你正在寻找一些超越基本功能的东西，比如一个成熟的SIEM，那么肯定是这样。这些解决方案的Elastic Stack实现很可能会更加成熟，但它们也会付出巨大的代价。对于自我管理-这些可能是你的决定因素。如果你正在寻找一个托管的解决方案，**有更多的选择有OpenSearch**，显而易见的原因。