對Elasticsearch生命週期的思考

什麼是es索引的生命週期？有啥用？能夠怎麼用？用了有什麼好處呢？

在現實的生產環境中有沒有以爲本身剛開始設計的索引的分片數剛恰好，可是隨着時間的增加，數據量增大，增加速度增大的狀況下，你的es索引的設計是否還合理呢？

在現實的生產存儲中，有沒有一些數據時間長了就沒價值了，不必浪費存儲了，就能夠刪除了，有些數據變得再也不重要了，能夠存放在低性能的磁盤上，節約公司的機器硬件成本呢？

es生產環境，有沒有經歷過經過人工去管理索引的中部分數據的刪除呢，知道es刪除數據原理的都知道，這樣對性能有很大的影響，剛開始並無真正的刪除數據。

這篇文章純屬於我的經過別人的博客和官網的學習，結合本身公司業務場景的一個思考，有些是沒有實際驗證的。本篇也是基於elasticsearch7.8.1的一個版本的知識點。

1、引起思考的背景

一、首先業務場景，es的業務場景是真的普遍，目前咱們只是用來作搜索查詢，雖然如今在研究elk，對日誌的進行索引，可是肯能還只是用到es的一點點的功能

二、在es安裝的時候，如何設計節點，如何根據現有的機器作es的集羣，配置好集羣后，怎麼設計索引，通常都會有一個時間的字段，根據數據量的大小和增加速度能夠根據天，月，年等時間間隔切分索引，使用別名管理，那麼多索引，可是又如何去管理這些索引呢，還要根據本身公司的業務場景，而不是純粹的設計理論，我覺的符合公司狀況，符合業務場景的設計纔是最好的設計吧，可是不是一味的強耦合的只考慮單個業務，應該考慮多個，可以作到模板化，這樣就能很好的作擴展了，以及要考慮對將來的規劃和數據增加的容忍度吧

三、固然咱們目前沒有巨量的數據，可是不少事情也必須考慮進去，根據公司業務，好比數據只有一年的常用，後面的數據基本不用，三年前的數據能夠刪除，機器設備性能，有些機器磁盤性能好ssd，有些通常吧機械硬盤，還有cpu，內存的因素都要考慮。

四、公司管理人員少，怎麼去管理這些呢，也沒這個精力去開發索引的管理界面，不少因素都要考慮進去

2、冷熱架構

冷熱架構就是有冷的有熱的（這是玩笑話），就是常常須要使用（熱）和不常用的數據（冷），有了這樣的卻別，存儲方面確定也要區別對待吧，把熱數據存放在性能好的機器上，把冷的數據存放在性能較差的機器上，這個就是所謂的合理利用資源，節約公司硬件成本，也就是在硬件成本必定的條件下，提高集羣的性能。可是描述是這麼描述了，怎麼實現熱數據就存在好的機器上，冷數據就存在差點的機器上呢，能夠映射呀，打標籤呀，方法不少嘛，es就是打標籤。----如上描述都是我的理解（這裏只說我的的）

好，接下來就給每一個es集羣的節點打標籤咯，說A集羣性能好，用來存熱數據，說B機器性能差一些，用來存冷數據，在他們每一個機器上掛個牌牌，方便數據根據本身的冷熱程度對號入座。es是這麼打標籤的：

在elasticsearch.yml文件中增長

node.attr.{attribute}: {value}

好比能夠給機器配置冷熱的標籤：

node.attr.temperature: hot //熱節點
node.attr.temperature: warm //冷節點

如今是機器的標籤打好了，那索引數據怎麼打標籤，而且一一對應呢？就是對索引有以下的設置（_settings）就能夠對應好啦：

index.routing.allocation.include.{attribute} 　　//表示索引能夠分配在包含多個值中其中一個的節點上。
index.routing.allocation.require.{attribute}　　 //表示索引要分配在包含索引指定值的節點上（一般通常設置一個值）。
index.routing.allocation.exclude.{attribute}　　 //表示索引只能分配在不包含全部指定值的節點上。

詳細的部署這裏不說了，大概只聊聊思想，部署能夠參考下其餘博主的博客：

