欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

ElasticSearch合理分配索引分片原理

 更新時(shí)間:2020年04月15日 10:40:10   作者:cool小伙  
這篇文章主要介紹了ElasticSearch合理分配索引分片原理,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下

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

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

一、什么是分片?

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

集群(cluster): 由一個(gè)或多個(gè)節(jié)點(diǎn)組成, 并通過(guò)集群名稱與其他集群進(jìn)行區(qū)分

節(jié)點(diǎn)(node): 單個(gè) ElasticSearch 實(shí)例. 通常一個(gè)節(jié)點(diǎn)運(yùn)行在一個(gè)隔離的容器或虛擬機(jī)中

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

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

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

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

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

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

注1:避免使用非常大的分片,因?yàn)檫@會(huì)對(duì)群集從故障中恢復(fù)的能力產(chǎn)生負(fù)面影響。 對(duì)分片的大小沒(méi)有固定的限制,但是通常情況下很多場(chǎng)景限制在 50GB 的分片大小以內(nèi)。

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

注3:盡可能使用基于時(shí)間的索引來(lái)管理數(shù)據(jù)保留期。 根據(jù)保留期將數(shù)據(jù)分組到索引中。 基于時(shí)間的索引還可以輕松地隨時(shí)間改變主分片和副本的數(shù)量,因?yàn)榭梢愿南乱粋€(gè)要生成的索引。

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

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

分配的每個(gè)分片都是有額外的成本的:

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

每個(gè)搜索請(qǐng)求會(huì)調(diào)度到索引的每個(gè)分片中. 如果分片分散在不同的節(jié)點(diǎn)倒是問(wèn)題不太. 但當(dāng)分片開始競(jìng)爭(zhēng)相同的硬件資源時(shí), 性能便會(huì)逐步下降

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

注1:小的分片會(huì)造成小的分段,從而會(huì)增加開銷。我們的目的是將平均分片大小控制在幾 GB 到幾十 GB 之間。對(duì)于基于時(shí)間的數(shù)據(jù)的使用場(chǎng)景來(lái)說(shuō),通常將分片大小控制在 20GB 到 40GB 之間。

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

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

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

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

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

在Elasticsearch中,每個(gè)查詢?cè)诿總€(gè)分片的單個(gè)線程中執(zhí)行。 但是,可以并行處理多個(gè)分片,對(duì)同一分片也可以進(jìn)行多個(gè)查詢和聚合。

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

四、如何管理分片大小

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

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

Rollover and Shrink API 可以指定應(yīng)包含的文檔和索引的數(shù)量和/或應(yīng)該向其寫入最大期限的文檔。 一旦超出其中一個(gè)標(biāo)準(zhǔn),Elasticsearch 就可以觸發(fā)創(chuàng)建新索引,無(wú)需停機(jī)即可完成寫入。 可以切換到特定大小的新索引,而不是讓每個(gè)索引覆蓋特定的時(shí)間段,這使得可以更容易地為所有索引實(shí)現(xiàn)均勻的分片大小。如果需要更新數(shù)據(jù),在使用此API時(shí),事件的時(shí)間戳與其所處的索引之間不再存在明顯的鏈接,這可能會(huì)使更新效率大大降低,因?yàn)槊看胃露夹枰谒阉髦斑M(jìn)行。

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

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

五、總結(jié)

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

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

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

相關(guān)文章

  • spring整合JMS實(shí)現(xiàn)同步收發(fā)消息(基于ActiveMQ的實(shí)現(xiàn))

    spring整合JMS實(shí)現(xiàn)同步收發(fā)消息(基于ActiveMQ的實(shí)現(xiàn))

    本篇文章主要介紹了spring整合JMS實(shí)現(xiàn)同步收發(fā)消息(基于ActiveMQ的實(shí)現(xiàn)),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下
    2017-10-10
  • Spring計(jì)時(shí)器StopWatch的具體使用

    Spring計(jì)時(shí)器StopWatch的具體使用

    本文主要介紹了Spring計(jì)時(shí)器StopWatch的具體使用,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2023-06-06
  • MyBatis不同Mapper文件引用resultMap實(shí)例代碼

    MyBatis不同Mapper文件引用resultMap實(shí)例代碼

    這篇文章主要介紹了mybatis 不同Mapper文件引用resultMap的實(shí)例代碼,非常不錯(cuò)具有參考借鑒價(jià)值,需要的朋友可以參考下
    2017-07-07
  • SpringBoot整合Gson 整合Fastjson的實(shí)例詳解

    SpringBoot整合Gson 整合Fastjson的實(shí)例詳解

    這篇文章主要介紹了SpringBoot整合Gson 整合Fastjson的實(shí)例詳解,本文通過(guò)實(shí)例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下
    2020-11-11
  • 一文秒懂springboot druid 配置

    一文秒懂springboot druid 配置

    Druid是阿里巴巴開發(fā)的一個(gè)連接池,他提供了一個(gè)高效、功能強(qiáng)大、可擴(kuò)展性好的數(shù)據(jù)庫(kù)連接池,區(qū)別于hikari,今天通過(guò)本文給大家分享springboot druid 配置教程,需要的朋友參考下吧
    2021-08-08
  • SpringMVC靜態(tài)資源訪問(wèn)問(wèn)題如何解決

    SpringMVC靜態(tài)資源訪問(wèn)問(wèn)題如何解決

    這篇文章主要介紹了SpringMVC靜態(tài)資源訪問(wèn)問(wèn)題如何解決,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下
    2020-11-11
  • java對(duì)接支付寶支付接口開發(fā)詳細(xì)步驟

    java對(duì)接支付寶支付接口開發(fā)詳細(xì)步驟

    本文主要介紹了java對(duì)接支付寶支付接口開發(fā)詳細(xì)步驟,文中通過(guò)示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下
    2022-01-01
  • Spring?Boot使用Hibernate-Validator校驗(yàn)參數(shù)時(shí)的長(zhǎng)度校驗(yàn)方法詳解

    Spring?Boot使用Hibernate-Validator校驗(yàn)參數(shù)時(shí)的長(zhǎng)度校驗(yàn)方法詳解

    這篇文章主要給大家介紹了關(guān)于Spring?Boot使用Hibernate-Validator校驗(yàn)參數(shù)時(shí)的長(zhǎng)度校驗(yàn)方法的相關(guān)資料,在Spring Boot中可以使用Spring Boot Validation來(lái)對(duì)參數(shù)名稱進(jìn)行校驗(yàn),需要的朋友可以參考下
    2023-08-08
  • Java中String類的常用方法總結(jié)

    Java中String類的常用方法總結(jié)

    java.lang.String?類代表字符串。Java程序中所有的字符串文字(例如"abc"?)都可以被看作是實(shí)現(xiàn)此類的實(shí)例。本文主要為大家介紹了String類的常用方法,需要的可以參考一下
    2022-11-11
  • Struts2 的國(guó)際化實(shí)現(xiàn)方式示例

    Struts2 的國(guó)際化實(shí)現(xiàn)方式示例

    這篇文章主要介紹了Struts2 的國(guó)際化實(shí)現(xiàn)方式示例,小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧
    2017-10-10

最新評(píng)論