Elasticsearch：規格容量評估

注意事項

本文根據實際測試結果和使用者使用經驗提供評估方法。由於不同使用者在資料結構、查詢複雜度、資料量大小、效能及資料變化等方面的需求不同，本文的評估不一定適用於所有使用者。建議您在條件允許的情況下，通過實際的資料和使用情境測試出適合自己的叢集規格容量規劃。

評估叢集儲存空間

影響ES叢集儲存空間大小的因素主要包括：

• 來源資料的大小。

• 索引的副本數量：每個索引至少需要1個副本。

• 索引開銷：通常比來源資料大10%。

  例如，儲存X-Pack組件用於異常分析的監控類索引，主要包含：

  • .monitoring-es-6-*：佔用空間相對比較大，預設保留最近7天的索引資料。

  • .monitoring-kibana-6-*：索引數越大佔用空間也越大，預設保留最近7天的索引資料。

  • .watcher-history-3-*：佔用空間相對比較小，如果開啟，需要您手動刪除。

• ES執行個體內部開銷：段合并、日誌等內部操作，預留20%。

  儲存叢集日誌（包括作業記錄、訪問日誌和慢日誌）隨著查詢或推送訪問量的增加，空間佔比不斷增大，預設保留最近7天的日誌，不支援修改。

• 作業系統預留空間：預設作業系統會保留5%的檔案系統供您處理關鍵流程、系統復原以及磁碟片段等。

• 安全閾值：通常至少預留15%的安全閾值。

根據以上因素得到建議叢集儲存空間：

叢集儲存空間 = 來源資料 *（1 + 副本數量）* 索引開銷 /（1 - 作業系統預留空間）/（1 - ES執行個體內部開銷）/（1 - 安全閾值）
             = 來源資料 *（1 + 副本數量）* 1.7
             = 來源資料 * 3.4

主分區數量不會影響磁碟空間佔用：增加主分區時，資料會在分區之間重新分配，總資料量不變，因此不會增加磁碟空間佔用。增加副本數量會按比例增加磁碟使用：每增加一個副本，都會完整複製一份來源資料，對應上述公式中的（1 + 副本數量）因子，副本數量越多，磁碟佔用越大。

因此，當單個分區儲存量過大時，建議通過增加主分區來解決，而不是增加副本。可以通過 _split API 拆分索引，或者重建索引（reindex）來調整分區數量。

評估節點規格和節點數量

資料節點

• 最大節點數量 = 單節點CPU大小 * 5。

• 業務情境不同，單節點最大承載資料量也不同：

  • 通用情境：單節點最大儲存空間 = 單節點記憶體大小（GiB）* 30。

  • 搜尋情境（資料庫加速、查詢彙總等）：單節點最大儲存空間 = 單節點記憶體大小（GiB）* 10。

  • 日誌分析情境（日誌寫入、離線分析等）：單節點最大儲存空間 = 單節點記憶體大小（GiB）* 50。

根據以上計算方式，得到部分節點規格的最大節點數量和單節點最大儲存空間：

叢集儲存空間=單節點儲存空間*節點數量，您可以根據單節點最大儲存空間和最大節點數量選擇滿足業務要求的節點規格。

專有主節點

如果叢集的資料節點較多，建議您開啟專有主節點，以保證叢集穩定性。

專有主節點規格選擇：

• 初始規格：2 核8 GiB

• 超過10個資料節點：4 核16 GiB

• 超過30個資料節點：8 核32 GiB

• 超過50個資料節點：16 核64 GiB

協調節點

使用獨立的協調節點，可以對最終的結果進行reduce操作，這樣即使reduce階段出現GC嚴重的現象，也不會影響資料節點。

如果開啟協調節點，建議協調節點與資料節點個數的比例為1:5（協調節點2個起購），協調節點建議選擇1:4或1:8規格類型系列。例如，10個8核32 GiB的資料節點，建議配置2個8核32 GiB的協調節點。

評估Shard

Shard儲存量和數量是影響阿里雲ES叢集穩定性和效能的重要因素之一。ES叢集中任何一個索引都需要進行合理的Shard規劃，防止因業務不明確導致分區龐大消耗ES本身效能，或導致負載不均衡，例如節點間磁碟使用率差距很大，節點CPU使用率呈現明顯的負載不均衡。

基於以上問題，下文對Shard規劃提供了一些建議。這些建議僅供參考，實際業務中還需根據需求進行調整：

• Shard儲存量

  • 建議單個Shard儲存量保持在30 GiB以內（最優），特殊情況下可以提升到50 GiB以內。

  • 對於日誌分析或者超大索引情境，建議單個Shard儲存量不要超過100 GiB。

