喬叔的 Elastic Stack 專業教育訓練
  • 喬叔的 Elastic Stack 專業教育訓練
  • 🧑關於喬叔 (Joe Wu)
  • Elastic 課程公開班
    • 🎯Elasticsearch 基礎實務班
      • 💯學員課後回饋
    • 🆕Elasticsearch 進階運維班
      • 💯學員課後回饋
    • Elasticsearch 進階開發班
    • Elastic Stack 基礎實務班
    • Elastic Observability 基礎實務班
    • 📩課程許願池
  • 技術分享
    • 📗喬叔帶你上手 Elastic Stack
      • 前言
      • Elastic Cloud 如何建立 Deployment
        • ES Node 的種類
        • 配置的選擇
      • Index 建立前你該知道的
        • ES Index 如何被建立
        • ES 的超前佈署 - Dynamic Mapping
        • ES 的超前佈署 - Index Template
        • ES Index 的別名 (Alias)
        • 管理你的 Index - Kibana Index
      • 管理 Index 的 Best Practices
        • Shard 的數量與 Rollover & Shrink API
        • 三溫暖架構 - Hot Warm Cold Architecture
        • Index Lifecycle Management (ILM)
        • Rollup
        • Transform
        • Snapshot Lifecycle Management (SLM)
        • 總結
      • Elastic Cloud 比免費版還多的功能
        • Elastic Stack 的方案比較與銷售方式
        • Centralized Beats Management
        • Centralized Pipeline Management
        • Watcher
        • Elasticsearch Token Service
        • Multi-stack monitoring & Automatic stack issue alerts
      • 向 App Search 學習怎麼用 Elasticsearch
        • 揭開 App Search 的面紗
        • Engine 的 Index Settings 篇
        • Engine 的 Mapping 篇
        • Engine 的 Search 基礎剖析篇
        • Engine 的 Search 進階剖析篇
      • Elasticsearch 的優化技巧
        • Indexing 索引效能優化
        • Searching 搜尋效能優化
        • Index 的儲存空間最佳化
        • Shard 的最佳化管理
      • 完賽心得
    • 📘喬叔帶你上手 Elastic Stack - 探索與實踐 Observability 系列
      • 前言 & 淺談 Observability
      • Elastic 的 Observability 解決方案
      • Uptime - 掌握系統的生命徵象
        • 我們要觀測的生命徵象是什麼?
        • 使用 Heartbeat 收集系統生命徵象數據
        • 透過 Kibana 觀看心電圖及設定警報
        • 使用合成監控 (Synthetics Monitor) 從使用者情境驗證服務的運作狀態
      • Metrics - 觀察系統的健康指標
        • Metrics 與 Metricbeat 的基本介紹
        • 使用 Metricbeat 掌握 Elastic Stack 的健康狀態
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 Host 篇
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 Docker 篇
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 Kubernetes 篇
        • 使用 Metricbeat 掌握 Infrastructure 的健康狀態 AWS 篇
      • Logs - 挖掘系統內部發生的狀況
        • Logs 與 Filebeat 的基本介紹
        • 使用 Filebeat 應該要了解的設計細節與原理
        • 透過 Filebeat 收集 Elastic Stack 中各種服務的細節資訊
        • 透過 Filebeat 收集 Infrastructure 中各種服務的細節資訊
      • Traces - 觀察應用程式的效能瓶頸
        • Elastic APM 基本介紹
        • 使用 APM-Integratoin-Testing 建立 Elastic APM 的模擬環境
        • 如何在 Kibana 使用 APM UI
        • 使用 APM Server 來收集 APM 數據
        • 透過 APM Agents 收集並傳送後端服務運作的記錄
        • 透過真實使用者監控 (RUM, Real User Monitoring) 來改善使用者體驗
      • 建立結構化的 Log
        • Elastic Common Schema 結構化 Log 的規範
        • Elasticsearch Ingest Pipeline 資料 Index 前的轉換好幫手
          • 基本介紹
          • 各種常用的 Processor
          • Enrich 資料與例外處理
      • 有效的使用 Observability 的資料
        • 透過 Machine Learning 發現異常的問題
        • 使用 Kibana Alerts 主動通知異常狀況
        • 資料的生命週期管理
        • 使用 Elastic Observability 追縱及觀察問題的心得
      • 完賽心得
    • 😀Elasticsearch 技術分享小品
      • 🤖Elastic 與 AI
        • Elasticsearch Inference API 讓我們直接在 ES 裡運用 OpenAI Completion API
    • 🎥線上分享
      • 喬叔 Elasticsearch Index 管理與效能優化技巧
      • Elastic Certification 認證經驗分享
    • 🛠️workshop
      • 如何在 Elasticsearch 實現敏捷的資料建模與管理 @ DevOpsDays 2023
        • 工作坊實作內容
      • Elastic Observability 實作體驗坊 @ DevOpsDays 2022
        • 行前準備
        • 工作坊實作內容
      • 當 Elasticsearch 搜尋引擎遇上 AI @ HelloWordDevConference 2024
        • 投影片
        • Elasticsearch 環境準備
        • Google Colab 環境準備
        • 工作坊操作說明
        • ElasticSearch Relevance Engine (ESRE)
    • ⬆️Elastic Stack 版本升級記錄
      • 🔍Elasticsearch
  • 其他專業服務
    • 👩‍🎓企業包班 | 企業內訓
    • 👨‍💼顧問服務
    • 🈺專案合作
    • 🧩Elastic 授權代理
  • 相關連結
    • Facebook 粉絲頁
