轉自：http://stormluke.me/es-managing-time-based-indices-efficiently/

用 Elasticsearch 來索引諸如日志事件等基於時間的數據的人可能已經習慣了“每日一索引”模式：使用以天為粒度的索引名字來存放當天的日志數據，一天過去后再建一個新索引。新索引的屬性可以由索引模板來提前控制。

這種模式很容易理解並且易於實現，但是它粉飾了索引管理的一些復雜的地方：

  • 為了達到較高的寫入速度，活躍索引分片需要分布在盡可能多的節點上。
  • 為了提高搜索速度和降低資源消耗，分片數量需要盡可能地少，但是也不能有過大的單個分片進而不便操作
  • 一天一個索引確實易於清理陳舊數據，但是一天到底需要多少個分片呢？
  • 每天的寫入壓力是一成不變的嗎？還是一天分片過多，而下一天分片不夠用呢？

在這篇文章中我將介紹新的”滾動模式“和用來實現它的 API 們，這個模式可以更加簡單且高效地管理基於時間的索引。

滾動模式

滾動模式工作流程如下：

  • 有一個用於寫入的索引別名，其指向活躍索引
  • 另外一個用於讀取（搜索）的索引別名，指向不活躍索引
  • 活躍索引具有和熱節點數量一樣多的分片，可以充分發揮昂貴硬件的索引寫入能力
  • 當活躍索引太滿或者太老的時候，它就會滾動：新建一個索引並且索引別名自動從老索引切換到新索引
  • 移動老索引到冷節點上並且縮小為一個分片，之后可以強制合並和壓縮。

入門

假設我們有一個具有 10 個熱節點和一個冷節點池的集群。理想情況下我們的活躍索引（接收所有寫入的索引）應該在每個熱節點上均勻分布一個分片，以此來盡可能地在多個機器上分散寫入壓力。

我們讓每個主分片都有一個復制分片來允許一個節點失效而不丟失數據。這意味着我們的活躍索引應該有 5 個主分片，加起來一共 10 個分片（每個節點一個）。我們也可以用 10 個主分片（包含冗余一共 20 個分片），這樣每個節點兩個分片。

首先，為活躍索引創建一個索引模版：

PUT _template/active-logs
{
"template": "active-logs-*",
"settings": {
"number_of_shards": 5,
"number_of_replicas": 1,
"routing.allocation.include.box_type": "hot",
"routing.allocation.total_shards_per_node": 2
},
"aliases": {
"active-logs": {},
"search-logs": {}
}
}

由這個模板創建的索引會被分配到標記為 box_type:hot 的節點上，而 total_shards_per_node 配置會保證將分片均勻分布在熱節點中。我把其設置為 2 而不是 1，這樣當一個節點失效時也可以繼續分配分片。

我們將會用 active-logs 別名來寫入當前的活躍索引，用 search-logs 別名來查詢所有的日志索引。

下面是非活躍索引的模板：

PUT _template/inactive-logs
{
"template": "inactive-logs-*",
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0,
"routing.allocation.include.box_type": "cold",
"codec": "best_compression"
}
}

歸檔的索引應該被分配到冷節點上並且使用 deflate 壓縮來節約磁盤空間。我會在之后解釋為什么把 replicas 設置為 0。

現在可以創建第一個活躍索引了：

PUT active-logs-1

Rollover API 會將名字中的 -1 識別為一個計數器。

索引日志事件

。。。