管理 ES 叢集：如何對叢集進行容量規劃

• 一個叢集總共需要多少個節點？ 一個索引需要設定幾個分片？
  • 規劃上需要保持一定的餘量，當負載出現波動，節點出現丟失時，還能正常執行
• 做容量規劃時，一些需要考慮的因素
  • 機器的軟硬體配置
  • 單條文件的尺寸 / 文件的總資料量 / 索引的總資料量（Time base 資料保留的時間）/ 副本分片數
  • 文件是如何寫入的（Bulk的尺寸）
  • 文件的複雜度，文件是如何進行讀取的（怎麼樣的查詢和聚合）

• 資料吞吐及效能需求
  • 資料寫入的吞吐量，每秒要求寫入多少資料？
  • 查詢的吞吐量？
  • 單條查詢可接受的最大返回時間？
• 瞭解你的資料
  • 資料的格式和資料的 Mapping
  • 實際的查詢和聚合長的是什麼樣的

• 搜尋：固定大小的資料集
  • 搜尋的資料集增長相對比較緩慢
• 日誌：基於時間序列的資料
  • 使用 ES 存放日誌與效能指標。資料每天不斷寫入，增長速度較快
  • 結合 Warm Node 做資料的老化處理

• 選擇合理的硬體，資料節點儘可能使用 SSD
• 搜尋等效能要求高的場景，建議 SSD
  • 按照 1 ：10 的比例配置記憶體和硬碟
• 日誌類和查詢併發低的場景，可以考慮使用機械硬碟儲存
  • 按照 1：50 的比例配置記憶體和硬碟
• 單節點資料建議控制在 2 TB 以內，最大不建議超過 5 TB
• JVM 配置機器記憶體的一半，JVM 記憶體配置不建議超過 32 G

• 按需選擇合理的部署方式
• 如果需要考慮可靠性高可用，建議部署 3 臺 dedicated 的 Master 節點
• 如果有複雜的查詢和聚合，建議設定 Coordinating 節點

• 一些案例：唱片資訊庫 / 產品資訊
• 一些特性
  • 被搜尋的資料集很大，但是增長相對比較慢（不會有大量的寫入）。更關心搜尋和聚合的讀取效能
    • 資料的重要性與時間範圍無關。關注的是搜尋的相關度
• 估算索引的的資料量，然後確定分片的大小
  • 單個分片的資料不要超過 20 GB
  • 可以通過增加副本分片，提高查詢的吞吐量

• 如果業務上有大量的查詢是基於一個欄位進行 Filter，該欄位又是一個數量有限的列舉值
  • 例如訂單所在的地區
• 如果在單個索引有大量的資料，可以考慮將索引拆分成多個索引
  • 查詢效能可以得到提高
  • 如果要對多個索引進行查詢，還是可以在查詢中指定多個索引得以實現
• 如果業務上有大量的查詢是基於一個欄位進行 Filter，該欄位數值並不固定
  • 可以啟用 Routing 功能，按照 filter 欄位的值分佈到叢集中不同的 shard，降低查詢時相關的 shard， 提高 CPU 利用率

• 相關的用案
  • 日誌 / 指標 / 安全相關的 Events
  • 輿情分析
• 一些特性
  • 每條資料都有時間戳；文件基本不會被更新（日誌和指標資料）
  • 使用者更多的會查詢近期的資料；對舊的資料查詢相對較少
  • 對資料的寫入效能要求比較高

• 建立 time-based 索引
  • 在索引的名字中增加時間資訊
  • 按照 每天 / 每週 / 每月 的方式進行劃分
• 帶來的好處
  • 更加合理的組織索引，例如隨著時間推移，便於對索引做的老化處理
    • 利用 Hot & Warm Architecture
    • 備份和刪除以及刪除的效率高。（ Delete By Query 執行速度慢，底層不也不會立刻釋放空間，而 Merge 時又很消 耗資源）

• 容易使用
• 如果時間發生變化，需要重新部署程式碼

# POST /<logs-{now/d}/_search 
POST /%3Clogs-%7Bnow%2Fd%7D%3E/_search

• Time-based 索引
  • 建立索引，每天 / 每週 / 每月
  • 在索引的名字中增加時間資訊

• 增加 Coordinating / Ingest Node
  • 解決 CPU 和 記憶體開銷的問題
• 增加資料節點
  • 解決儲存的容量的問題
  • 為避免分片分佈不均的問題，要提前監控磁碟空間，提前清理資料或增加節點（70%）

本作品採用《CC 協議》，轉載必須註明作者和本文連結