Elasticsearch 是一個(gè)強(qiáng)大的搜索和分析引擎，它通過將數(shù)據(jù)分散到多個(gè)節(jié)點(diǎn)的分片中來進(jìn)行分布式處理。

本文將探討分片大小和策略的概念，以優(yōu)化 Elasticsearch 的性能并防止過度分片或分片過大等問題。

先看個(gè)分片設(shè)置不合理的真實(shí)企業(yè)案例：

圖片

10TB 左右集群數(shù)據(jù)，只有兩個(gè)節(jié)點(diǎn)集群。單個(gè)最大索引 600GB，7.17.4 版本，200分片（全部）。

集群重啟無法啟動(dòng)，未咨詢之前是：最長時(shí)間8小時(shí)啟動(dòng)集群，過年期間，直接無法啟動(dòng)（已啟動(dòng)了20個(gè)小時(shí)+）。

——https://t.zsxq.com/SzcaQ

1、什么是分片？

在 Elasticsearch 中，每個(gè)索引都被劃分為多個(gè)分片，每個(gè)分片可以在多個(gè)節(jié)點(diǎn)上復(fù)制，以確保數(shù)據(jù)的可用性和冗余。

圖片

上圖是我本地單節(jié)點(diǎn)8.X 集群的 Head 插件截圖，綠色代表已分配分片，灰色代表未分配副本分片（單節(jié)點(diǎn)所以無法分配副本分片）。

然而，盡管分片允許通過分散數(shù)據(jù)來擴(kuò)展，不當(dāng)?shù)姆制赡軐?dǎo)致性能瓶頸或穩(wěn)定性問題。

2、為什么分片策略很重要？

有效的分片關(guān)鍵在于找到正確的平衡。

過多的分片會(huì)導(dǎo)致“過度分片”，在這種情況下，管理眾多分片的開銷超過了其帶來的好處，導(dǎo)致查詢處理效率降低，可能還會(huì)引發(fā)集群不穩(wěn)定。

3、創(chuàng)建分片策略

為了防止這些問題，至關(guān)重要的是要根據(jù)我們的特定需求開發(fā)一個(gè)分片策略，這包括：

• 了解集群的數(shù)據(jù)和查詢：分析咱們所在集群的數(shù)據(jù)性質(zhì)和將執(zhí)行的查詢。
• 基準(zhǔn)測(cè)試：在類似生產(chǎn)環(huán)境中測(cè)試不同的分片配置，看看更改如何影響性能。

舉例，如下基準(zhǔn)測(cè)試僅供參考。

在實(shí)際應(yīng)用中，應(yīng)根據(jù)具體需求和資源條件，選擇最適合的分片配置。

• 監(jiān)控：使用 Kibana 等工具監(jiān)控不同分片大小和配置對(duì)集群性能和穩(wěn)定性的影響。

不幸的是，沒有一種萬能的分片策略。一種在某個(gè)環(huán)境中有效的策略可能不適用于其他環(huán)境。一個(gè)好的分片策略必須考慮到我們的硬件基礎(chǔ)設(shè)施、業(yè)務(wù)場景和性能預(yù)期。

所以，大廠的意見、建議、經(jīng)驗(yàn)貼不見得適用我們下廠。這很關(guān)鍵！

4、分片大小的關(guān)鍵考慮因素

4.1 搜索線程

每個(gè)分片在單獨(dú)的線程中處理搜索查詢。如果存在太多分片，可能會(huì)超負(fù)荷節(jié)點(diǎn)的搜索線程池，從而減慢查詢處理速度。

GET /_cat/thread_pool?v&h=id,name,active,rejected,completed

圖片

上述命令會(huì)顯示集群中所有節(jié)點(diǎn)的所有線程池的信息，幫助我們識(shí)別哪些線程池可能過載。

4.2 分片開銷

每個(gè)分片無論大小都會(huì)增加 CPU 和內(nèi)存使用的開銷。少量大分片通常比許多小分片使用資源更高效。

注意：在 Elasticsearch 中，可以使用一些命令行操作來查看分片的資源使用情況，尤其是關(guān)于 CPU 和內(nèi)存的開銷。

雖然沒有直接的命令行工具可以顯示每個(gè)分片的 CPU 使用情況（因?yàn)?CPU 使用通常被監(jiān)控在節(jié)點(diǎn)級(jí)別而非分片級(jí)別），但咱們可以獲取關(guān)于每個(gè)分片內(nèi)存和存儲(chǔ)使用的信息。

