ElasticSearch怎么合理分配索引分片

小編這次要給大家分享的是ElasticSearch怎么合理分配索引分片，文章內容豐富，感興趣的小伙伴可以來了解一下，希望大家閱讀完這篇文章之后能夠有所收獲。

Elasticsearch 是一個非常通用的平臺，支持各種用戶實例，并為組織數據和復制策略提供了極大的靈活性。但是，這種靈活性有時會使我們很難在早期確定如何很好地將數據組織成索引和分片，尤其是不熟悉 Elastic Stack。雖然不一定會在首次啟動時引起問題，但隨著數據量的增長，它們可能會導致性能問題。群集擁有的數據越多，糾正問題也越困難，因為有時可能需要重新索引大量數據。

因此，當我們遇到性能問題時，往往可以追溯到索引方式以及集群中分片的數量。那么就會遇到問題，我們應該有多少分片以及我的分片應該有多大。

一、什么是分片？

假如我們的集群的架構如下圖：

集群(cluster): 由一個或多個節點組成, 并通過集群名稱與其他集群進行區分

節點(node): 單個 ElasticSearch 實例. 通常一個節點運行在一個隔離的容器或虛擬機中

索引(index): 在 ES 中, 索引是一組文檔的集合

分片(shard): 因為 ES 是個分布式的搜索引擎, 所以索引通常都會分解成不同部分, 而這些分布在不同節點的數據就是分片. ES自動管理和組織分片, 并在必要的時候對分片數據進行再平衡分配, 所以用戶基本上不用擔心分片的處理細節.

副本(replica): ES 默認為一個索引創建 5 個主分片, 并分別為其創建一個副本分片. 也就是說每個索引都由 5 個主分片成本, 而每個主分片都相應的有一個 copy。對于分布式搜索引擎來說, 分片及副本的分配將是高可用及快速搜索響應的設計核心.主分片與副本都能處理查詢請求，它們的唯一區別在于只有主分片才能處理索引請求.副本對搜索性能非常重要，同時用戶也可在任何時候添加或刪除副本。額外的副本能給帶來更大的容量, 更高的呑吐能力及更強的故障恢復能力。

如上圖，有集群兩個節點，并使用了默認的分片配置. ES自動把這5個主分片分配到2個節點上, 而它們分別對應的副本則在完全不同的節點上。其中 node1 有某個索引的分片1、2、3和副本分片4、5，node2 有該索引的分片4、5和副本分片1、2、3。

當數據被寫入分片時，它會定期發布到磁盤上的不可變的 Lucene 分段中用于查詢。隨著分段數量的增長，這些分段會定期合并為更大的分段。 此過程稱為合并。 由于所有分段都是不可變的，這意味著所使用的磁盤空間通常會在索引期間波動，因為需要在刪除替換分段之前創建新的合并分段。 合并可能非常耗費資源，特別是在磁盤I / O方面。

分片是 Elasticsearch 集群分發數據的單元。 Elasticsearch 在重新平衡數據時可以移動分片的速度，例如發生故障后，將取決于分片的大小和數量以及網絡和磁盤性能。

注1：避免使用非常大的分片，因為這會對群集從故障中恢復的能力產生負面影響。 對分片的大小沒有固定的限制，但是通常情況下很多場景限制在 50GB 的分片大小以內。

注2：當在ElasticSearch集群中配置好你的索引后, 你要明白在集群運行中你無法調整分片設置. 既便以后你發現需要調整分片數量, 你也只能新建創建并對數據進行重新索引(reindex)(雖然reindex會比較耗時, 但至少能保證你不會停機).
主分片的配置與硬盤分區很類似, 在對一塊空的硬盤空間進行分區時, 會要求用戶先進行數據備份, 然后配置新的分區, 最后把數據寫到新的分區上。

注3：盡可能使用基于時間的索引來管理數據保留期。 根據保留期將數據分組到索引中。 基于時間的索引還可以輕松地隨時間改變主分片和副本的數量，因為可以更改下一個要生成的索引。

二、索引和分片是否是空閑的

