對Elasticsearch生命周期的思考
什麼是es索引的生命周期？有啥用？可以怎麼用？用了有什麼好處呢？
在現實的生產環境中有沒有覺得自己剛開始設計的索引的分片數剛剛好，但是隨着時間的增長，數據量增大，增長速度增大的情況下，你的es索引的設計是否還合理呢？
在現實的生產存儲中，有沒有一些數據時間長了就沒價值了，沒必要浪費存儲了，就可以刪除了，有些數據變得不再重要了，可以存放在低性能的磁盤上，節約公司的機器硬件成本呢？
es生產環境，有沒有經歷過通過人工去管理索引的中部分數據的刪除呢，知道es刪除數據原理的都知道，這樣對性能有很大的影響，剛開始並沒有真正的刪除數據。
這篇文章純屬於個人通過別人的博客和官網的學習，結合自己公司業務場景的一個思考，有些是沒有實際驗證的。本篇也是基於elasticsearch7.8.1的一個版本的知識點。
一、引發思考的背景
1、首先業務場景，es的業務場景是真的廣泛，目前我們只是用來做搜索查詢，雖然現在在研究elk，對日誌的進行索引，但是肯能還只是用到es的一點點的功能
2、在es安裝的時候，如何設計節點，如何根據現有的機器做es的集群，配置好集群後，怎麼設計索引，一般都會有一個時間的字段，根據數據量的大小和增長速度可以根據天，月，年等時間間隔切分索引，使用別名管理，那麼多索引，但是又如何去管理這些索引呢，還要根據自己公司的業務場景，而不是純粹的設計理論，我覺的符合公司情況，符合業務場景的設計才是最好的設計吧，但是不是一味的強耦合的只考慮單個業務，應該考慮多個，能夠做到模板化，這樣就能很好的做擴展了，以及要考慮對未來的規劃和數據增長的容忍度吧
3、當然我們目前沒有巨量的數據，但是很多事情也必須考慮進去，根據公司業務，比如數據只有一年的經常使用，後面的數據基本不用，三年前的數據可以刪除，機器設備性能，有些機器磁盤性能好ssd，有些一般吧機械硬盤，還有cpu，內存的因素都要考慮。
4、公司管理人員少，怎麼去管理這些呢，也沒這個精力去開發索引的管理界面，很多因素都要考慮進去
二、冷熱架構
冷熱架構就是有冷的有熱的（這是玩笑話），就是經常需要使用（熱）和不經常使用的數據（冷），有了這樣的卻別，存儲方面肯定也要區別對待吧，把熱數據存放在性能好的機器上，把冷的數據存放在性能較差的機器上，這個就是所謂的合理利用資源，節約公司硬件成本，也就是在硬件成本一定的條件下，提升集群的性能。但是描述是這麼描述了，怎麼實現熱數據就存在好的機器上，冷數據就存在差點的機器上呢，可以映射呀，打標籤呀，方法很多嘛，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} //表示索引只能分配在不包含所有指定值的節點上。
詳細的部署這裡不說了，大概只聊聊思想，部署可以參考下其他博主的博客：
//www.elastic.co/guide/en/elasticsearch/reference/7.8/shard-allocation-filtering.html
//zhuanlan.zhihu.com/p/97098781
//www.cnblogs.com/caoweixiong/p/11988457.html
三、生命周期
聊了背景，說了冷熱架構，那我們怎麼怎麼自動的管理呢？這樣生命周期就派上用處了，比如一個索引的數據經過10天就從熱數據轉為了冷數據，這樣可以通過一系列的action和設置進行操作，自動根據時間把冷數據轉移到性能較差的機器上。這樣豈不是很方便，接下來我們就了解下索引的生命周期，以及怎麼使用。
二話不說，上官網：//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 |
索引不再需要，可以安全地刪除 |
那這些索引是根據什麼條件去從一個階段轉到另一個階段的呢？比如可以根據時間呀，文檔數據呀，索引大小呀作為判斷條件轉到下一個階段。
1、當索引達到50GB時，將鼠標移至新索引。
2、將舊索引移至熱階段，將其標記為只讀，然後將其縮小為單個碎片。
3、7天後，將索引移至冷階段，然後將其移至較便宜的硬件上。
4、達到所需的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）是什麼，大家參考官網//www.elastic.co/guide/en/elasticsearch/reference/7.8/ilm-actions.html
我們知道索引生命的周期的階段，也知道根據什麼條件從一個周期跳轉到另一個階段，也知道在每一個階段可以做什麼操作了，那麼就成了呀，更具自己的業務場景設計索引的生命周期吧！！！接下來就看看什麼實用呢？
來，官網：//www.elastic.co/guide/en/elasticsearch/reference/7.8/set-up-lifecycle-policy.html
通過索引生命周期策略管理索引的基本步驟如下：
1. 創建定義適當階段和操作的生命周期策略
2. 創建索引模板，將策略應用於每個新索引
3. 引導一個索引作為初始寫索引
4. 驗證索引按預期在生命周期階段中移動
如上四個步驟根據官網來一步一步操作很簡單，如果要結合冷熱架構的話，可以在某一個階段根據自己的需求通過索引的設置（_settings）指定打好標籤機器的標籤就好了
當然索引的生命周期還可以通過kibana進行配置：
根據圖一步一步的操作很簡單的！
生命周期管理策略真的是一個很好管理索引的技術，很靈活，能夠減少人工的介入。都可以根據公司的業務場景好好使用，本文的冷熱架構這裡沒有實踐過，但是索引的生命周期還是實踐過，挺好用的，特別是一些日誌數據，保留7天或者一個月就夠了，可以通過生命周期策略配置自動刪除滿足條件的數據，這樣集群的數據也不會無限的增長，也不需要人工管理。
願每一個努力的人都積極思考，而不是知識的搬運工