Powered by GitBook
On this page
  • 前言
  • 進入此章節的先備知識
  • 此章節的重點學習
  • 冷熱資料管理的基本觀念
  • Elastic Cloud Deployment 的入口
  • Hot-Warm-Cold Architecture
  • Hot Warm Cold 的資源使用狀況
  • Freeze Indices
  • Freeze API
  • 搜尋被 Freeze 的 Index
  • 在 Kibana 搜尋到 Freezed Index 裡的資料
  • 參考資料
  1. 技術分享
  2. 喬叔帶你上手 Elastic Stack
  3. 管理 Index 的 Best Practices

三溫暖架構 - Hot Warm Cold Architecture

PreviousShard 的數量與 Rollover & Shrink APINextIndex Lifecycle Management (ILM)

Last updated 2 years ago

前言

前一天介紹了 Index 中 Shard 數量對效能的影響以及透過 Rollover 及 Shrink API 來管理 time-based 資料的方法,接下來要介紹 Elastic Stack 6.3 時陸續開始所推出針對這些隨時間增長的資料更全面的整體管理解決方案。

進入此章節的先備知識

  • Elasticsearch Index, Shard, Segment File 的基本認識。

  • Index Template。

  • Rollover 與 Shrink 的機制。

此章節的重點學習

  • Elasticsearch 中的 hot-warm-cold architecture。

  • Elasticsearch Freeze API。


冷熱資料管理的基本觀念

針對 time-based 的資料,Elasticsearch 在 5.x 版的時候,就提出了 Hot-Warm 的架構,主要是針對 常用的資料 與 時間較久也就是不常用的資料 分開用不同的硬體來存放,以達到資源有效的利用,不過從 Elastic Stack 6.3 開始,陸續在接連的幾個版本中,針對 time-based 資料的管理機制,提供了更全面的解決方案,就像是以下的拼圖,拼湊得更加完整了,從這篇開始,我們會陸續的做相關的介紹。

hot-warm-features-frozen-indices-transp.png

Elastic Cloud Deployment 的入口

當你要建立 Hot-Warm Architecture 時,若是使用 Elastic Cloud,在 Deployment 的階段就有這個配置可以選擇,但是明眼的一看,他只有 Hot-Warm 並沒有 Cold,這是因為實際上機器的配置,並沒有特別針對 Cold 的配置來安排機器,至少這是目前在 Elastic Cloud 上還沒看到的。

若是進入到 Customize deployment 後,可以看到實際的配置,是只有 Hot 與 Warm ,沒有 Cold 的配置。

Hot-Warm-Cold Architecture

這邊提到了 Hot Warm Cold 三種狀態,可想而知,就是除了分出 Hot Warm 之外,還要更細分出 Cold 的存放方式,所以使用上的資料管理順序,也就如下圖所示,新進來的資料就是會配置到 Hot Data Node,再來一段時間後,進入 Warm Data Node,再過一段時間後,最後進入 Code Data Node。

