Elasticsearch

Elasticsearch是一個流行的搜索引擎，基于Apache Lucene項目（也是Apache Solr的父項目），自2010年以來已被許多人用于搜索和日志分析。它的設(shè)計具有高度可擴展性，可用于廣泛的應(yīng)用程序，從簡單的搜索功能到復(fù)雜的數(shù)據(jù)分析。

Elasticsearch和Kibana作為Elastic Stack的一部分，都有一套強大的功能，包括支持全文搜索、企業(yè)搜索、真實的時間分析和地理空間查詢。它曾經(jīng)在Apache許可證下完全開源，直到2021年初競爭對手亞馬遜開始創(chuàng)建自己的項目。Elasticsearch通常部署在自我管理或Elastic Cloud上。

什么是OpenSearch？

OpenSearch搜索引擎是亞馬遜自2021年1月以來維護的Elasticsearch的一個分支。在fork事件之前，它基本上是相同的代碼庫，這也是項目開始略有分歧的時候。OpenSearch的一個關(guān)鍵特征是它對透明度和社區(qū)驅(qū)動開發(fā)的關(guān)注。

與Elasticsearch不同，OpenSearch由社區(qū)驅(qū)動的基金會管理。這意味著任何人都可以為OpenSearch的發(fā)展做出貢獻。雖然這兩個軟件產(chǎn)品的代碼庫都是開放的，任何想要審查它的人都可以檢查，但貢獻代碼和影響OpenSearch的方向比Elasticsearch更容易。它通常用作Amazon OpenSearch Service（以前稱為Amazon Elasticsearch Service）的一部分。

在比較這兩者時，我們將回顧Codebase作為牽引力和開發(fā)工作的信號，以及特性-因此您可以選擇哪一個更適合您的需求。

代碼庫和發(fā)布

OpenSearch項目在7.10.2版本是最新版本時派生了Elasticsearch代碼庫，然后在OpenSearch代碼庫上進行了大量工作，以重命名項目并清理所有非Apache許可的代碼（即X-Pack功能）。為了正確地比較兩者所做的工作，我們統(tǒng)計了自2021年4月22日以來在主/主分支上進行的提交，這標志著OpenSearch在幾個月前分叉后的第一個候選版本。

Elasticsearch倉庫有近20 k次提交，其中6 k次提交到核心Elasticsearch（“服務(wù)器”文件夾），還有一些提交到衛(wèi)星模塊：

# 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發(fā)布的版本（主要和次要）相比，OpenSearch發(fā)布的版本較少。

雖然提交的數(shù)量并不是代碼質(zhì)量或軟件性能的直接證據(jù)，但很明顯，Elasticsearch項目在核心上看到了更多的工作，這反過來肯定會轉(zhuǎn)化為更好的性能，更多的功能，跟上最新版本的依賴項和Lucene功能等等-特別是當差異達到這種程度時。

功能比較

搜索、分析和儀表板的所有基本功能在這兩種技術(shù)之間完全相同。畢竟，OpenSearch是從Elasticsearch的一個非常成熟的版本派生出來的。對于標準用例，從功能的角度來看，選擇哪個搜索引擎并不重要。

項目之間的功能差異將是Elastic的X-Pack（免費或付費）下的任何內(nèi)容，以及分叉后添加的所有功能。

對于重要的功能，去一點點以上只是基本的-那些最終存在或?qū)⒋嬖谟趦烧?。作為主要的例子，我們可以列出以下?nèi)容：

• 數(shù)據(jù)流API由兩者實現(xiàn)（盡管Elasticsearch剛剛發(fā)布了OpenSearch中沒有的時間序列數(shù)據(jù)流）
• 索引狀態(tài)管理在OpenSearch中成為索引狀態(tài)管理
• 兩者都有一些警報支持（盡管我們實際上建議使用ElastAlert2，而不是任何內(nèi)置的警報解決方案）。
• 兩者都支持跨集群復(fù)制，在Elasticsearch中，這是一個高級層功能（不是免費的）。

在寫這篇文章的時候，一些利基核心功能仍然是Elasticsearch獨有的，比如geoshape和geohex網(wǎng)格聚合。