• Shard數量

  • 在分配Shard前，建議對ES進行資料測試。

    • 資料量很大時，需要減少寫入量的大小，降低ES壓力，建議選擇多主1副本。

    • 資料量較小，且寫入量也較小時，建議使用單主多副本或者單主1副本。

    說明

    • 7.x及以上版本執行個體預設一個索引建立1個主分區和1個副本分區。7.x以下版本執行個體預設一個索引建立5個主分區，並分別為每個主分區建立1個副本分區。

    • Shard儲存量低於30 GiB的業務，可以使用單主多副本的策略進行負載平衡。例如，20 GiB的單索引，分布在5個資料節點中，可以考慮單主4副本的Shard規劃。

  • 建議Shard個數（包括主分區和副本分區）儘可能等於資料節點數，或者是資料節點數的整數倍。

  • 建議單個節點上同一索引的Shard個數不要超過5個。

  • 建議按照以下說明，評估單個節點上全部索引的Shard數量。

    • 小規格執行個體參考：單個資料節點的Shard數量 = 當前節點的記憶體大小 * 30

    • 大規格執行個體參考：單個資料節點的Shard數量 = 當前節點的記憶體大小 * 50

    說明

    • 評估Shard數量時，還需結合資料量進行分析，建議TiB層級以下的資料量參考小規格執行個體進行評估。

    • 7.x版本ES執行個體預設的單節點Shard上限為1000個（官方不建議調整），您可以通過增加或擴容節點數量來調整單節點的Shard數量。

    • Shard個數不是越多越好。主分區越多ES效能開銷也會越大，shard數量太多極易引起檔案控制代碼耗盡，導致叢集故障。

當叢集中同時存在多個業務索引時，上述建議需要按索引逐個落到具體的主分區數。您可以按以下步驟規劃：

1. 統計每個索引的現狀與增長趨勢。使用GET _cat/indices?v&bytes=b查看各索引當前的儲存大小，並結合每日增量和資料保留周期，估算每個索引在保留周期內的預計儲存量。日誌類按天或按周滾動的索引，按單個滾動周期的資料量估算，不按累計量估算。

2. 按單個Shard儲存量計算主分區數。以單個Shard儲存量30 GiB以內為最優目標，特殊情況下可放寬到50 GiB以內，即主分區數 = 索引預計儲存量 ÷ 單個Shard目標儲存量，結果向上取整。儲存量低於30 GiB的小索引保持1個主分區，通過增加副本分區做負載平衡。

3. 用資料節點數量校正主分區數。調整上一步的結果，使該索引的Shard總數（主分區數 × (1 + 副本分區數)）等於資料節點數或其整數倍，同時保證單個節點上同一索引的Shard個數不超過5個。例如某索引預計儲存量360 GiB，按30 GiB目標得到12個主分區，叢集有6個資料節點，12是6的整數倍，配置1個副本分區後Shard總數為24，仍為6的整數倍，規劃成立。

4. 匯總校正單節點Shard總量。把所有索引的Shard數量相加後除以資料節點數，與本文給出的單個資料節點Shard數量上限（小規格執行個體為節點記憶體大小 × 30，大規格執行個體為節點記憶體大小 × 50，7.x版本執行個體預設單節點上限1000個）比對。超出上限時優先合并或清理低價值的小索引，其次通過增加或擴容節點數量提升上限。

5. 讓規劃生效。主分區數只能在建立索引時指定，因此規劃結果需要區分新索引和已有索引落地：新索引在執行個體詳情的ES叢集配置 > 情境化配置 > 索引模板配置中寫入分區設定，該模板僅在建立索引時應用，更改模板不會影響已有索引；已有索引需要通過_splitAPI拆分或者reindex重建索引來調整主分區數。

規劃落地後，如果出現節點間磁碟使用率或CPU使用率差距較大的現象，或在事件中心看到節點CPU負載不均衡事件，說明問題在Shard分布而不是Shard總量，可以按叢集負載不均分析中的方法定位到具體的索引和節點後再調整。

關於評估Shard的更多資訊，請參見How to size your shards。

相關文檔

• 瞭解不同地區和版本支援的節點規格或購買ES執行個體，請參見購買頁。

• 瞭解不同節點規格的效能，可以參考阿里雲ES執行個體不同規格和版本的壓測實驗結果，請參見產品效能。

• 如果您對選擇執行個體類型（通用商業版、核心增強型）或執行個體版本有疑問，請參見版本特性。

• 對於已存在的叢集，您可以根據評估結果調整節點規格、節點儲存空間、節點數量等。具體操作和限制，請參見升配叢集和降配叢集。