圖片

4.3 數(shù)據(jù)段

隨著分片內(nèi)數(shù)據(jù)的增長，數(shù)據(jù)會(huì)被劃分為多個(gè)段。

Elasticsearch 在 JVM 堆內(nèi)存中保留段元數(shù)據(jù)，以便可以快速檢索用于搜索。隨著分片的增長，其段被合并成更少的更大的段。這減少了段的數(shù)量，意味著在堆內(nèi)存中保留的元數(shù)據(jù)更少。

這些段會(huì)定期合并，以優(yōu)化查詢性能和資源使用。

5、分片大小的最佳實(shí)踐

5.1 理想的分片大小

官方建議：分片大小在 10GB 到 50GB 之間通常是有效的，這有助于平衡資源使用和恢復(fù)時(shí)間。

5.2 節(jié)點(diǎn)上的分片數(shù)

參考依據(jù)之一：根據(jù)節(jié)點(diǎn)的內(nèi)存容量保持分片數(shù)。例如，具有 30GB 堆內(nèi)存的節(jié)點(diǎn)最多應(yīng)承載 600 個(gè)分片。

參考依據(jù)之二：數(shù)據(jù)節(jié)點(diǎn)個(gè)數(shù)，設(shè)置索引分片數(shù)據(jù)建議數(shù)據(jù)節(jié)點(diǎn)的1（或者1.5）-3倍。

5.3 最佳實(shí)踐和工具的使用

節(jié)點(diǎn)的堆內(nèi)存：通過以下命令檢查每個(gè)節(jié)點(diǎn)的當(dāng)前堆內(nèi)存大小。

GET _cat/nodes?v=true&h=heap.current

圖片

檢查節(jié)點(diǎn)上的分片數(shù)：使用以下命令來查看每個(gè)節(jié)點(diǎn)上的分片數(shù)量。

GET _cat/shards?v=true

圖片

顯式映射：與其讓 Elasticsearch 自動(dòng)創(chuàng)建映射，不如明確地定義它們，以避免不必要的資源使用。

6、使用數(shù)據(jù)流和 ILM

對(duì)于時(shí)間序列數(shù)據(jù)，使用數(shù)據(jù)流（data stream）和索引生命周期管理 (ILM) 可以簡化時(shí)間基礎(chǔ)索引的管理。

ILM 幫助根據(jù)特定標(biāo)準(zhǔn)自動(dòng)管理滾動(dòng)和刪除，確保有效的數(shù)據(jù)存儲(chǔ)和分片管理。

7、實(shí)踐中調(diào)整分片

• 滾動(dòng)標(biāo)準(zhǔn)

設(shè)置基于分片大小或文檔數(shù)量的滾動(dòng)條件，防止任何單個(gè)分片變得過大。

圖片

PUT my-index-000001/_settings
{
  "index" : {
    "routing.allocation.total_shards_per_node" : 5
  }
}

避免熱點(diǎn)：均勻地在節(jié)點(diǎn)之間分配分片，以防止任何單個(gè)節(jié)點(diǎn)成為性能瓶頸。顯式映射：與其讓 Elasticsearch 自動(dòng)創(chuàng)建映射，不如明確地定義它們，以避免不必要的資源使用。

8、減少分片數(shù)量

如果我們的集群已經(jīng)存在過度分片問題，可以考慮：

（1）合并索引：將小型、相似的索引合并成更大的索引。

圖片

POST _reindex
{
  "source": {
    "index": "my-index-2099.10.*"
  },
  "dest": {
    "index": "my-index-2099.10"
  }
}

刪除不使用的索引：刪除不再需要的索引以釋放資源。

DELETE my-index-000001

沒到這個(gè)地方，咱們都多強(qiáng)調(diào)一句——?jiǎng)h除索引，而不是文檔！

刪除的文檔不會(huì)立即從 Elasticsearch 的文件系統(tǒng)中移除。相反，Elasticsearch 會(huì)在每個(gè)相關(guān)分片上標(biāo)記該文檔為已刪除。標(biāo)記的文檔將繼續(xù)使用資源，直到在定期的段合并期間被移除。

（2）壓縮索引：減少不再寫入數(shù)據(jù)的舊索引中的分片數(shù)量。

9、處理分片相關(guān)錯(cuò)誤

注意節(jié)點(diǎn)最大分片數(shù)設(shè)置。如果某個(gè)操作超過了這個(gè)限制，可能需要臨時(shí)調(diào)整該設(shè)置或考慮更永久的解決方案，