而這三種的定義與差異如下:

  • Hot: 因為負責最新的資料,所以會負責處理 indexing 的資料,同時新的資料被使用的機率也最高,所以也會處理頻繁的 searching 請求。

  • Warm: 當一份 Index 的資料成長到一定的量、或是已經過了一段時間,會將這份資料轉到 Warm data node,這時 Warn data node 是 read-only 也就是不會需要處理 indexing 的請求,只會專注在處理 searching 的請求。

  • Cold: 當一份 Index 的資料經過一段較長的時間,判定會較少使用到時,會將他移到 Cold data node,並且針對這些資料進行 Freeze 的處理 (下面會介紹),這時資料會被以最節省系統資源的狀態下被保存,還是可以提供查詢,但速度會較慢。

Hot Warm Cold 的資源使用狀況

從上圖可以看到,在這種架構下,各自針對 JVM heap 的使用狀況:

  • Hot Node 因為會處理 Indexing 的請求,所以 JVM heap 會有一定比例拿來處理 Indexing。

  • Warm Node 不處理 Indexing 所以只會有一半 JVM heap 拿來處理 query request,剩下的會來給 Lucene 用作暫存。

  • Cold Node 不會處理 Indexing,而且針對 query request 所產生的 transient cache 也會一用完就盡快的釋放,減少 heap 的使用。

Freeze Indices

沒錯,所謂的 code data 就是被 freeze 的 indices。

這邊解釋一下 Elasticsearch 為什麼要特別建立這個 Freeze 的機制。

一般的 Index,隨著搜尋的用法等不同,JVM heap需要的大小與 Index 存放的資料量比例,大約是 1:8 ~1:100 不等,因此這會限制了某個 Index 能存放的資料量的大小。

但是我們在較少用的舊資料上,我們希望能有更有效的資源使用,也就是一個同樣記憶體大小的 Node 能存放更多的資料、也願意犧牲一些查詢時的反應速度,因此 Elasticsearch 就設計的這個 Freeze 的機制,讓被 Freeze 的 Index 能盡量減少 heap 的使用。

Freeze API

要把一個 Index freeze 或 unfreeze 使用的方式如下:

POST /my_index/_freeze
POST /my_index/_unfreeze

目前 Freeze Index 時,Elasticsearch 會在背後將 Index close 再重新打開,所以 cluster 的狀態會短暫進入 紅燈 直到 index 重新打開時,primary shard 被重新載入。

要注意的另一件事是,freezed Index 是 read-only ,也就是連 Segment file 的 _forcemerge 都不能操作,所以要 Freeze 之前,較好的 practice 是先記得將 Index 進行 segment file 的 force merge。

POST /sampledata/_forcemerge?max_num_segments=1

搜尋被 Freeze 的 Index

為了避免 Freezed index 在無意識的情況下被存取到, Freezed Index 是會被指定為 throttled 的,也就是預設 Elasticsearch 的搜尋,是不會查到 Freezed index 的資料,若是要查詢包含 Freezed index 裡的資料,需要在搜尋時帶上 ignore_throttled=false 的參數。

GET /sampledata/_search?ignore_throttled=false
{
 "query": {
   "match": {
     "name": "jane"
   }
 }
}

在 Kibana 搜尋到 Freezed Index 裡的資料

若是在 Kibana 裡,想要搜尋 Freezed Index 的資料的話,需要從以下的地方進入:

左滿 Menu 選單底下的 Stack Management > 找到 Kibana 區塊裡的 Advanced Settings > 找到 Search 區塊裡的 Search in frozen indices 並設定成 On。

以上是 Hot-Warm-Cold Architecture 的介紹及原理,下一篇將會介紹如何透過 Index Lifecycle Management 來達到輕鬆設定、並直接利用 Rollover, Shrink, Hot-Warm-Cold Architecture 的機制來有效的管理我們的 Indices。

參考資料

Elastic Cloud Hot-warm architecture
elastic cloud hot-warm architecture 2
hot-warm-cold architecture
hot-warm-cold architecture heap usage
kibana search in frozen indices

📗
官方文件 - Index Lifecycle Management
官方 Blog - Creating frozen indices with the Elasticsearch Freeze index API
Efficiency in Elasticsearch