[Day29] Index Lifecycle Management 简介

当股票系统上线後，就会就它年复一年的走下去，资料量也会随着时间累积，虽然我觉得盘後资讯一天不过二千笔资料有找，跟重辄上万的 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...