转载：https://my.oschina.net/xiaomaijiang/blog/826701

当使用ElasticSearch做大规模的时序数据分析的时候，我们建议使用基于时序的索引并且采用3种不同类型的节点组成分层架构（Master、Hot-Node、Warm-Node），也就是我们所说的"Hot-Warm"架构。

Master Nodes

我们建议使用3个独立的主节点来提供足够的弹性，为了防止脑裂的问题，你应该把discovery.zen.minimum_master_nodes setting设置为2。通过利用专门的主节点来管理集群的状态和对集群的专门管理来提高整体系统的稳定性。由于这三个节点不存数据也不参与到搜索和索引的操作，因此他们不太可能收到GC的影响。所以我们可以为比数据节点低很多的配置

Hot Nodes

这个特别的数据节点完成所有的索引操作，它们也具有最新的索引信息，因为这些数据被查询到的几率很高。由于索引是一个高CPI和IO的操作，这些服务器需要配备SSD。为了达到高可用，我们建议最少运行3个Hot nodes，剩下的就根据自己的实际需要进行调整

Warm Nodes

这种类型的节点被用于存放只读并且很少被查询的索引。由于这些索引是只读的并且不太可能被频繁的查询，Warm nodes 会把他们放到比较廉价的磁盘中而不是SSD中。同样，我们建议最少使用3个Warm节点来保证高可用。这些节点的CPU和内存通常和Hot Nodes类似，剩下的根据实际情况来考虑

ElasticSearch集群需要知道哪些是热数据节点，哪些是冷数据节点，所以我们需要给节点打一下标记

例如，你可以修改elasticsearch.yml的node.attr.box_type: hot来标记或者在启动的时候加参数也可以./bin/elasticsearch -Enode.attr.box_type=hot

冷数据的启动方式和热数据节点启动方式一样，修改配置文件的node.attr.box_type: warm或者./bin/elasticsearch -Enode.attr.box_type=warm

box_type这个属性的值是可以自己定义的，这个值用于告诉ES究竟要把数据分配到哪个索引

我们能够通过下面的配置来保证今天的数据都在热数据节点上

PUT /logs_2016-12-26{  "settings": {    "index.routing.allocation.require.box_type": "hot"  }}

几天后，如果这个索引不再经常被用到，我们可以把他移动到冷数据节点上

PUT /logs_2016-12-26/_settings {   "settings": {     "index.routing.allocation.require.box_type": "warm"  } }

当我们使用LogStash的时候，我们可以在创建索引的时候指定

{  "template" : "indexname-*",  "version" : 50001,  "settings" : {             "index.routing.allocation.require.box_type": "hot" ...

另外一种做法是设置通用模板

{  "template" : "*",  "version" : 50001,  "settings" : {           "index.routing.allocation.require.box_type": "hot" ...

当你判断一个索引不会被写入并且也不会被频繁的查询，你可以把它从热数据节点迁移到冷数据节点，所有的动作都会在修改索引的配置后由ES自动完成

最后，我们可以在冷数据节点上设置index.codec: best_compression来启用更好的压缩算法。当数据迁移到冷数据节点的时候，我们可以调用_forcemergeAPI进行段合并。这样做既节省内存，也节省磁盘和系统的文件打开数（因为段更少了），但是也会因为重新修改索引的压缩模式带来一些副作用

在索引还在热节点的时候进行强制合并操作不是一个好的实践，因为进程会非常的忙，一边要处理合并一边还要索引数据，会对索引的速度造成影响。但是在冷数据节点就没太大的问题

接下来我们来看看怎么使用Curator让这个过程自动化

在这个例子中，我们使用curator 4.2 来进行冷热数据的切换

actions:  1:    action: allocation    description: "Apply shard allocation filtering rules to the specified indices"    options:      key: box_type      value: warm      allocation_type: require      wait_for_completion: true      timeout_override:      continue_if_exception: false      disable_action: false    filters:    - filtertype: pattern      kind: prefix      value: logstash-    - filtertype: age      source: name      direction: older      timestring: ‘%Y.%m.%d‘      unit: days      unit_count: 3

最后我们使用它来强制索引合并，这个过程会有点久。你可以在上面的配置中设置wait_for_completion或者修改unit_count来选择大于4天的索引，等索引迁移完后再进行强制合并的操作

2:    action: forcemerge    description: "Perform a forceMerge on selected indices to ‘max_num_segments‘ per shard"    options:      max_num_segments: 1      delay:      timeout_override: 21600       continue_if_exception: false      disable_action: false    filters:    - filtertype: pattern      kind: prefix      value: logstash-    - filtertype: age      source: name      direction: older      timestring: ‘%Y.%m.%d‘      unit: days      unit_count: 3

记得要调整timeout_override的值，默认是21600秒

从ES5.0开始，我们可以使用Rollover和shirking api来处理shards，来完成一个更加简单易用的时间序列索引

ElasticSearch5.X的冷热数据架构