這篇文章主要介紹“java的Elasticsearch從基本概念到生產(chǎn)使用分析”，在日常操作中，相信很多人在java的Elasticsearch從基本概念到生產(chǎn)使用分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”java的Elasticsearch從基本概念到生產(chǎn)使用分析”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

創(chuàng)新互聯(lián)是一家專業(yè)提供習水企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站設(shè)計制作、網(wǎng)站設(shè)計、H5技術(shù)、小程序制作等業(yè)務(wù)。10年已為習水眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進行中。

基礎(chǔ)概念

對于一個Elasticsearch(ES)的新手，首先需要學習一些基本概念。

Elasticsearch項目源于Java的優(yōu)秀的分布式搜索引擎Apache  Lucene，Luncene還派生了另一個非常優(yōu)秀的搜索項目Solor。不管是是Elasticsearch和Solor其底層保存數(shù)據(jù)和搜索引擎部分都是Lucene。ES在基于Lucene內(nèi)核上更加優(yōu)秀的一個分布式實時搜索引擎，尤其在分布式集群和橫向擴展方面做的非常好，可以很輕松地運行管理數(shù)千個Lucene實例。

在ES架構(gòu)中的最高級別單元是群集(Cluster)。集群是ES節(jié)點和索引的集合。

節(jié)點(Node)是ES的實例。它們可以是單個服務(wù)器，也可以僅僅為服務(wù)器上運行的ES進程。注意：服務(wù)器并等價于節(jié)點不相同。VM虛擬機或物理服務(wù)器都可以容納許多ES進程，每個ES進程都是一個節(jié)點。節(jié)點可以完全加入一個集群。有不同類型的節(jié)點。其中最有重要兩個節(jié)點是數(shù)據(jù)節(jié)點(Data  Node)和備選主節(jié)點(Master-Eligible  Node)。一個節(jié)點可以同時具備多種屬性。數(shù)據(jù)節(jié)點運行所有數(shù)據(jù)操作。即存儲，索引和搜索數(shù)據(jù)。備選主節(jié)點用來投票為運行集群和索引管理的主機。

索引(Index)是數(shù)據(jù)的高級抽象。索引本身不保存數(shù)據(jù)。它們只是對實際存儲數(shù)據(jù)的另一種抽象。對數(shù)據(jù)執(zhí)行的任何操作(例如插入，刪除，建立索引和搜索)都會對索引產(chǎn)生影響。索引可以完全屬于一個簇，并且由分片組成。

分片(Shard)是Apache  Lucene的實例。一個分片可以容納許多文檔。分片是實際數(shù)據(jù)存儲，索引和搜索的對象。一個分片恰好屬于一個節(jié)點和索引。分片分兩種類型：主(primary)分片和副本(replica)。兩者基本上是等同的，它們擁有相同的數(shù)據(jù)，并且并行搜索所有分片。在擁有相同數(shù)據(jù)的所有分片中，一個是主分片，是唯一可以接受索引請求的分片。如果主分片所在的節(jié)點死亡，則副本分片將自動接管成為主分片。然后，ES將創(chuàng)建一個新的副本分片并復(fù)制數(shù)據(jù)?？傮w上可以用一個簡單的圖示如下：

深入了解

如果想運行一個系統(tǒng)，首先需要了解該系統(tǒng)。在了解基礎(chǔ)概念后，我們來實際了解Elasticsearch的各個部分。

Quorum

理解Elasticsearch組織是一個民主機制很重要。節(jié)點通過投票決定誰是老大Master，即主節(jié)點。該主節(jié)點主運行很多集群管理進程，在集群中享有最終決定權(quán)。ES的  選舉是有條件的，既只有備選節(jié)點才能參與選舉成為主節(jié)點。符合Master資格的是其配置中設(shè)置為下面條件的所有節(jié)點：

node.master: true