https://www.elastic.co/guide/en/elasticsearch/reference/7.8/shard-allocation-filtering.html  

https://zhuanlan.zhihu.com/p/97098781

http://www.javashuo.com/article/p-bkjvpufa-hx.html

3、生命週期

聊了背景，說了冷熱架構，那咱們怎麼怎麼自動的管理呢？這樣生命週期就派上用處了，好比一個索引的數據通過10天就從熱數據轉爲了冷數據，這樣能夠經過一系列的action和設置進行操做，自動根據時間把冷數據轉移到性能較差的機器上。這樣豈不是很方便，接下來咱們就瞭解下索引的生命週期，以及怎麼使用。

二話不說，上官網：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/index-lifecycle-management.html

能夠配置索引生命週期管理(ILM)策略，以根據您的性能、彈性和保留需求自動管理索引。好比當索引達到必定大小或文檔數量時，旋轉新索引，天天、每週或每個月建立一個新索引，並歸檔之前的索引，刪除過期的索引以執行數據保留標準。能夠經過API配置和kibana配置進行生命週期的管理。

ES索引生命週期管理分爲4個階段：hot、warm、cold、delete，其中hot主要負責對索引進行rollover操做，warm、cold、delete分別對rollover後的數據進一步處理（前提是配置了hot）

階段	描述
hot	主要處理時序數據的實時寫入
warm	索引再也不被更新，但仍在被查詢
cold	索引再也不被更新，而且不多被查詢。這些信息仍然須要可搜索
delete	索引再也不須要，能夠安全地刪除

那這些索引是根據什麼條件去從一個階段轉到另外一個階段的呢？好比能夠根據時間呀，文檔數據呀，索引大小呀做爲判斷條件轉到下一個階段。

一、當索引達到50GB時，將鼠標移至新索引。
二、將舊索引移至熱階段，將其標記爲只讀，而後將其縮小爲單個碎片。
三、7天后，將索引移至冷階段，而後將其移至較便宜的硬件上。
四、達到所需的30天保留期後，刪除索引

那咱們在索引的每個階段能夠作什麼樣的操做呢，好比增長索引的設置，修改副本數量等。

階段	操做（action）
Hot	Set Priority，Unfollow，Rollover
Warm	Set Priority，Unfollow，Read-Only，Allocate，Shrink，Force Merge
Cold	Set Priority，Unfollow，Allocate，Freeze
Delete	Wait For Snapshot，Delete

具體如上的每個動做（action）是什麼，你們參考官網https://www.elastic.co/guide/en/elasticsearch/reference/7.8/ilm-actions.html

咱們知道索引生命的週期的階段，也知道根據什麼條件從一個週期跳轉到另外一個階段，也知道在每個階段能夠作什麼操做了，那麼就成了呀，更具本身的業務場景設計索引的生命週期吧！！！接下來就看看什麼實用呢？

來，官網：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/set-up-lifecycle-policy.html

https://www.elastic.co/guide/en/elasticsearch/reference/7.8/getting-started-index-lifecycle-management.html

經過索引生命週期策略管理索引的基本步驟以下：
1. 建立定義適當階段和操做的生命週期策略
2. 建立索引模板，將策略應用於每一個新索引
3. 引導一個索引做爲初始寫索引
4. 驗證索引按預期在生命週期階段中移動

如上四個步驟根據官網來一步一步操做很簡單，若是要結合冷熱架構的話，能夠在某一個階段根據本身的需求經過索引的設置（_settings）指定打好標籤機器的標籤就行了

固然索引的生命週期還能夠經過kibana進行配置：

 

 根據圖一步一步的操做很簡單的！

生命週期管理策略真的是一個很好管理索引的技術，很靈活，可以減小人工的介入。均可以根據公司的業務場景好好使用，本文的冷熱架構這裏沒有實踐過，可是索引的生命週期仍是實踐過，挺好用的，特別是一些日誌數據，保留7天或者一個月就夠了，能夠經過生命週期策略配置自動刪除知足條件的數據，這樣集羣的數據也不會無限的增加，也不須要人工管理。

願每個努力的人都積極思考，而不是知識的搬運工