ElasticSearch—冷热(hot&warm)架构部署

最新推荐文章于 2025-03-10 11:08:09 发布

积极流年

最新推荐文章于 2025-03-10 11:08:09 发布

阅读量3.2k

点赞数

分类专栏： ElasticSearch

本文链接：https://blog.csdn.net/lanlianhua_luffy/article/details/110678077

版权

本文介绍了ElasticSearch的冷热架构，旨在解决海量数据存储和检索的成本问题。热节点处理新输入数据，提供快速检索，而冷节点用于存储历史数据。文章详细阐述了冷热架构的官方解读、典型应用场景、实现原理和具体实施方案，包括数据迁移策略。此外，还提到了应用冷热架构时如何进行查询操作和资源充分利用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景

最近在做订单数据存储到ElasticSearch，考虑到数据量比较大，采用冷热架构来存储，每月建立一个新索引，数据先写入到热索引，通过工具将3个月后的索引自动迁移到冷节点上。

ElasticSearch版本：6.2.4

冷热架构

官方叫法：热暖架构——“Hot-Warm” Architecture。

通俗解读：热节点存放用户最关心的热数据；温节点或者冷节点存放用户不太关心或者关心优先级低的冷数据或者暖数据。

1.1 官方解读冷热架构

为了保证Elasticsearch的读写性能，官方建议磁盘使用SSD固态硬盘。然而Elasticsearch要解决的是海量数据的存储和检索问题，海量的数据就意味需要大量的存储空间，如果都使用SSD固态硬盘成本将成为一个很大的问题，这也是制约许多企业和个人使用Elasticsearch的因素之一。为了解决这个问题，Elasticsearch冷热分离架构应运而生。

冷热架构是一项十分强大的功能，能够让您将 Elasticsearch 部署划分为“热”数据节点和“冷”数据节点。

热数据节点处理所有新输入的数据，并且存储速度也较快，以便确保快速地采集和检索数据。
冷节点的存储密度则较大，如需在较长保留期限内保留日志数据，不失为一种具有成本效益的方法。

将这两种类型的数据节点结合到一起后，您便能够有效地处理输入数据，并将其用于查询，同时还能在节省成本的前提下在较长时间内保留数据。此架构对日志用例来说尤其大有帮助，因为在日志用例中，人们的大部分精力都会专注于近期的日志（例如最近两周），而较早的日志（由于合规性或者其他原因仍需要保留）则可以接受较慢的查询时间。

1.2 典型应用场景

一句话：在成本有限的前提下，让客户关注的实时数据和历史数据硬件隔离，最大化解决客户反应的响应时间慢的问题。业务场景描述：
每日增量6TB日志数据，高峰时段写入及查询频率都较高，集群压力较大，查询ES时，常出现查询缓慢问题。

- ES集群的索引写入及查询速度主要依赖于磁盘的IO速度，冷热数据分离的关键为使用SSD磁盘存储热数据，提升查询效率。
- 若全部使用SSD，成本过高，且存放冷数据较为浪费，因而使用普通SATA磁盘与SSD磁盘混搭，可做到资源充分利用，性能大幅提升的目标。

实现原理

借助 Elasticsearch的分片分配策略，确切的说是：

第一：集群节点层面支持规划节点类型，这是划分热暖节点的前提。

具体方式是在elasticsearch.yml文件中增加以下配置：

node.attr.{attribute}: {value}

其中attribute为用户自定义的任意标签名，value为该节点对应的该标签的值，例如对于冷热分离，可以使用如下设置

node.attr.temperature: hot //热节点
node.attr.temperature: cold //冷节点

第二：索引层面支持将数据路由到给定节点，这为数据写入冷、热节点做了保障。

具体方式是在创建模板或索引时指定属性：

index.routing.allocation.include.{attribute} 　　//表示索引可以分配在包含多个值中其中一个的节点上。
index.routing.allocation.require.{attribute}　　 //表示索引要分配在包含索引指定值的节点上（通常一般设置一个值）。
index.routing.allocation.exclude.{attribute}　　 //表示索引只能分配在不包含所有指定值的节点上。