ES冷热分离架构设计:一招让你的ELK日志系统节省 50% 的硬盘成本

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
Elasticsearch Serverless通用抵扣包,测试体验金 200元
简介: ES冷热分离架构设计:一招让你的ELK日志系统节省 50% 的硬盘成本

引言

首先抛出问题:对于热点搜索而言,最高效的存储手段是什么?

一味地堆硬件配置,不仅不能有效的解决问题,反而会让服务变得臃肿,集群变得累赘增加管理成本和硬件成本。

本文主要探讨关于热点数据的高效存储问题,讨论范围在数据持久化前提下,多级缓存暂不讨论。


1、冷热数据分离思想

冷热集群架构方案即我们常说的冷热数据分离。本质是针对不同访问频率的数据做分离存储,让访问量高的数据存放在性能更好的磁盘中,以实现更合理的资源分配和调度。


就实际而言,其实超过80%的请求,集中在20%的数据上,所以如果普遍采取廉价的机械磁盘存储,势必达不到良好的性能。而如果全面采用SSD做保证数据持久化存储,又会带来高昂的硬件成本,这其实完全没有必要。


这里有人提过质疑,说热数据做缓存就行了呀,费这个劲干啥?其实从原理上来说,冷热数据分离和多级缓存是非常类似的,一句话概括就是把更高频访问的数据,放在性能搞好的硬件上。但区别就是多级缓存是不考虑数据持久化的。


这种资源分层调度的思想应用其实非常广泛:

b1360649eb4d4f5ab505b086b55d5d02.png

性能越快的硬件往往空间越少,以至于其只能把最高频使用的数据放进去,如CPU的L1、L2、L3三级缓存。性能递减,容量递增。上升到整个计算机层面,CPU到内存再到磁盘,也是速度递减,容量递增。本质上讲,就是把最常用的东西放在最近的位置。


举个通俗易懂的例子:


我们睡觉的时候,都是把第二天要穿的衣服放在床边,床边是最方便的,但是床边就只能放这么一套衣服,放不了太多。

如果向要换衣服,就要去衣柜里找,衣柜的空间更大,但是衣柜离我们更远,拿取衣服就需要翻箱倒柜(寻址)

衣柜里也没你想要的衣服了,那你就要去商场里购买,商场里有足够多的衣服让你选,但是商场很远,你需要更多的时间来选衣服、把衣服运送过来。

这个例子可以看成是一个多级缓存的例子,在这里例子里,床边让你放衣服的椅子拿衣服是最快的,你可以看成是你的顶级缓存或一级缓存;衣柜可以看成是你的二级缓存,容量大一些,速度慢一些;而商场就是三级缓存,容量更大,速度更慢。如果把这个过程看成是计算机的CPU、内存到磁盘的过程。那么在商场中选购衣服可以看成是在磁盘中查找数据。选衣服的过程就是磁盘寻址,而把衣服拿回家,就是磁盘IO。


同样这个例子也可以是冷热数据分离的一个比喻,此时我们可以把数据划分为热数据、温数据、冷数据三个阶段。那么可以做如下类比:


床边放衣服的椅子 => 热数据

衣柜 => 温数据

商场 => 冷数据


2、数据层:Data tiers

在 Elasticsearch 中,不同热度的数据,通过 Data tiers 来界定。数据层是具有相同数据角色的节点的集合,通常共享相同的硬件配置文件。根据不同的热度,ES 把数据层定义为四个阶段:

hot tier:处理时间序列数据(例如日志或指标)的索引负载,并保存您最近、最常访问的数据。

warm tier:保存访问频率较低且很少需要更新的时间序列数据。

cold tier:保存不经常访问且通常不更新的时间序列数据。

frozen tier:保存很少访问且从不更新的时间序列数据,保存在可搜索的快照中。

另外还有一个特殊的内容层:


content tier:处理产品目录等内容的索引和查询负载。

当文档直接索引到特定 index 时,会永久保留在 content tier 节点上。


当文档索引到数据流时,数据最初驻留在 hot tier 节点上。