在群集啟動時或主節(jié)點退出群集時，所有符合主節(jié)點條件的節(jié)點都會開始選舉新的主節(jié)點。因此，需要具有2n +  1個符合主機要求的節(jié)點。否則，可能會出現(xiàn)選舉55開的裂腦情況。

節(jié)點加入

當ES流程啟動時，它就獨立自由存在，他如何知道自己所處的集群呢?有不同的方法可以完成此操作。但常用一種叫做種子主機(Seed  Hosts)的方法來這個過程。

Elasticsearch節(jié)點會不斷地和他所見過的所有其他節(jié)點進行對話。因此，一個節(jié)點最初只需資詢幾個其他節(jié)點即可了解整個集群。整個過程不是一個恒定的過程：節(jié)點不屬于集群時，它們僅共享有關(guān)他們發(fā)現(xiàn)的其他節(jié)點的信息。一旦加入群集，節(jié)點便會停止該操作，并依靠當選群集主節(jié)點共享所發(fā)生的變化信息。這樣可以節(jié)省了大量不必要的網(wǎng)絡(luò)閑聊。在ES  7.x中，節(jié)點間只交流他們所見到到備選主機節(jié)點，發(fā)現(xiàn)過程會忽略備選主機節(jié)點。

以一個三節(jié)點集群的為例：

初始狀態(tài)：

節(jié)點A和C只是知道B。B是種子主機。種子主機要么以配置文件的形式提供給ES，要么直接放入elasticsearch.yml中。

節(jié)點A與B連接并交換信息：

一旦節(jié)點A連接到B，B現(xiàn)在就知道了A的存在。A沒有任何變化。

節(jié)點C連接并與B共享信息

現(xiàn)在C連線，C會和B通訊。B就會告訴C A的存在。C和B現(xiàn)在都知道群集中的所有節(jié)點。下一次A重新連接到B，它也會知道C的存在。

段合并

前面我們說過，分片存儲數(shù)據(jù)。數(shù)據(jù)將以..文件的形式存儲在文件系統(tǒng)中。在Lucene和Elasticsearch中，這些文件被稱為段(Segments)。一個分片會有一到數(shù)千個段。

段是物理上實際存在的文件，可以在ES安裝的data目錄中看到。所以端文件的操作是個開銷。如果要查看，必須要找到對應(yīng)的文件并打開。如果要打開許多文件，那么將會帶來很大的開銷。由于Lucene中的段是不可變的，只能寫入不可更改。放入ES中的每個文檔都將創(chuàng)建一個僅包含單個文檔的段。那么，如果集群中有十億個文檔則對應(yīng)會有十億個段文件么?

實際上不是這樣的。在Lucene后臺，會進行段合并。該操作不對段進行更改，但是可以兩個較小段的數(shù)據(jù)合并創(chuàng)建新的段，并將合并的兩個小段清理掉：

lucene會不斷段合并，并 保持段數(shù)量不會太大。

消息路由

在Elasticsearch中，可以對集群中的任何節(jié)點運行任何命令，并且保持結(jié)果將相同。然而，在最底層文檔將只存在于一個主分片及其副本中，而ES該文檔位于何處，也沒有映射說明特定文檔位于特定分片中。

如果進行搜索，請求入口點ES節(jié)點會將其廣播到索引中的所有分片，這些分片來查看該文檔的所有段。如果要插入，則ES節(jié)點會隨機選擇一個主分片并將文檔放在其中，然后將其寫入該主要分片及其所有副本。

生產(chǎn)實踐

最后部分來說說在生產(chǎn)中如何部署和管理Elasticsearc。

Elasticsearch實踐中最常見的一個問題是，估計需要的集群規(guī)模，包括節(jié)點數(shù)量，需要硬件資源等。

內(nèi)存

首先要考慮內(nèi)存使用，內(nèi)存大小將限制所有其他資源。

Java堆

ES是用Java開發(fā)的。Java要用堆，可以將其視為Java保留的內(nèi)存。關(guān)于堆，有所有重要的東西會使這個文檔的大小增加三倍。

