當股票系統上線後，就會就它年復一年的走下去，資料量也會隨著時間累積，雖然我覺得盤後資訊一天不過二千筆資料有找，跟重輒上萬的 System log，User Log 相比其實是小量，但還是來看看 ES 是怎麼處理這方面的問題。

ILM Overview

ILM 對生命週期定義了 4 個階段：

• Hot: index　可以被更新與查詢
• Warm: index 不可被更新，但仍然可以被查詢
• Cold: index 不可被更新，但查詢率很低，查詢速度可能低於 Warm
• Delete: index 可以被移除

Index 生命週期策略可以觸發以下的 Actions:

• Rollover: 當現存的 Index 的資料量到達某個等級時（如資料大小，document 數量或是存放時限）建立一個新的 Index
• Shrink: 減少 Primary shards 的數量
• Freeze: 把 Index 變成 read-only
• Delete: 永久刪除一個 Index

ilm API

套路！玩玩看才有感覺。ILM 可以透過 Kibana 的介面進行設定，當然也有提供 API 供手動或程式化部署。我還是喜歡 API 的自由自在啊。

Explain Lifecycle API

GET /stock-history-prices-daily/_ilm/explain

其中　"managed" : false　表示目前的 Index 沒有被 ILM 管理中。

Create Policy API

ILM 只根據每個 Index 的「年紀」來進行 Phase 轉換。做個簡單的實驗，將一個 Index 在 3 分鐘後就進入 Warm 階段。首先，建立一個 Policy:

PUT _ilm/policy/test_policy
{
  "policy": {
    "phases": {
      "warm": {
        "min_age":"3m",
        "actions": {
          "readonly" : { }
        }
      }
    }
  }
}

然後再建立 Index 時，套用 Policy:

PUT /stock-history-prices-policy
{
  "settings": {
    "index.lifecycle.name": "test_policy"
  }
}

再來看看 Explain 的內容：

過了９分鐘後…

觀察發現， Policy 已經生效，而且生效並不會在 min_age 到達後立即生效，這點在文件中也有說明，是正常滴。

目前暫時還想不到在我的系統中，Policy 能帶來什麼關鍵性的好處，主要還是資料量不大。　呼～　今天倒數第 2 天了…　　明天來 Say Goodbye...