java的Elasticsearch從基本概念到生產使用分析

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

基礎概念

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

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

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

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

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

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

深入了解

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

Quorum

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

node.master: true

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

節點加入

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

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

以一個三節點集群的為例：

初始狀態：

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

節點A與B連接并交換信息：

一旦節點A連接到B，B現在就知道了A的存在。A沒有任何變化。

節點C連接并與B共享信息

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

段合并

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

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

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

lucene會不斷段合并，并 保持段數量不會太大。

消息路由

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

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

生產實踐

最后部分來說說在生產中如何部署和管理Elasticsearc。

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

內存

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

Java堆

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

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

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

根據社區對Elasticsearch的不同文件系統，堆大小，FS和BIOS的組合的基準測試，結果如下：

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

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

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

文件緩存

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

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

CPU

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

磁盤

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

關于文件系統和RAID設置：

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

QueueDepth：盡可能高

預讀：是的，請使用

Raid塊大小：無影響

FS塊大小：無影響

FS類型：XFS優于ext4

索引布局

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

分片

簡而言之：

對于寫繁重的工作負載，主分片=節點數

于讀繁重的工作負載，主分片*復制=節點數

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

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

節點吞吐量*主分片數

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

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

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

節點吞吐量*(主分片數+副本數)

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

規模大小

關于索引大小有很懂資料。我們在此一個經驗是：

30G堆=每個節點最多140個分片

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

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

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

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

索引大小=(節點數 * 硬盤大小)/索引數量

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

段合并

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

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

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

集群布局

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

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

記住，種子節點是在Elasticsearch中執行節點發現的最簡單方法。由于的主節點很少會會更改，因此，它們是最佳選擇，他們已經知道了集群中的所有其他節點。

主節點可能很小，一個核心甚至4G的內存就可以滿足大多數群集的需求。與往常一樣，關注實際使用情況并進行相應調整。

監控

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

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

到此，關于“java的Elasticsearch從基本概念到生產使用分析”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！