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很可能更容易從任何地方集成，并且由于非?；钴S的開發團隊，Elasticsearch也將更快地趕上bug和問題。

另一方面，OpenSearch很可能操作起來更便宜，如果你正在尋找一些超越基本功能的東西，比如一個成熟的SIEM，那么肯定是這樣。這些解決方案的Elastic Stack實現很可能會更加成熟，但它們也會付出巨大的代價。

對于自我管理-這些可能是你的決定因素。如果你正在尋找一個托管的解決方案，有更多的選擇有OpenSearch，顯而易見的原因。