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

評估節點規格和節點數量

資料節點

• 最大節點數量 = 單節點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數量太多極易引起檔案控制代碼耗盡，導致叢集故障。

關於評估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分析欄位級儲存分布，定位佔比較大的欄位。