一些OpenSearch功能僅在托管服務(wù)Amazon OpenSearch Service上可用，另一方面，與Elastic Cloud不同，Elastic Cloud始終保持最新的Elasticsearch版本，Amazon的托管OpenSearch產(chǎn)品通常落后2-3個版本。

大多數(shù)主要差異存在于可用于各種用例的垂直解決方案堆棧（例如APM，SIEM等）。以下是Elasticsearch和OpenSearch之間的主要區(qū)別。

安全

Elasticsearch和OpenSearch中的安全功能是一個相當廣泛的類別，涉及幾個功能和問題。身份驗證（允許用戶進入）、授權(quán)和RBAC（基于角色的訪問控制）、用戶模擬、審計日志、靜態(tài)和傳輸中的加密以及各種多租戶問題。

Elasticsearch的所有內(nèi)置安全功能都是X-Pack Basic許可證的一部分，并且僅限于基于Elasticsearch的用戶目錄。從7.0版開始，所有用戶都可以免費使用。要使用LDAP、OpenID、SAML和更多付費許可進行身份驗證，需要使用這些許可。這同樣適用于其他安全功能，如IP過濾，文檔和字段級安全等。

OpenSearch提供相同的安全功能和控制，但完全免費。OpenSearch的安全模塊完全在開放環(huán)境下開發(fā)，具有所有必要的功能：Active Directory和LDAP、SAML、OpenID、訪問控制功能（包括屏蔽和字段級安全性）、審計日志、加密支持等。

隨著安全性的發(fā)展，Elasticsearch和OpenSearch完全處于同一水平，OpenSearch通過將所有這些完全免費作為開源內(nèi)置模塊提供而具有優(yōu)勢。

可搜索快照

創(chuàng)建“離線”搜索體驗的能力，從而顯著減少了使用較舊、訪問頻率較低的數(shù)據(jù)運行Elasticsearch集群所需的硬件數(shù)量，這對許多用例來說是一個真正的游戲規(guī)則改變者。

Elasticsearch已經(jīng)實現(xiàn)了這個功能，并且已經(jīng)廣泛使用了一段時間;而OpenSearch最近剛剛發(fā)布了它，它仍然被標記為實驗性的。然而，非常重要的是- Elasticsearch需要在高層（企業(yè)）上使用此功能的付費許可證，而在OpenSearch中，可搜索快照是一個完全免費的功能。

此功能由托管服務(wù)提供，在Elastic Cloud中稱為“可搜索快照”或“凍結(jié)層搜索”，在Amazon OpenSearch Service中稱為“Ultrawarm”。

機器學(xué)習(xí)

我們的建議是，不要僅僅因為Elasticsearch或OpenSearch不是專門為它構(gòu)建的，就在其上運行機器學(xué)習(xí)和人工智能工作負載。當然，有時候它很方便，但它不是沒有價格標簽的。

Elasticsearch和OpenSearch應(yīng)該被認為是服務(wù)層引擎。你應(yīng)該準備好數(shù)據(jù)結(jié)構(gòu)，這樣無論是否涉及ML，都可以輕松地從它們中提供數(shù)據(jù)。例如，您可以使用向量字段（密集或稀疏向量）并使用kNN / ANN算法通過向量搜索查找類似文檔。

另一種方法是使用重新評分方法，如LTR插件所做的，以提高評分能力。

Elasticsearch和OpenSearch都為機器學(xué)習(xí)工作負載和用例提供了內(nèi)置的解決方案（或“應(yīng)用程序”），在某些情況下可能會派上用場（例如Elastic Stack中的內(nèi)置SIEM），但在我們看來-不是一般的，廣泛的使用。

數(shù)據(jù)攝取

當分叉發(fā)生時，Elasticsearch已經(jīng)在作為Elastic Stack的一部分發(fā)布的所有外圍軟件工具中強制執(zhí)行了版本檢查。Logstash、Beats和JavaScript、Java等客戶端庫都在檢查Elasticsearch集群，以確認它確實是Elasticsearch而不是OpenSearch。這在項目的這些方面產(chǎn)生了顯著的分歧-您不能在OpenSearch中使用現(xiàn)代的Logstash或Beats;因此，您需要找到替代方案。

Data Prepper技術(shù)是OpenSearch項目的一部分，旨在滿足這一需求。