• 主分區的數量只能在建立索引時指定，並且建立索引後不能更改。建立索引，請參見建立索引。

• 對於已存在的索引，如果Shard超過推薦儲存量，建議通過reindex重建索引。具體操作，請參見阿里雲ES間跨叢集reindex。

  說明

  reindex能保證不停機，但是比較耗時。

• 叢集負載不均問題的分析方法及解決方案。

• 通過手動遷移shard均勻分布熱點資料的解決方案。

• 如果開啟了自動建立索引功能，建議啟用索引生命週期管理，或者通過ES API指令碼刪除到期的索引。

• 建議及時清理小索引，小索引同樣會佔用ES堆記憶體。

ES索引儲存空間差異大的常見原因

不同索引之間的儲存空間可能存在較大差異，常見原因及排查方法如下：

• 分詞器設定不同：ngram分詞器將文本切分為指定長度的字元組合，產生的token數量遠多於standard分詞器，導致倒排索引更大。例如相同文檔使用ngram（min_gram=1, max_gram=4）分詞器的索引儲存約為standard分詞器的3.4倍。

• 欄位類型和mapping設定不同：text類型欄位會構建倒排索引，keyword類型不會。不同mapping配置直接影響儲存佔用。

• 副本數量不同：number_of_replicas參數設定越高，總儲存佔用越大。

• 壓縮方式不同：best_compression使用DEFLATE演算法，壓縮比高於default的LZ4演算法，但讀寫效能略有降低。

排查儲存差異的方法：

• 使用GET _cat/indices?v&bytes=b查看各索引的儲存大小。

• 使用POST <index>/_disk_usage?run_expensive_tasks=true分析欄位級儲存分布，定位佔比較大的欄位。

常見問題

如何判斷ES執行個體是否需要擴容，以及IOPS、磁碟頻寬是否存在風險？

先用監控指標判斷整體資源是否接近邊界，再用事件判斷磁碟IO是否已成為瓶頸，最後按短期和長期兩條路徑處置。

判斷是否需要擴容

在執行個體詳情的叢集監控 > 基礎監控中，把時間範圍切到7天，觀察節點CPU使用率(%)、節點磁碟使用率(%)、節點HeapMemory使用率(%)、節點load_1m四條資源類曲線，並結合叢集狀態、叢集寫入QPS（Count/Second）和叢集查詢QPS（Count/Second）判斷壓力來源。資源類指標長期處於高位（經驗參考：持續高於80%）時，即使沒有收到警示，叢集也已經接近容量邊界，寫入和查詢延遲會隨流量波動放大，建議考慮升配。水位參考值可以對齊一鍵警示的預設規則：節點磁碟使用率超過75%、節點JVM Heap使用率超過85%即視為異常。儲存維度還可以用本文「評估叢集儲存空間」的公式和「資料節點」章節的單節點最大儲存空間反推當前規格還能承載多少資料。

識別IOPS與磁碟頻寬風險

基礎監控提供的是上述7個指標，不包含獨立的IOPS曲線和磁碟頻寬（輸送量）曲線，因此磁碟IO是否觸及上限需要通過事件判斷。在事件中心按發生時間和事件等級（資訊、警告、嚴重）篩選，重點關注以下事件：

雲端硬碟的IOPS與輸送量上限隨儲存類型和單節點儲存空間變化，選型階段可以在購買頁或升配頁的儲存類型說明中確認各類雲端硬碟的適用情境：SSD雲端碟適合擁有高IOPS、資料響應度較高的線上分析和搜尋情境，高效雲端碟面向大規模資料量的日誌及分析情境。

處置建議

• 短期緩解：最佳化查詢，減少不必要的彙總、深分頁和萬用字元首碼查詢；對儲存量已經偏大的索引，按業務重要性下調副本分區數量以降低寫入與磁碟壓力；按本文「評估Shard」重新核對分區規劃。需要注意主分區數量只能在建立索引時指定，已有索引只能通過_splitAPI或者reindex重建索引調整，不能線上修改。

• 長期擴容：在執行個體列表中通過行操作升配提升節點規格、增加節點數量或擴容儲存空間，具體操作和限制請參見升配叢集。開發人員規格執行個體升配期間服務會中斷，且升配到普通規格後無法降回開發人員規格，請安排在業務低峰期操作。

• 如果只有部分節點資源高位、其餘節點空閑，先按叢集負載不均分析排查負載不均，擴容無法解決分布不均帶來的效能問題。

• 開啟一鍵警示，在磁碟使用率、JVM Heap使用率和叢集狀態出現異常時提前收到通知，避免等到查詢逾時才發現容量不足。