全部產品
Search
文件中心

Elasticsearch:規格容量評估

更新時間:Jun 30, 2024

在購買或升縮配Elasticsearch叢集前,您可以根據本文提供的相對通用的評估方法,初步評估叢集所需資源的規格容量,包括節點規格、節點儲存空間和節點數量。建立索引前或遇到節點間磁碟使用率差距很大、節點CPU使用率呈現明顯的負載不均衡等現象時,評估索引的shard儲存量和數量。

注意事項

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

評估叢集儲存空間

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

  • 來源資料的大小。

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

  • 索引開銷:通常比來源資料大10%,預設不開啟_all參數的索引。

    例如,儲存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為例,如果調整副本數量,請重新計算。

開啟_all參數的索引後,索引儲存空間的開銷也會隨之增大。根據測試結果和使用經驗,建議將叢集儲存空間增加至原來的1.5倍,即:

節點儲存空間總大小 = 來源資料 *(1 + 副本數量)* 1.7 *1.5
                 = 來源資料 *(1 + 副本數量)* 2.55
說明

如果不需要在業務上使用_all參數,通常建議您禁止或者有選擇性地添加_all參數。

評估節點規格和節點數量

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

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

    • 通用情境:單節點最大儲存空間 = 單節點記憶體大小(GiB)* 30。

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

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

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

節點規格

最大節點數量

單節點最大儲存空間

通用情境

搜尋情境

日誌分析情境

2核4 GiB

10

120 GiB

40 GiB

200 GiB

2核8 GiB

10

240 GiB

80 GiB

400 GiB

4核16 GiB

20

480 GiB

160 GiB

800 GiB

8核32 GiB

40

960 GiB

320 GiB

1.5 TiB

16核64 GiB

80

1.9 TiB

640 GiB

3 TiB

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

  • 彙總查詢(Agg查詢)情境資料節點規格建議選擇1:2規格類型系列,並開啟協調節點。

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

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

  • 資料節點數量會影響Shard總數量,在確定執行個體規格前您還需要評估索引的Shard。

評估Shard

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

說明

Shard是索引在ES中的分布式儲存單元,包括主分區和副本分區。詳細資料,請參見分區和副本

在進行Shard規劃前,需要先考慮以下幾個問題:

  • 當前單個索引的資料多大?

  • 資料是否會持續增長?

  • 購買的執行個體規格多大?

  • 是否會定期刪除索引或合并臨時索引?

基於以上問題,下文對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 API指令碼刪除到期的索引。

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