0、引言
實戰中經常遇到的問題：
問題 1：請問下大家是如何評估集羣的規模？比如數據量達到百萬，千萬，億萬，分別需要什麼級別的集羣，這要怎麼評估？
ps：自己搭建的測試環境很難達到這一級別。
問題 2：
問題 3：我看了很多文章關於 es 集羣規劃的文章，總感覺亂七八糟的，沒有一個統一的規劃思路。如何根據硬件條件和數據量來規劃集羣，設置多少節點，每個節點規劃多少分片和副本？
Elasticsearch 集羣規模和容量規劃：是進行 Elasticsearch 集羣部署前對所需資源類型和數量的規劃。
通過本文，您將瞭解：
Elasticsearch 計算資源詳解
Elasticsearch 架構、增刪改查操作和資源需求
Elasticsearch 集羣規模和容量規劃的方法論
1、Elasticsearch 基礎架構
1.1 自頂向下的架構體系![]()
Cluster—協同工作的節點組，以保障 Elasticsearch 的運行。
Node—運行 Elasticsearch 軟件的 Java 進程。
Index—一組形成邏輯數據存儲的分片的集合。
Shard—Lucene 索引，用於存儲和處理 Elasticsearch 索引的一部分。
Segment—Lucene 段，存儲了 Lucene 索引的一部分且不可變。
Document—條記錄，用以寫入 Elasticsearch 索引並從中檢索數據。
1.2 節點角色劃分及資源使用情況
| 角色 | 描述 | 存儲 | 內存 | 計算 | 網絡 |
|---|---|---|---|---|---|
| 數據節點 | 存儲和檢索數據 | 極高 | 高 | 高 | 中 |
| 主節點 | 管理集羣狀態 | 低 | 低 | 低 | 低 |
| Ingest 節點 | 轉換輸入數據 | 低 | 中 | 高 | 中 |
| 機器學習節點 | 機器學習 | 低 | 極高 | 極高 | 中 |
| 協調節點 | 請求轉發和合並檢索結果 | 低 | 中 | 中 | 中 |
劃重點：對資源利用率拿不準的，多結合業務實際看看這個表格。
2、維繫 Elasticsearch 高性能的資源組成
4 個基本的計算資源 存儲、內存、計算、網絡
2.1 存儲資源
2.1.1 存儲介質
固態硬盤（SSD） 提供最佳“熱”工作負載的性能。
普通磁盤（HDD） 成本低，用於“暖”和“冷”數據存儲。
注意：RAID0 可以提高性能。RAID 是可選的，因爲 Elastic 默認爲 N + 1 分片複製策略。
爲了追求硬件級別的高可用性，可以接受標準性能的 RAID 配置（例如 RAID 1/10/50 等）。
2.1.2 存儲建議
建議直接使用：附加存儲（DAS）、存儲區域網絡（SAN）、超融合存儲（建議最低〜3Gb / s，250Mb / s）
避免使用：網絡附加存儲（NAS）
例如 SMB，NFS，AFP。使用時可能帶來的性能問題：網絡協議的開銷，延遲大和昂貴的存儲抽象層。
2.2 內存資源
2.2.1 JVM Heap
存儲有關集羣索引、分片、段和 fielddata 數據。
建議：可用 RAM 的 50％，最多最大 30GB RAM，以避免垃圾回收。
官方文檔最大指 32 GB：
https://www.elastic.co/guide/en/elasticsearch/guide/master/heap-sizing.html
2.2.2 操作系統緩存
Elasticsearch 將使用剩餘的可用內存來緩存數據（Lucene 使用）， 通過避免在全文檢索、文檔聚合和排序環節的磁盤讀取，極大地提高了性能。
2.3 計算資源
Elasticsearch 如何使用計算資源？
Elasticsearch 處理數據的方式多種多樣，但計算成本較高。
可用的計算資源：線程池、線程隊列。
CPU 內核的數量和性能：決定着計算平均速度和峯值吞吐量。
2.4 網絡資源
Elasticsearch 如何使用網絡？小帶寬是限制 Elasticsearch 的資源。
針對大規模集羣，ingest、搜索和副本複製相關的數據傳輸可能會導致網絡飽和。
在這些情況下，網絡連接可以考慮升級到更高的速度，或者 Elastic 部署可以分爲兩個或多個集羣，然後使用跨集羣（CCS）作爲單個邏輯單元進行搜索。
3、數據增刪改查操作
增、刪、改、查是 Elasticsearch 中的四個基本數據操作。
每個操作都有其自己的資源需求。每個業務用例都利用其中一個操作，實際業務往往會側重其中一個或多個操作。
增：新增索引處理文檔並將其存儲在索引中，以備將來檢索。
刪：從索引中刪除文檔。
改：更新刪除文檔併爲其替換的新文檔建立索引。
查：搜索從一個或多個索引中檢索或聚合一個或多個文檔。
3.1 增/索引數據處理流程![]()
如圖所示，增/索引數據大致的處理流程如下：
1、客戶端發起寫入請求到協調節點；
2、協調節點根據請求類型的不同進行判斷，如果是 Ingest 相關，提交給 Ingest 節點；如果不相關，則計算路由後提交給數據節點；
3、數據節點根據數據類型不同決定是否分詞以索引化數據，最終落地磁盤存儲；同時將副本分發給其他數據節點。
3.2 刪除數據處理流程![]()
如果所示，刪除數據大致處理流程如下：
1、客戶端發出刪除文檔請求到協調節點；
2、協調節點將請求路由給數據節點；
3、數據節點接收到請求後，將數據標記爲 deleted 狀態（注意，此處爲邏輯刪除）
4、待段合併時機，邏輯刪除會變成物理刪除。
3.3 更新數據處理流程
文檔在 Elasticsearch 中是不可變的。當 Elasticsearch 更新文檔時，它將刪除原始文檔併爲新的待更新的文檔建立索引。
這兩步操作在每個 Lucene 分片是原子操作，操作會帶來刪除和索引（索引不調用任何 ingest pipeline 操作）操作的開銷。
Update = Delete + (Index - Ingest Pipeline）
3.4 檢索操作處理流程
“搜索”是信息檢索的通用術語。Elasticsearch 具有多種檢索功能，包括但不限於全文搜索、範圍搜索、腳本搜索和聚合。
搜索速度和吞吐量受許多因素影響，包括集羣的配置、索引、查詢和硬件。
實際的容量規劃取決於應用上述優化配置後的大量測試實踐結果。
Elasticsearch 檢索可以細化分爲：scatter（分散）、 search（檢索）、gather（收集）、merge（合併）四個階段。
scatter:將結果分發給各個相關的分片；
search：在各個分片執行檢索；
gather：數據節點將檢索結果彙集到協調節點；
merge：協調節點將數據結果進行合併，返回給客戶端。
3.5 用例場景
Elasticsearch 有一些常規的使用模式。大致可分類如下：
寫/索引（Index）密集型的業務場景：Logging, Metrics, Security, APM
檢索（search）密集型的業務場景：App Search, Site Search, Analytics
更新（update）密集型的業務場景：Caching, Systems of Record
混合（hybrid）業務場景：支持多種操作的混合用例 Transactions Search
4、Elasticsearch 索引化流程
4.0 概述
以下過程適用於 ingest 節點處理數據流程。
Json 數據轉換——結構化或非結構化數據，轉換爲 json 落地存儲。
數據索引化——數據以不同數據類型進行處理和索引。
數據壓縮——提高存儲效率。
副本複製——提高容錯能力和搜索吞吐量。
4.1 Json 轉換
結構化或非結構化數據轉換成 json 格式，可通過_source 控制是否展示。
4.2 數據索引化
第一：數據結構 Elasticsearch 索引各種數據結構中的值。每種數據類型 有自己的存儲特性。
第二：多種索引方法 某些值可以通過多種方式索引。字符串值通常是索引兩次（藉助 fields 實現）。
一次作爲聚合的 keyword 類型；
一次作爲文本用於全文搜索的 text 類型。
4.3 數據壓縮
Elasticsearch 可以使用兩種不同的壓縮算法之一來壓縮數據：LZ4（默認）和 DEFLATE。
與 LZ4 相比，DEFLATE 節省了多達 15％的額外空間，但以增加的計算時間爲代價。
通常，Elasticsearch 可以將數據壓縮 20 – 30％。
4.4 副本分片拷貝
第一：存儲 Elasticsearch 可以在數據節點之間複製分片一次或多次，以提高容錯能力和搜索吞吐量。
每個副本分片都是其主分片的完整副本。
第二：索引和搜索吞吐量
日誌記錄和指標用例場景（Logging and metrics）通常具有一個副本分片，這是確保出現故障的最小數量， 同時最大程度地減少了寫入次數。
搜索用例通常具有更多的副本分片以提高搜索吞吐率。
4.5 完整示例
5、集羣規模和容量規劃預估方法
容量規劃——預估集羣中每個節點的分片數、內存及存儲資源。
吞吐量規劃——以預期的延遲和吞吐量估算處理預期操作所需的內存，計算和網絡資源。
5.1 數據量預估
第一，問自己幾個問題：
您每天將索引多少原始數據（GB）？
您將保留數據多少天？
每天增量數據是多少？
您將強制執行多少個副本分片？
您將爲每個數據節點分配多少內存？
您的內存：數據比率是多少？
第二，預留存儲以備錯誤。(Elastic 官方推薦經驗值）
預留 15%警戒磁盤水位空間。
爲錯誤餘量和後臺活動預留+ 5％。
保留等效的數據節點以處理故障。
第三，容量預估計算方法如下：
總數據量（GB） = 原始數據量（GB） /每天 X 保留天數 X 淨膨脹係數 X （副本 + 1）
磁盤存儲（GB） = 總數據量（GB）* ( 1 + 0.15 + 0.05)
數據節點 = 向上取證（磁盤存儲（GB）/ 每個數據節點的內存量 / 內存：數據比率）+ 1
Tips：騰訊雲 在 2019 4 月的 meetup 分享中建議：磁盤容量大小 = 原始數據大小 * 3.38。
5.2 分片預估
第一，問自己幾個問題：
您將創建多少索引？
您將配置多少個主和副本分片？
您將在什麼時間間隔旋轉索引？
您將保留索引多長時間？
您將爲每個數據節點分配多少內存？
第二，經驗值（Elastic 官方推薦）
每 GB JVM 堆內存支持的分片數不超過 20 個。
每個分片大小不要超過 50GB。推薦閱讀：https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
Tips：
將小的每日索引整合爲每週或每月的索引，以減少分片數。
將大型（> 50GB）每日索引分拆分成小時索引或增加主分片的數量。
第三，分片預估方法如下：
總分片數 = 索引個數 X 主分片數 * （副本分片數 +1）X 保留間隔
總數據節點個數 = 向上取整（總分片數 / (20 X 每個節點內存大小））
5.3 搜索吞吐量預估
搜索用例場景除了考慮搜索容量外，還要考慮如下目標：
搜索響應時間；
搜索吞吐量。
這些目標可能需要更多的內存和計算資源。
第一：問自己幾個問題
您期望每秒的峯值搜索量是多少？
您期望平均搜索響應時間是多少毫秒？
您期望的數據節點上幾核 CPU，每核有多少個線程？
第二：方法論
與其確定資源將如何影響搜索速度，不如通過在計劃的固定硬件上進行測量，可以將搜索速度作爲一個常數，
然後確定集羣中要處理峯值搜索吞吐量需要多少個核。
最終目標是防止線程池排隊的增長速度超過了 CPU 的處理能力。
如果計算資源不足，搜索請求可能會被拒絕掉。
第三：吞吐量預估方法
峯值線程數 = 向上取整（每秒峯值檢索請求數 _ 每個請求的平均響應時間（毫秒）/1000）
線程隊列大小 = 向上取整（(每個節點的物理 cpu 核數 _ 每核的線程數 * 3 / 2）+ 1)
總數據節點個數 = 向上取整（峯值線程數 / 線程隊列大小）
5.4 冷熱集羣架構
Elasticsearch 可以使用分片分配感知（shard allocation awareness）在特定硬件上分配分片。
索引密集型業務場景通常使用它在熱節點、暖節點和冷（Frozen）節點上存儲索引，
然後根據業務需要進行數據遷移（熱節點->暖節點->冷節點），以完成數據的刪除和存檔需要。
這是優化集羣性能的最經濟方法之一，在容量規劃期間，先確定每一類節點的數據規模，然後進行組合。
冷熱集羣架構推薦：
| 節點類型 | 存儲目標 | 建議磁盤類型 | 內存/磁盤比率 |
|---|---|---|---|
| 熱節點 | 搜索優化 | SSD DAS / SAN（> 200Gb / s） | 1:30 |
| 暖節點 | 存儲優化 | HDD DAS / SAN（〜100Gb / s） | 1:160 |
| 冷節點 | 歸檔優化 | 最便宜的 DAS / SAN（<100Gb / s） | 1:1000+ |
5.5 集羣節點角色劃分
Elasticsearch 節點執行一個或多個角色。通常，當集羣規模大時，每個節點分配一個具體角色很有意義。
您可以針對每個角色優化硬件，並防止節點爭奪資源。
同 2.2 章節。不再贅述。
6 小結
集羣規模和容量規劃的底層邏輯涉及到：
Elasticsearch 的基礎架構
維繫 Elasticsearch 高效運轉的計算資源（CPU、內存、磁盤、網絡）
Elasticsearch 增刪改查的業務流程及資源耗費情況
Elasticsearch 數據索引化的核心流程 基於以上四點的整合，纔有了：集羣規模和容量規劃預估方法。
評估所需資源需要執行以下步驟：
步驟1：確定集羣的節點類型；
步驟2：對於不同節點類型（熱，暖，冷），確定以下規模的最大值：
數據量
分片數量
索引吞吐量
搜索吞吐量
步驟3：合併每一類型節點所需資源大小 注意：在任何專用節點上做出決策-主節點、協調節點、機器學習節點、路由節點。
注：這是 Elastic 官方 2019 年 11 月份的視頻 內容的詳細梳理。
推薦過一遍視頻：
https://www.elastic.co/cn/webinars/elasticsearch-sizing-and-capacity-planning
微信公衆號回覆：容量規劃 下載 PPT
推薦：
重磅 | 死磕Elasticsearch方法論認知清單（2019國慶更新版）
https://elastic.blog.csdn.net/
更短時間更快習得更多幹貨！