關(guān)于盡量可能多的使用，但堆大小不要超過30G。

有一個這很多人都不知道的關(guān)于堆的秘密：堆中的每個對象都需要一個唯一的地址，即一個對象指針。該地址的長度是固定的，所以可以尋址的對象數(shù)量是有限的。簡而言之，在某一時刻，Java會需要使用壓縮的對象指針而不是未壓縮的對象指針。這樣每個內(nèi)存訪問都將涉及其他步驟，并且速度會慢得多。請不要超過此閾值(大約32G)。

根據(jù)社區(qū)對Elasticsearch的不同文件系統(tǒng)，堆大小，F(xiàn)S和BIOS的組合的基準測試，結(jié)果如下：

如上圖所示，從32G的堆大小開始，性能突然開始變差(50%訪問延時，越小越好)。

吞吐量結(jié)果(越大越好)也類似：

總之，請使用29G或30G的內(nèi)存，請使用XFS，并盡可能使用hardwareprefetch和llc-prefetch。

文件緩存

絕大大多數(shù)人會在Linux上運行Elasticsearch，Linux使用RAM作為文件系統(tǒng)緩存。常見的建議是將64G用于ES服務(wù)器，這樣一半的緩存，一半的堆。大型ES群集(如用于日志記錄)可以從擁有大容量的FS緩存中獲益。如果所有的索引都適合堆，則不需要那么多。

Elasticsearch  7.x會在其堆上需要一定數(shù)量的直接內(nèi)存，并且還有其他開銷，這就是為什么建議堆大小不超過物理內(nèi)存的50%的原因。這是一個上限，64GB主機上的32GB堆可能不能為文件系統(tǒng)緩存保留太多空間。文件系統(tǒng)緩存是Elasticsearch/Lucene性能的關(guān)鍵，并且較小的堆有時可以產(chǎn)生更好的性能(它們?yōu)槲募到y(tǒng)緩存留出更多空間，并且對于GC而言也更便宜)。

CPU

這取決于對群集執(zhí)行的操作。如果要進行大量索引編制，則與僅執(zhí)行日志記錄相比，需要更多，更快的CPU。對于日志記錄，一般來說8核CPU就綽綽有余，但是更具不同用途，要具體實踐而定。

磁盤

如果索引分配到合適的內(nèi)存，則磁盤僅在節(jié)點冷時才重要。而且實際可以存儲的數(shù)據(jù)量取決于索引布局。每個分片都是Lucene實例，它們都有內(nèi)存需求。這樣可以在堆中容納最大數(shù)量的分片。通常，可以將所有數(shù)據(jù)磁盤放入RAID0。應(yīng)該在Elasticsearch級別進行復(fù)制，因此丟失節(jié)點無關(guān)緊要。不要請將LVM和多個磁盤一起使用，因為LVM一次只能寫入一個磁盤，根本就不會給帶來多個磁盤的好處。

關(guān)于文件系統(tǒng)和RAID設(shè)置：

調(diào)度器：cfq和截止日期優(yōu)于noop。如果有nvme，Kyber可能會很好(未嚴格測試過)

QueueDepth：盡可能高

預(yù)讀：是的，請使用

Raid塊大?。簾o影響

FS塊大?。簾o影響

FS類型：XFS優(yōu)于ext4

索引布局

大程度上取決于的用例。從日志集群背景為例來說。

分片

簡而言之：

對于寫繁重的工作負載，主分片=節(jié)點數(shù)

于讀繁重的工作負載，主分片*復(fù)制=節(jié)點數(shù)

更多副本=更高的搜索性能

可以通過一個公式來計算寫入性能：

節(jié)點吞吐量*主分片數(shù)

原因很簡單：如果只有一個主分片，那么只能像一個節(jié)點可以寫入數(shù)據(jù)那樣快地寫入數(shù)據(jù)，因為一個分片只能位于一個節(jié)點上。如果確實想優(yōu)化寫入性能，則應(yīng)確保每個節(jié)點上只有一個分片(主節(jié)點或副本)，因為副本顯然獲得與主節(jié)點相同的寫入，并且寫入很大程度上取決于磁盤IO。