2.1 内容层:Content Tier

存储在内容层中的数据通常是项目的集合,例如产品目录或文章存档。与时间序列数据不同,内容的价值随着时间的推移保持相对恒定,因此随着时间的推移将其移动到具有不同性能特征的层是没有意义的。内容数据通常具有较长的数据保留要求,并且您希望能够快速检索项目,无论它们有多旧。


内容层节点通常针对查询性能进行优化——它们优先考虑处理能力而不是 IO 吞吐量,因此它们可以处理复杂的搜索和聚合并快速返回结果。虽然它们还负责索引,但内容数据的摄取率通常不如日志和指标等时间序列数据那么高。从弹性的角度来看,该层中的索引应配置为使用一个或多个副本。


内容层是必需的。不属于数据流的系统索引和其他索引会自动分配给内容层。


2.2 热数据层:Hot Tier

热层是时间序列数据的 Elasticsearch 入口点,保存最近、最常搜索的时间序列数据。热层中的节点需要快速读取和写入,这需要更多的硬件资源和更快的存储 (SSD)。为了弹性,热层中的索引应配置为使用一个或多个副本。

热层是必须的。作为数据流一部分的新索引会自动分配给热层。


2.3 温数据层:Warm Tier

一旦查询的频率低于热层中最近索引的数据,时间序列数据就可以移动到热层。暖层通常保存最近几周的数据。仍然允许更新,但可能不频繁。热层中的节点通常不需要像热层中的节点那样快。为了弹性,应将暖层中的索引配置为使用一个或多个副本。


2.4 冷数据层:Cold Tier

一旦数据不再被更新,它就可以从暖层移动到冷层,并在不经常被查询的情况下停留在那里。冷层仍然是响应式查询层,但冷层中的数据不会正常更新。随着数据转换到冷层,它可以被压缩和缩小。对于弹性,冷层可以使用完全安装的 可搜索快照索引,从而消除对副本的需求。


2.5 冻结层:Frozen Tier

一旦数据不再被查询或很少被查询,它可能会从冷层移动到冻结层,并在其余生中停留。


冻结层使用部分安装的索引来存储和加载来自快照存储库的数据。这降低了本地存储和运营成本,同时仍然让您搜索冻结的数据。因为 Elasticsearch 有时必须从快照存储库中获取冻结数据,所以在冻结层上的搜索通常比在冷层上慢。


3、节点角色

根绝不同的数据层,ES 制定了不同的节点角色:

  • data_content
  • data_hot
  • data_warm
  • data_cold
  • data_frozen


3.1 内容节点

内容数据节点容纳用户创建的内容。它们支持 CRUD、搜索和聚合等操作。

要创建专用内容节点,在配置文件中设置:

node.roles: [ data_content ]


3.2 热数据节点

热数据节点在进入 Elasticsearch 时存储时间序列数据。热层对于读取和写入都必须快速,并且需要更多的硬件资源(例如 SSD 驱动器)。


要创建专用热节点,配置

node.roles: [ data_hot ]


3.3 温数据节点

暖数据节点存储不再定期更新但仍在查询的索引。查询量的频率通常低于索引处于热层时的频率。此层中的节点通常可以使用性能较低的硬件。


要创建一个专用的暖节点,

node.roles: [ data_warm ]


3.4 冷数据节点

冷数据节点存储访问频率较低的只读索引。该层使用性能较低的硬件,并且可以利用可搜索的快照索引来最小化所需的资源。


要创建专用冷节点,设置

node.roles: [ data_cold ]


3.5 冻结数据节点

冻结层 专门存储部分安装的索引。我们建议您在冻结层中使用专用节点。


要创建专用的冻结节点,设置

node.roles: [ data_frozen ]


