Elasticsearch 是一個強大的搜索和分析引擎，它通過將數據分散到多個節點的分片中來進行分布式處理。

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

先看個分片設置不合理的真實企業案例：

圖片

10TB 左右集群數據，只有兩個節點集群。單個最大索引 600GB，7.17.4 版本，200分片（全部）。

集群重啟無法啟動，未咨詢之前是：最長時間8小時啟動集群，過年期間，直接無法啟動（已啟動了20個小時+）。

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

1、什么是分片？

在 Elasticsearch 中，每個索引都被劃分為多個分片，每個分片可以在多個節點上復制，以確保數據的可用性和冗余。

圖片

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

然而，盡管分片允許通過分散數據來擴展，不當的分片可能導致性能瓶頸或穩定性問題。

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

有效的分片關鍵在于找到正確的平衡。

過多的分片會導致“過度分片”，在這種情況下，管理眾多分片的開銷超過了其帶來的好處，導致查詢處理效率降低，可能還會引發集群不穩定。

3、創建分片策略

為了防止這些問題，至關重要的是要根據我們的特定需求開發一個分片策略，這包括：

• 了解集群的數據和查詢：分析咱們所在集群的數據性質和將執行的查詢。
• 基準測試：在類似生產環境中測試不同的分片配置，看看更改如何影響性能。

舉例，如下基準測試僅供參考。

在實際應用中，應根據具體需求和資源條件，選擇最適合的分片配置。

• 監控：使用 Kibana 等工具監控不同分片大小和配置對集群性能和穩定性的影響。

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

所以，大廠的意見、建議、經驗貼不見得適用我們下廠。這很關鍵！

4、分片大小的關鍵考慮因素

4.1 搜索線程

每個分片在單獨的線程中處理搜索查詢。如果存在太多分片，可能會超負荷節點的搜索線程池，從而減慢查詢處理速度。

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

圖片

上述命令會顯示集群中所有節點的所有線程池的信息，幫助我們識別哪些線程池可能過載。

4.2 分片開銷

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

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

雖然沒有直接的命令行工具可以顯示每個分片的 CPU 使用情況（因為 CPU 使用通常被監控在節點級別而非分片級別），但咱們可以獲取關于每個分片內存和存儲使用的信息。

圖片

4.3 數據段

隨著分片內數據的增長，數據會被劃分為多個段。

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

這些段會定期合并，以優化查詢性能和資源使用。

5、分片大小的最佳實踐

5.1 理想的分片大小

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

5.2 節點上的分片數

參考依據之一：根據節點的內存容量保持分片數。例如，具有 30GB 堆內存的節點最多應承載 600 個分片。

參考依據之二：數據節點個數，設置索引分片數據建議數據節點的1（或者1.5）-3倍。

5.3 最佳實踐和工具的使用

節點的堆內存：通過以下命令檢查每個節點的當前堆內存大小。

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

圖片

檢查節點上的分片數：使用以下命令來查看每個節點上的分片數量。

GET _cat/shards?v=true

圖片

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

6、使用數據流和 ILM

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

ILM 幫助根據特定標準自動管理滾動和刪除，確保有效的數據存儲和分片管理。

7、實踐中調整分片

• 滾動標準

設置基于分片大小或文檔數量的滾動條件，防止任何單個分片變得過大。

圖片

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

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

8、減少分片數量

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

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

圖片

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

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

DELETE my-index-000001

沒到這個地方，咱們都多強調一句——刪除索引，而不是文檔！

刪除的文檔不會立即從 Elasticsearch 的文件系統中移除。相反，Elasticsearch 會在每個相關分片上標記該文檔為已刪除。標記的文檔將繼續使用資源，直到在定期的段合并期間被移除。

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

9、處理分片相關錯誤

注意節點最大分片數設置。如果某個操作超過了這個限制，可能需要臨時調整該設置或考慮更永久的解決方案，

如增加節點或合并分片。

必知必會兩個核心參數：

- cluster.max_shards_per_node

- index.routing.allocation.total_shards_per_node

9.1 cluster.max_shards_per_node

這是一個集群級別的設置，用來限制每個節點可以持有的最大分片數。默認值：1000。

其目的是防止單個節點由于持有過多分片而過載，這可能會導致性能下降和穩定性問題。

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

• 使用場景

防止節點過載——在大規模部署中，防止任何單個節點因分片數量過多而成為性能瓶頸。

集群擴展——在節點添加到集群或從集群中移除時，該設置幫助平衡分片分布，保持集群的健康和性能。

• 注意事項

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

（2）可以動態更新這個設置，以適應集群的變化，如節點增加或減少。

圖片

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

9.2. index.routing.allocation.total_shards_per_node

這是一個索引級別的設置，用于限制特定索引的分片可以分配到每個節點的最大數目。這個設置允許對單個索引的分片分布進行更細致的控制。

• 使用場景

分片均衡——確保一個高流量的索引不會在少數節點上聚集過多分片，從而避免這些節點成為熱點。特定索引的性能優化：針對訪問模式和查詢負載對特定索引進行優化。

圖片

• 注意事項

在索引的生命周期中，我們可能需要根據使用模式和節點的變化調整這個設置。

使用這個設置可以增加配置的復雜性，需要詳細監控和調整以確保最佳性能。

雖然這兩個設置都涉及分片分配，但 cluster.max_shards_per_node 提供了一個全局的安全網，防止任何節點因分片過多而過載。

而 index.routing.allocation.total_shards_per_node 允許對單個索引進行更細粒度的控制。在實踐中，這兩個設置可以同時使用，以確保節點不會因全局或局部的分片分布不均而影響整體的Elasticsearch集群性能。

總的來說，適當配置這兩個參數能夠有效地管理和優化 Elasticsearch 集群的分片分布，從而提高查詢性能和系統穩定性。在實際操作中，應根據集群的具體業務場景需求和表現來調整這些設置，以達到最佳的運行效果。

10、結論

在 Elasticsearch 中，有效地管理分片對于維護最佳性能至關重要。通過仔細規劃我們的分片策略并定期監控分片性能和資源使用情況，可以確保 Elasticsearch 集群保持穩定、可擴展和快速。

記住，最好的分片方法是能夠適應我們的數據和查詢需求的不斷變化的方法。

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

圖片

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