對于每個 Elasticsearch 索引，有關映射和狀態的信息都存儲在集群狀態中。它保存在內存中以便快速訪問。 因此，在群集中具有大量索引可能導致較大的群集狀態，尤其是在映射較大的情況下。 這可能會變得很慢，因為所有更新都需要通過單個線程完成，以便在更改集群中分布之前保證一致性。
每個分片都有需要保存在內存中的數據并使用堆空間。 這包括在分片級別保存信息的數據結構，但也包括在分段級別的數據結構，以便定義數據駐留在磁盤上的位置。 這些數據結構的大小不固定，并且會根據使用場景不同而有所不同。然而，分段相關開銷的一個重要特征是它與分段的大小不嚴格成比例。 這意味著與較小的分段相比，較大的分段每個數據量的開銷較小。 差異可能很大。為了能夠為每個節點存儲盡可能多的數據，管理堆的使用并盡可能減少開銷變得很重要。 節點擁有的堆空間越多，它可以處理的數據和分片就越多。
因此，索引和分片在集群視角下不是空閑的，因為每個索引和分片都存在一定程度的資源開銷。

分配的每個分片都是有額外的成本的:

每個分片本質上就是一個Lucene索引, 因此會消耗相應的文件句柄, 內存和CPU資源

每個搜索請求會調度到索引的每個分片中. 如果分片分散在不同的節點倒是問題不太. 但當分片開始競爭相同的硬件資源時, 性能便會逐步下降

ES 使用詞頻統計來計算相關性. 當然這些統計也會分配到各個分片上。如果在大量分片上只維護了很少的數據, 則將導致最終的文檔相關性較差。

注1：小的分片會造成小的分段，從而會增加開銷。我們的目的是將平均分片大小控制在幾 GB 到幾十 GB 之間。對于基于時間的數據的使用場景來說，通常將分片大小控制在 20GB 到 40GB 之間。

注2：由于每個分片的開銷取決于分段的數量和大小，因此通過 forcemerge 操作強制將較小的分段合并為較大的分段，這樣可以減少開銷并提高查詢性能。 理想情況下，一旦不再向索引寫入數據，就應該這樣做。 請注意，這是一項比較耗費性能和開銷的操作，因此應該在非高峰時段執行。

注3：我們可以在節點上保留的分片數量與可用的堆內存成正比，但 Elasticsearch 沒有強制的固定限制。 一個好的經驗法則是確保每個節點的分片數量低于每GB堆內存配置20到25個分片。 因此，具有30GB堆內存的節點應該具有最多600-750個分片，但是低于該限制可以使其保持更好。 這通常有助于集群保持健康。

注4：如果擔心數據的快速增長, 建議根據這條限制: ElasticSearch推薦的最大JVM堆空間 是 30~32G, 所以把分片最大容量限制為 30GB, 然后再對分片數量做合理估算。例如, 如果的數據能達到 200GB, 則最多分配7到8個分片。

注5：如果是基于日期的索引需求, 并且對索引數據的搜索場景非常少. 也許這些索引量將達到成百上千, 但每個索引的數據量只有1GB甚至更小. 對于這種類似場景, 建議是只需要為索引分配1個分片。如果使用ES的默認配置(5個分片), 并且使用 Logstash 按天生成索引, 那么 6 個月下來, 擁有的分片數將達到 890 個. 再多的話, 你的集群將難以工作--除非提供了更多(例如15個或更多)的節點。想一下, 大部分的 Logstash 用戶并不會頻繁的進行搜索, 甚至每分鐘都不會有一次查詢. 所以這種場景, 推薦更為經濟使用的設置. 在這種場景下, 搜索性能并不是第一要素, 所以并不需要很多副本。 維護單個副本用于數據冗余已經足夠。不過數據被不斷載入到內存的比例相應也會變高。如果索引只需要一個分片, 那么使用 Logstash 的配置可以在 3 節點的集群中維持運行 6 個月。當然你至少需要使用 4GB 的內存, 不過建議使用 8GB, 因為在多數據云平臺中使用 8GB 內存會有明顯的網速以及更少的資源共享.

三、分片大小如何影響性能