注意：如果有很多索引，則可能不正確，而瓶頸可能是其他原因。

如果要優(yōu)化搜索性能，可以通過以下公式給出搜索性能：

節(jié)點吞吐量*(主分片數(shù)+副本數(shù))

對于搜索，主碎片和副本分片基本上是等同的。因此，如果想提高搜索性能，只需增加副本數(shù)即可。

規(guī)模大小

關(guān)于索引大小有很懂資料。我們在此一個經(jīng)驗是：

30G堆=每個節(jié)點最多140個分片

使用多余140分片，可能會使Elasticsearch進程崩潰并出現(xiàn)內(nèi)存不足錯誤。因為每個分片都是Lucene實例，并且每個實例都需要一定數(shù)量的內(nèi)存。所以，每個節(jié)點可以有多少個分片。

如果有節(jié)點數(shù)量，分片數(shù)量和索引大小，則可以容納多少個索引：

分片數(shù)量=(140*節(jié)點數(shù))/(主分片數(shù)*副本率)

這樣就可以計算出，所需要的大小：

索引大小=(節(jié)點數(shù) * 硬盤大小)/索引數(shù)量

請注：較大的索引也相對較慢。對于日志記錄來說，一定程度是可以的，但是對于真正搜索繁重的應(yīng)用程序，應(yīng)該根據(jù)所擁有的內(nèi)存數(shù)量來增加大小。

段合并

請記住，每個段都是文件系統(tǒng)上的實際文件?；旧?，對于每個搜索查詢，都會轉(zhuǎn)到索引中的所有分片，再從那里到分片中的所有段。段文件太多會極大地增加群集的讀取IOPS，直至無法使用。因此，最好將段數(shù)保持在盡可能低的水平。

有一個force_merge  API，允許將段合并到一定數(shù)量，例如1。如果進行索引輪換，例如，因為使用Elasticsearch進行日志記錄，則在不使用群集時進行常規(guī)使用中的強制合并是一個好主意。

強制合并會占用大量資源，并且會大大降低群集的速度，如果有很多索引，則必須要強制合并。

集群布局

對于除最小設(shè)置以外的所有內(nèi)容，最好使用專用的符合主機資格的節(jié)點。保持具有2n +  1個備選節(jié)點以確保仲裁。但是對于數(shù)據(jù)節(jié)點，只希望能夠隨時添加一個新節(jié)點，而不必擔心。另外，也不希望數(shù)據(jù)節(jié)點上的高負載影響的主節(jié)點。

最后，主節(jié)點是種子節(jié)點的理想候選者。

記住，種子節(jié)點是在Elasticsearch中執(zhí)行節(jié)點發(fā)現(xiàn)的最簡單方法。由于的主節(jié)點很少會會更改，因此，它們是最佳選擇，他們已經(jīng)知道了集群中的所有其他節(jié)點。

主節(jié)點可能很小，一個核心甚至4G的內(nèi)存就可以滿足大多數(shù)群集的需求。與往常一樣，關(guān)注實際使用情況并進行相應(yīng)調(diào)整。

監(jiān)控

監(jiān)控是個好東西，對Elasticsearch也是如此。ES為提供了大量的指標，并且支持以JSON的形式為方便調(diào)用，在監(jiān)控工具中添加這些指標非常簡單。以下是一些有用的監(jiān)控指標包括：

段數(shù)，堆使用率，堆GC時間，搜索、索引、合并的平均用時，IOPS，磁盤利用率等

到此，關(guān)于“java的Elasticsearch從基本概念到生產(chǎn)使用分析”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
本文題目：java的Elasticsearch從基本概念到生產(chǎn)使用分析
URL鏈接：http://weahome.cn/article/gipgdi.html