什麼是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} //表示索引只能分配在不包含所有指定值的節點上。
詳細的部署這裡不說了，大概只聊聊思想，部署可以參考下其他博主的部落格：
https://www.elastic.co/guide/en/elasticsearch/reference/7.8/shard-allocation-filtering.html
https://zhuanlan.zhihu.com/p/97098781
https://www.cnblogs.com/caoweixiong/p/11988457.html
三、生命週期
聊了背景，說了冷熱架構，那我們怎麼怎麼自動的管理呢？這樣生命週期就派上用處了，比如一個索引的資料經過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 |
索引不再需要，可以安全地刪除 |
那這些索引是根據什麼條件去從一個階段轉到另一個階段的呢？比如可以根據時間呀，文件資料呀，索引大小呀作為判斷條件轉到下一個階段。
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）是什麼，大家參考官網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
通過索引生命週期策略管理索引的基本步驟如下：
1. 建立定義適當階段和操作的生命週期策略
2. 建立索引模板，將策略應用於每個新索引
3. 引導一個索引作為初始寫索引
4. 驗證索引按預期在生命週期階段中移動
如上四個步驟根據官網來一步一步操作很簡單，如果要結合冷熱架構的話，可以在某一個階段根據自己的需求通過索引的設定（_settings）指定打好標籤機器的標籤就好了
當然索引的生命週期還可以通過kibana進行配置：
根據圖一步一步的操作很簡單的！
生命週期管理策略真的是一個很好管理索引的技術，很靈活，能夠減少人工的介入。都可以根據公司的業務場景好好使用，本文的冷熱架構這裡沒有實踐過，但是索引的生命週期還是實踐過，挺好用的，特別是一些日誌資料，保留7天或者一個月就夠了，可以通過生命週期策略配置自動刪除滿足條件的資料，這樣叢集的資料也不會無限的增長，也不需要人工管理。
願每一個努力的人都積極思考，而不是知識的搬運工