或者，有專門的連接器準備各種數(shù)據(jù)流技術(shù)，如Kafka連接Kafka，F(xiàn)link接收器用于各種來源，等等。

客戶端庫

兩者之間的一個顯著差異是易于使用各種編碼語言和平臺，以及客戶端庫的成熟度。

Elasticsearch擁有幾乎所有軟件開發(fā)平臺的客戶端庫- Ruby，JavaScript，.NET，Java，Python等等。雖然它是一個HTTP REST API，但有很多不同的API，有很多細節(jié)，一個好的客戶端庫能夠提供良好的語法糖，并簡化編寫和維護與之交互的代碼的過程。

自從分叉以來，大多數(shù)客戶端庫在嘗試將它們連接到OpenSearch集群時都會拋出錯誤;隨著時間的推移，這些技術(shù)自然會出現(xiàn)分歧，因此即使是核心和當前共享的API也會在兩者之間發(fā)展和變化。因此OpenSearch需要開發(fā)和維護自己的客戶端庫。

不幸的是，這是OpenSearch的一個大弱點。我們嘗試使用的各種客戶端庫都是最小的，缺乏，甚至有bug和文檔漏洞。它們并不是完全不可用，但它們通常接近于不可用。有時直接使用簡單的HTTP客戶端庫比使用OpenSearch的客戶端庫更容易。

許可和限制

當然，我們不能在沒有討論房間里的大象的情況下比較兩者，這就是許可模式。Elasticsearch以前是在Apache許可證下發(fā)布的，這是一個非常寬松的許可證。這也是OpenSearch當前的許可證-但Elasticsearch現(xiàn)在是在一個不同的，不太寬松的許可證下發(fā)布的，許多人認為這不是開源許可證。

我和團隊都不是律師--我們更喜歡保持高度的技術(shù)性，這是我們能夠提供的真實的價值。但更多的時候，我們會被問到做X是合法的還是違反了Elastic的許可證。

要點是新許可證禁止將Elasticsearch API作為托管服務(wù)提供。如果你只是使用Elasticsearch作為你的應(yīng)用程序的后端-你很好去。但是有很多灰色地帶，比如將Elasticsearch嵌入作為一個整體銷售的更大解決方案的一部分，暴露一些可以被視為Elasticsearch API的API（例如通過API進行搜索）等等。我們很多客戶都希望零風險，特別是如果他們不需要Elasticsearch的任何特殊功能-他們選擇使用OpenSearch并使用其基本功能，然后一些。

支持和文檔

OpenSearch是一個開源項目，這意味著沒有官方支持。OpenSearch的托管服務(wù)，如Amazon OpenSearch Service、Aiven等，將負責為您運行硬件和軟件，但不負責您如何使用它。

Elasticsearch背后的公司Elastic Co確實通過其標準訂閱許可證或通過Elastic Cloud上的托管產(chǎn)品提供支持。但同樣，這種支持將是有限的，并不總是提供最好的定制建議，如何使用該技術(shù)，以最好地滿足您的需求。

當文檔不夠時，當您需要一個真正的專家作為您值得信賴的顧問時，我們已經(jīng)確立了我們作為Elasticsearch和OpenSearch支持的世界領(lǐng)導(dǎo)者的名字。除了咨詢和遷移服務(wù)，我們還提供24/7生產(chǎn)支持，以幫助處理緊急事務(wù)，并始終保持集群的健康運行。

還可以查看Pulse-我們的自動化顧問解決方案，用于主動監(jiān)控和支持。

結(jié)論

簡單地總結(jié)一下OpenSearch和Elasticsearch的比較--只要你不直接向客戶提供Elasticsearch，或者不屬于這樣做的法律的灰色區(qū)域，你就可以安全地使用Elasticsearch和OpenSearch。

對于所有基本和主流的用例，Elasticsearch和OpenSearch之間沒有任何區(qū)別。這些用例包括文本搜索、日志分析、儀表板等，這兩種技術(shù)的用途完全相同。

由于廣泛的客戶端庫支持，Elasticsearch很可能更容易從任何地方集成，并且由于非?；钴S的開發(fā)團隊，Elasticsearch也將更快地趕上bug和問題。

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

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