java的Elasticsearch從基本概念到生產(chǎn)使用分析

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

基礎(chǔ)概念

對(duì)于一個(gè)Elasticsearch(ES)的新手，首先需要學(xué)習(xí)一些基本概念。

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

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

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

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

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

深入了解

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

Quorum

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

node.master: true

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

節(jié)點(diǎn)加入

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

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

以一個(gè)三節(jié)點(diǎn)集群的為例：

初始狀態(tài)：

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

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

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

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

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

段合并

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

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

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

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

消息路由

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

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

生產(chǎn)實(shí)踐

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

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

內(nèi)存

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

Java堆

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

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

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

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

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

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

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

文件緩存

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

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

CPU

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

磁盤

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

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

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

QueueDepth：盡可能高

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

Raid塊大?。簾o影響

FS塊大小：無影響

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

索引布局

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

分片

簡而言之：

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

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

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

可以通過一個(gè)公式來計(jì)算寫入性能：

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

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

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

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

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

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

規(guī)模大小

關(guān)于索引大小有很懂資料。我們?cè)诖艘粋€(gè)經(jīng)驗(yàn)是：

30G堆=每個(gè)節(jié)點(diǎn)最多140個(gè)分片

使用多余140分片，可能會(huì)使Elasticsearch進(jìn)程崩潰并出現(xiàn)內(nèi)存不足錯(cuò)誤。因?yàn)槊總€(gè)分片都是Lucene實(shí)例，并且每個(gè)實(shí)例都需要一定數(shù)量的內(nèi)存。所以，每個(gè)節(jié)點(diǎn)可以有多少個(gè)分片。

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

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

這樣就可以計(jì)算出，所需要的大?。?/p>

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

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

段合并

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

有一個(gè)force_merge  API，允許將段合并到一定數(shù)量，例如1。如果進(jìn)行索引輪換，例如，因?yàn)槭褂肊lasticsearch進(jìn)行日志記錄，則在不使用群集時(shí)進(jìn)行常規(guī)使用中的強(qiáng)制合并是一個(gè)好主意。

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

集群布局

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

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

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

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

監(jiān)控

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

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

到此，關(guān)于“java的Elasticsearch從基本概念到生產(chǎn)使用分析”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！