在Elasticsearch中，每個查詢在每個分片的單個線程中執行。 但是，可以并行處理多個分片，對同一分片也可以進行多個查詢和聚合。

這意味著，如果不涉及緩存，則最小查詢延遲將取決于數據、查詢類型以及分片的大小。 查詢大量小的分片將使每個分片的處理速度更快，但是需要按順序排隊和處理更多的任務，它不一定比查詢較少數量的較大分片更快。 如果存在多個并發查詢，則擁有大量小分片也會降低查詢吞吐量。
從查詢性能角度確定最大分片大小的最佳方法是使用實際數據和查詢進行基準測試。 始終以查詢和加載索引的節點在生產中需要處理的內容基準，因為優化單個查詢可能會產生誤導性結果。

四、如何管理分片大小

當使用基于時間的索引時，通常每個索引都與固定的時間段相關聯。 每天的索引非常常見，通常用于保存保留期短的或每日量大的數據。 這些允許以合適的粒度管理保留期，并且可以輕松調整日常基礎量。 具有較長保留期的數據，特別是如果每日的量不能保證使用每天的索引，通常使用每周或每月的索引以保證分片大小。 這減少了隨著時間的推移需要存儲在集群中的索引和分片的數量。

注：如果使用基于時間的索引，這個時間是某個固定的時間段，那么需要根據數據的保留期限和預期的數據量來調整每個索引所覆蓋的時間段，以達到目標分片的大小。也就是說，如果我們要確定最終分片的大小，則需要根據我們的數據保存的期限以及預估預期的數據量來調整我們索引需要按照天還是周還是月的時間來進行評估。
當數據量可以合理預測并且變化緩慢時，具有固定時間間隔的基于時間的索引很有效。 如果索引快速變化，則很難保持統一的目標分片大小。為了能夠更好地處理這種類型的場景，引入了 Rollover and Shrink API  這些為索引和分片的管理方式增加了很多靈活性，特別是對于基于時間的索引。

Rollover and Shrink API 可以指定應包含的文檔和索引的數量和/或應該向其寫入最大期限的文檔。 一旦超出其中一個標準，Elasticsearch 就可以觸發創建新索引，無需停機即可完成寫入。 可以切換到特定大小的新索引，而不是讓每個索引覆蓋特定的時間段，這使得可以更容易地為所有索引實現均勻的分片大小。如果需要更新數據，在使用此API時，事件的時間戳與其所處的索引之間不再存在明顯的鏈接，這可能會使更新效率大大降低，因為每次更新都需要在搜索之前進行。

注：如果我們有基于時間的不可變數據，其中數據量可能會隨時間發生顯著變化，就可以考慮使用 Rollover API，通過動態更改每個索引所涵蓋的時間段來實現最佳目標分片大小。 這提供了極大的靈活性，并且可以幫助避免在數據量不可預測時具有太大或太小的分片。

Shrink API 允許我們將現有索引縮小為具有較少主分片的新索引。 如果在索引期間需要跨節點均勻擴展分片，但這會導致分片太小，一旦索引不再被索引，此 API 可用于減少主分片的數量。 這將生成更大的分片，更適合長期存儲數據。
如果需要讓每個索引覆蓋特定的時間段，并且希望能夠在大量節點上擴展索引，請考慮使用 Shrink API 在索引不再編入索引時減少主分片的數量。 如果最初配置了太多分片，此 API 還可用于減少分片數量。

五、總結

關于如何在索引和分片之間最佳地分布數據，這將取決于所使用的場景的細節，有時很難確定如何最好地應用可用的建議。

數據分片也是要有相應資源消耗,并且需要持續投入。當索引擁有較多分片時, 為了組裝查詢結果, ES 必須單獨查詢每個分片(當然并行的方式)并對結果進行合并。所以高性能 IO 設備(SSDs)和多核處理器無疑對分片性能會有巨大幫助。盡管如此, 還是要多關心數據本身的大小,更新頻率以及未來的狀態。在分片分配上并沒有絕對的答案。

看完這篇關于ElasticSearch怎么合理分配索引分片的文章，如果覺得文章內容寫得不錯的話，可以把它分享出去給更多人看到。