冷熱分離結合滾動模式工作流程如下：
步驟1：有一個用於寫入的索引別名，其指向活躍索引（熱數據）；
步驟2：另外一個用於讀取（搜索）的索引別名，指向不活躍索引（冷數據）；
步驟3：活躍索引具有和熱節點數量一樣多的分片，可以充分發揮昂貴硬件的索引寫入能力；
步驟4：當活躍索引太滿或者太老的時候，它就會滾動：新建一個索引並且索引別名自動從老索引切換到新索引；
步驟5：移動老索引到冷節點上並且縮小為一個分片，之后可以強制合並和壓縮。
0、引言
Elasticsearch上海Meetup中ebay工程師提了索引生命周期管理的概念。的確，在Demo級別的驗證階段我們數據量比較小，不太需要關注索引的生命周期，一個或幾個索引基本就能滿足需要。所以，這也會產生一種假象，認為：“Elasticsearch不就是增刪改查，毛毛雨啦”的荒誕的假象。
但是，在實戰開發的生產環境中，索引的動態模板設置、索引Mapping設置、索引分片數/副本數設置、索引創建、打開、關閉、刪除的全生命周期的管理必須高度關注，做好提前知識儲備，否則，會在開發后期出現由於數據激增暴露架構設計不合理問題，甚至引發分片/節點數據丟失、集群宕機等嚴重問題。
1、什么是Elasticsearch索引生命周期管理？
Elasticsearch索引生命周期管理指：Elasticsearch從設置、創建、打開、關閉、刪除的全生命周期過程的管理。
Elasticsearch生產環境中一般采用多索引結合基於時間、基於空間的橫向擴展的方式存儲數據，隨着數據量的增多，不用修改索引的底層架構邏輯。
2、索引生命周期管理為什么重要？
索引管理決定Elasticsearch魯棒性、高可用性。
索引管理和搜索、插入性能也密切相關。
實際場景例子：100節點的集群中某一個節點數據丟失后，GET /_cat/nodes?v 接口的返回時延時延非常大，接近5-8s。搜索、聚合的性能更不必說。
原因：節點丟失后，ES會自動復制分片到新的節點中去，但是該丟失節點的shard非常大（幾百個GB甚至上TB），集群當時的寫入壓力也非常大。這么大量級的數據拷貝和實時寫入，最終導致延時會非常大。
3、索引生命周期管理面臨的挑戰
1）索引管理需要ES專業知識和業務知識的結合。
業務數據多少結合業務場景，有突發情況。
2）涉及生產環境的操作。
3）用戶使用有突發情況。
比如：參數設置錯誤，分片數和副本數弄反了，路由設置錯誤。
4）索引操作的時候可能會失敗。
5）高可用性挑戰。
4、高可用的索引管理初探
Ebay的分享提及內部團隊開發了索引管理系統，會擇期分享，截止20180805 github還沒有開源，期待中。
索引生命周期管理的核心就是定義索引的早期階段，前面考慮充分了，后面的架構才會高效、穩定。
實際Elasticsearch5.X之后的版本已經推出：新增了一個Rollover API。Rollover API解決的是以日期作為索引名稱的索引大小不均衡的問題。
medcl介紹如下：Rollover API對於日志類的數據非常有用，一般我們按天來對索引進行分割（數據量更大還能進一步拆分），沒有Rollover之前，需要在程序里設置一個自動生成索引的模板，
相比於模板，Rollover API是更為簡潔的方式。
4.1 RollOver 的定義
當現有索引被認為太大或太舊時，滾動索引API將別名滾動到新索引。該API接受一個別名和一個條件列表。別名必須只指向一個索引。如果索引滿足指定條件，則創建一個新索引，並將別名切換到指向新索引的位置。
6.XRollover支持的三種條件是：
索引存儲的最長時間。如： "max_age": "7d",
索引支持的最大文檔數。如："max_docs": 1000,
索引最大磁盤空間大小。"max_size": "5gb"。
注意：
5.X版本不支持"max_size": "5gb"磁盤大小的方式。
分片的大小並不是一個可靠的測量標准，因為正在進行中的合並會產生大量的臨時分片大小增長，而當合並結束后這些增長會消失掉。五個主分片，每個都在合並到一個 5GB 分片的過程中，那么此時索引大小會臨時增多 25GB！而對於文檔數量來說，它的增長則是可以預測的。
4.2 RollOver的適用場景
這個特性對於存放日志數據的場景、索引非常大、索引實時導入數據的場景是極為友好的。
你也可以先在索引模板里面設置索引的setting、mapping等參數, 然后設定好_rollover 規則，剩下的es會自動幫你處理。
4.3 6.XRollOverAPI調用方式如下
方式一：基於序號的索引管理。
步驟1：創建索引（注意序號）
1PUT /logs-000001
2{
3 "aliases": {
4 "logs_write": {}
5 }
6}
步驟2：指定RollOver規則。
1POST /logs_write/_rollover
2{
3 "conditions": {
4 "max_age": "7d",
5 "max_docs": 2,
6 "max_size": "5gb"
7 }
8}
步驟3：批量插入數據。
1POST logs_write/log/_bulk
2{ "create": {"_id":1}}
3{ "text": "111"}
4{ "create": {"_id":2}}
5{ "text": "222" }
6{ "create": {"_id":3}}
7{ "text": "333"}
8{ "create": {"_id":4}}
9{ "text": "4444"}
注意啦，理論上：_id=3和_id=4的數據會滾動到logs-000002的索引，實際並沒有。
這個問題困擾我一上午。實踐驗證發現，然並卵。
步驟4：重復步驟2。
查看返回結果如下：
1{
2 "old_index": "logs-000001",
3 "new_index": "logs-000002",
4 "rolled_over": true,
5 "dry_run": false,
6 "acknowledged": true,
7 "shards_acknowledged": true,
8 "conditions": {
9 "[max_docs: 2]": true,
10 "[max_age: 7d]": false,
11 "[max_size: 5gb]": false
12 }
13}
這樣以后，后續插入的數據索引就自動變為logs-000002，logs-000003…..logs-00000N。
注意：
1）執行數據插入前要先執行_rollover API。
2）_rollover API不是一勞永逸的，需要手動執行后才能生效。
方式二：基於時間的索引管理。
步驟1：創建基於日期的索引。
1#PUT /<logs-{now/d}-1> with URI encoding:
2PUT /%3Clogs-%7Bnow%2Fd%7D-1%3E
3{
4 "aliases": {
5 "logs_write": {}
6 }
7}
URI 編碼工具：http://t.cn/RAEZiuq
輸入：<logs-{now/d}-1>
輸出：%3Clogs-%7Bnow%2Fd%7D-1%3E
步驟2：插入一條數據。
1PUT logs_write/_doc/1
2{
3 "message": "a dummy log"
4}
步驟3：指定RollOver規則。
1POST /logs_write/_rollover
2{
3 "conditions": {
4 "max_docs": "1"
5 }
6}
返回結果：
1{
2 "old_index": "logs-2018.08.05-1",
3 "new_index": "logs-2018.08.05-000002",
4 "rolled_over": true,
5 "dry_run": false,
6 "acknowledged": true,
7 "shards_acknowledged": true,
8 "conditions": {
9 "[max_docs: 1]": true
10 }
11}
注意，可能感覺到日期沒有變更困惑的問題解釋如下：
1）如果立即執行，new_index的名字就是當前的日期：logs-2018.08.05-000002。
2）如果24小時候后執行，new_index的名字就是+1天后的日期：logs-2018.08.06-000002。
5、高可用的索引管理進階
ES官網博客做了更好的詮釋：http://t.cn/RDZUBKZ
翻譯版本：http://t.cn/REFMMZM
在基礎RollOver滾動索引的基礎上，引入冷、熱數據分離。這是實際業務非常需要一種場景。
冷熱分離結合滾動模式工作流程如下：
步驟1：有一個用於寫入的索引別名，其指向活躍索引（熱數據）；
步驟2：另外一個用於讀取（搜索）的索引別名，指向不活躍索引（冷數據）；
步驟3：活躍索引具有和熱節點數量一樣多的分片，可以充分發揮昂貴硬件的索引寫入能力；
步驟4：當活躍索引太滿或者太老的時候，它就會滾動：新建一個索引並且索引別名自動從老索引切換到新索引；
步驟5：移動老索引到冷節點上並且縮小為一個分片，之后可以強制合並和壓縮。
具體實現，官方博客已經做了具體的說明。
注意：
1"routing.allocation.include.box_type": "hot",
2"routing.allocation.total_shards_per_node": 2
單節點執行上述操作會導致失敗，具體原因待進一步驗證。
6、Rollover的不足和改進
Rollover API大大簡化了基於時間的索引的管理。但是，仍然需要以一種重復的方式調用_rollover API接口，可以手動調用，也可以通過基於crontab的工具(如director)調用。
但是，如果翻轉過程是隱式的並在內部進行管理，則會簡單得多。其思想是在創建索引時(或在索引模板中相等地)在別名中指定滾動條件。
1PUT /<logs-{now/d}-1>
2{
3 "mappings": {...},
4 "aliases" : {
5 "logs-search" : {},
6 "logs-write" : {
7 "rollover" : {
8 "conditions": {
9 "max_age": "1d",
10 "max_docs": 100000
11 }
12 }
13 }
14 }
15}
github提出的改進建議如下：http://t.cn/RDZ45xt
截止：20180805這種方式沒有實現。
7、小結
Elasticsearch索引生命周期管理是件大事，無論你是開發還是運維人員，千萬不要輕視。
Rollover的出現能相對緩解分片、索引、集群的壓力，相對高效的管理索引的生命周期。
結合curator的定時刪除機制會更高效。
