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

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

一、什么是分片？

假如我們的集群的架構(gòu)如下圖：

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

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

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

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

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

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

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

分片是 Elasticsearch 集群分發(fā)數(shù)據(jù)的單元。 Elasticsearch 在重新平衡數(shù)據(jù)時可以移動分片的速度，例如發(fā)生故障后，將取決于分片的大小和數(shù)量以及網(wǎng)絡(luò)和磁盤性能。

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

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

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

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

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

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

每個分片本質(zhì)上就是一個Lucene索引, 因此會消耗相應(yīng)的文件句柄, 內(nèi)存和CPU資源

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

ES 使用詞頻統(tǒng)計來計算相關(guān)性. 當然這些統(tǒng)計也會分配到各個分片上。如果在大量分片上只維護了很少的數(shù)據(jù), 則將導(dǎo)致最終的文檔相關(guān)性較差。

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

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

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

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

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

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

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

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

四、如何管理分片大小

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

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

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

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

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

五、總結(jié)

關(guān)于如何在索引和分片之間最佳地分布數(shù)據(jù)，這將取決于所使用的場景的細節(jié)，有時很難確定如何最好地應(yīng)用可用的建議。

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

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論