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**，顯而易見的原因。