相关实践学习
通过日志服务实现云资源OSS的安全审计
本实验介绍如何通过日志服务实现云资源OSS的安全审计。
相关文章
|
2月前
|
存储 数据挖掘 BI
2-5 倍性能提升,30% 成本降低,阿里云 SelectDB 存算分离架构助力波司登集团实现降本增效
波司登集团升级大数据架构,采用阿里云数据库 SelectDB 版,实现资源隔离与弹性扩缩容,查询性能提升 2-5 倍,总体成本降低 30% 以上,效率提升 30%,助力销售旺季高效运营。
165 9
|
1月前
|
Prometheus 监控 Cloud Native
基于docker搭建监控系统&日志收集
Prometheus 是一款由 SoundCloud 开发的开源监控报警系统及时序数据库(TSDB),支持多维数据模型和灵活查询语言,适用于大规模集群监控。它通过 HTTP 拉取数据,支持服务发现、多种图表展示(如 Grafana),并可结合 Loki 实现日志聚合。本文介绍其架构、部署及与 Docker 集成的监控方案。
252 122
基于docker搭建监控系统&日志收集
WGLOG日志管理系统是怎么收集日志的
WGLOG通过部署Agent客户端采集日志,Agent持续收集指定日志文件并上报Server,Server负责展示与分析。Agent与Server需保持相同版本。官网下载地址:www.wgstart.com
|
27天前
|
消息中间件 Java Kafka
搭建ELK日志收集,保姆级教程
本文介绍了分布式日志采集的背景及ELK与Kafka的整合应用。传统多服务器环境下,日志查询效率低下,因此需要集中化日志管理。ELK(Elasticsearch、Logstash、Kibana)应运而生,但单独使用ELK在性能上存在瓶颈,故结合Kafka实现高效的日志采集与处理。文章还详细讲解了基于Docker Compose构建ELK+Kafka环境的方法、验证步骤,以及如何在Spring Boot项目中整合ELK+Kafka,并通过Logback配置实现日志的采集与展示。
271 64
搭建ELK日志收集,保姆级教程
|
4月前
|
监控 API 开发工具
HarmonyOS Next的HiLog日志系统完全指南:从入门到精通
本文深入解析HarmonyOS Next的HiLog日志系统,涵盖日志级别、核心API、隐私保护与高级回调功能,助你从入门到精通掌握这一重要开发工具。
221 1
|
21天前
|
Ubuntu
在Ubuntu系统上设置syslog日志轮替与大小限制
请注意,在修改任何系统级别配置之前,请务必备份相应得原始档案并理解每项变更可能带来得影响。
76 2
|
9月前
|
存储 运维 监控
日志服务SLS焕新升级:卓越性能、高效成本、极致稳定与智能化
日志服务SLS焕新升级,涵盖卓越性能、高效成本、极致稳定与智能化。新功能特性包括Project回收站、ELasticsearch兼容方案及全链路数据处理能力提升。通过扫描计算模式和数据加工优化,实现更好的成本效果。案例分析展示了一家国内顶级车企如何通过日志服务实现跨云、跨地域的全链路数据处理,大幅提升问题处理效率。
215 9
|
4月前
|
存储 关系型数据库 MySQL
成本直降30%!RDS MySQL存储自动分层实战:OSS冷热分离架构设计指南
在日均订单量超500万的场景下,MySQL数据年增200%,但访问集中在近7天(85%)。通过冷热数据分离,将历史数据迁移至OSS,实现存储成本下降48%,年省72万元。结合RDS、OSS与Redis构建分层架构,自动化管理数据生命周期,优化查询性能与资源利用率,支撑PB级数据扩展。
238 3
|
7月前
|
数据可视化 关系型数据库 MySQL
ELK实现nginx、mysql、http的日志可视化实验
通过本文的步骤,你可以成功配置ELK(Elasticsearch, Logstash, Kibana)来实现nginx、mysql和http日志的可视化。通过Kibana,你可以直观地查看和分析日志数据,从而更好地监控和管理系统。希望这些步骤能帮助你在实际项目中有效地利用ELK来处理日志数据。
524 90
|
3月前
|
存储
WGLOG日志管理系统可以采集网络设备的日志吗
WGLOG日志审计系统提供开放接口,支持外部获取日志内容后发送至该接口,实现日志的存储与分析。详情请访问:https://www.wgstart.com/wglog/docs9.html

热门文章

最新文章