ES （elasticsearch）集群数据冷热分离实现

导语

这种打标签的 *** 作可以通过滚动，重启集群实例，因为涉及到重启后的数据恢复问题，可能滚动重启的时间会比较长（根据数据量大小和分片数量决定），可以通过如下的方式，增加数据恢复的最大并行度和数据恢复的最大带宽进行调整，逐步调大到不影响集群业务性能为止。

1、ES 集群异构，机器硬件资源配置不一，有高性能 CPU 和 SSD 存储集群，也有大容量的机械磁盘集群，比如我们的场景就是存放冷数据的集群，服务器都是多年前买的一批满配的 4T Dell R70，但是新扩容的热节点机器均为 DELL 高性能 SSD 磁盘和 CPU 的 R740 机器。

2、对于时间型数据来说，一般是当前的数据，写入和查询较为集中，所以高性能的资源应该优先提供给这些数据使用。

3、集群的搜索和写入性能，取决于最慢节点的性能。

1、ES 的索引已经按照天或者月的时间维度生成索引。

2、 历史 数据相对于近期数据来说没有高频度的查询需求。

本文实现策略：最新的天和月索引均为热数据，其他索引根据查询周期不同，调整为冷数据。当然业务不同策略不同，具体实现策略还是需要根据实际的业务场景来决定。

前置条件

需要修改 ES 集群配置文件，对节点进行打标签 *** 作，配置如下：

热数据实例：

冷数据实例：

修改集群配置需要进行重启实例生效

这种打标签的 *** 作可以通过滚动，重启集群实例，因为涉及到重启后的数据恢复问题，可能滚动重启的时间会比较长（根据数据量大小和分片数量决定），可以通过如下的方式，增加数据恢复的最大并行度和数据恢复的最大带宽进行调整，逐步调大到不影响集群业务性能为止。

设置数据恢复的最大并行度

设置数据恢复的最大带宽

新增索引实现冷热数据分离

集群滚动重启完成之后，已经具备了冷热数据分离的条件，那么如何让新增索引自动成为热数据呢？

答案就是修改 ES 索引的模板，为 ES 索引打 tag，配置实例如下：

只要在索引模板中打了热标签的索引，就会在创建的时候自动分布在集群中实例打了热标签的节点上。

历史 索引实现冷热数据迁移

那么 历史 的 ES 数据如何让其从热节点迁移到冷节点呢？

答案就是，通过 api 修改 ES 索引的标签，将其变更为冷标签，这样 ES 索引就会自动迁移到集群中打了冷标签的实例上，配置如下：

实际生产中会将制定好的冷热数据规则编写成脚本，放到计划任务中，来定时定点的运行，达到热数据自动迁移为冷数据的目的。

熟悉 ES 的同学知道，JVM heap 分配不能超过 32GB，对于使用物理机部署 ES 的环境来说，一台机器的内存往往就动辄 192G 或者 256G，如果只跑一个 ES 实例，只能利用到 32G 的 heap，而且还无法充分发挥 CPU 和 IO 资源，这样显然是不经济的。

因为我们常常会部署单机多实例的 ES 节点，在多实例配置中除了要隔离日志和数据目录之外，还需要增加以下两个配置，不然一台物理机宕机，可能会因为多个副本存在一个 ES 物理机上面导致业务受到影响。

# 执行检查以防止基于主机名和主机地址在单个主机上分配同一分片的多个实例。 默认为 false，表示默认情况下不执行检查。 此设置仅适用于在同一台计算机上启动多个节点的情况。这个我的理解是如果设置为 false，则同一个节点上多个实例可以存储同一个 shard 的多个副本没有容灾作用了。

以上就是关于ES （elasticsearch）集群数据冷热分离实现全部的内容，包括:ES （elasticsearch）集群数据冷热分离实现、、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！