高效管理 Elasticsearch 中基于时间的索引——本质是在利用滚动模式做数据的冷热分离，热索引可以用ssd

高效管理 Elasticsearch 中基于时间的索引

转自：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

识别为一个计数器。

索引日志事件

。。。