如增加節(jié)點(diǎn)或合并分片。

必知必會(huì)兩個(gè)核心參數(shù)：

- cluster.max_shards_per_node

- index.routing.allocation.total_shards_per_node

9.1 cluster.max_shards_per_node

這是一個(gè)集群級(jí)別的設(shè)置，用來限制每個(gè)節(jié)點(diǎn)可以持有的最大分片數(shù)。默認(rèn)值：1000。

其目的是防止單個(gè)節(jié)點(diǎn)由于持有過多分片而過載，這可能會(huì)導(dǎo)致性能下降和穩(wěn)定性問題。

https://www.elastic.co/guide/en/elasticsearch/reference/8.14/misc-cluster-settings.html

• 使用場景

防止節(jié)點(diǎn)過載——在大規(guī)模部署中，防止任何單個(gè)節(jié)點(diǎn)因分片數(shù)量過多而成為性能瓶頸。

集群擴(kuò)展——在節(jié)點(diǎn)添加到集群或從集群中移除時(shí)，該設(shè)置幫助平衡分片分布，保持集群的健康和性能。

• 注意事項(xiàng)

（1）如果 cluster.max_shards_per_node 設(shè)置得太低，可能會(huì)妨礙Elasticsearch正常的分片分配，特別是在集群擴(kuò)展或收縮時(shí)。

（2）可以動(dòng)態(tài)更新這個(gè)設(shè)置，以適應(yīng)集群的變化，如節(jié)點(diǎn)增加或減少。

圖片

PUT _cluster/settings
{
  "persistent" : {
    "cluster.max_shards_per_node": 1200
  }
}

9.2. index.routing.allocation.total_shards_per_node

這是一個(gè)索引級(jí)別的設(shè)置，用于限制特定索引的分片可以分配到每個(gè)節(jié)點(diǎn)的最大數(shù)目。這個(gè)設(shè)置允許對(duì)單個(gè)索引的分片分布進(jìn)行更細(xì)致的控制。

• 使用場景

分片均衡——確保一個(gè)高流量的索引不會(huì)在少數(shù)節(jié)點(diǎn)上聚集過多分片，從而避免這些節(jié)點(diǎn)成為熱點(diǎn)。特定索引的性能優(yōu)化：針對(duì)訪問模式和查詢負(fù)載對(duì)特定索引進(jìn)行優(yōu)化。

圖片

• 注意事項(xiàng)

在索引的生命周期中，我們可能需要根據(jù)使用模式和節(jié)點(diǎn)的變化調(diào)整這個(gè)設(shè)置。

使用這個(gè)設(shè)置可以增加配置的復(fù)雜性，需要詳細(xì)監(jiān)控和調(diào)整以確保最佳性能。

雖然這兩個(gè)設(shè)置都涉及分片分配，但 cluster.max_shards_per_node 提供了一個(gè)全局的安全網(wǎng)，防止任何節(jié)點(diǎn)因分片過多而過載。

而 index.routing.allocation.total_shards_per_node 允許對(duì)單個(gè)索引進(jìn)行更細(xì)粒度的控制。在實(shí)踐中，這兩個(gè)設(shè)置可以同時(shí)使用，以確保節(jié)點(diǎn)不會(huì)因全局或局部的分片分布不均而影響整體的Elasticsearch集群性能。

總的來說，適當(dāng)配置這兩個(gè)參數(shù)能夠有效地管理和優(yōu)化 Elasticsearch 集群的分片分布，從而提高查詢性能和系統(tǒng)穩(wěn)定性。在實(shí)際操作中，應(yīng)根據(jù)集群的具體業(yè)務(wù)場景需求和表現(xiàn)來調(diào)整這些設(shè)置，以達(dá)到最佳的運(yùn)行效果。

10、結(jié)論

在 Elasticsearch 中，有效地管理分片對(duì)于維護(hù)最佳性能至關(guān)重要。通過仔細(xì)規(guī)劃我們的分片策略并定期監(jiān)控分片性能和資源使用情況，可以確保 Elasticsearch 集群保持穩(wěn)定、可擴(kuò)展和快速。

記住，最好的分片方法是能夠適應(yīng)我們的數(shù)據(jù)和查詢需求的不斷變化的方法。

開篇問題也得以解決，截圖如下。

圖片

https://www.elastic.co/guide/en/elasticsearch/reference/8.14/size-your-shards.html