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

本文涉及的产品
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介: 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 ]


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
27天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
146 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
1天前
|
存储 安全 Java
Spring Boot 3 集成Spring AOP实现系统日志记录
本文介绍了如何在Spring Boot 3中集成Spring AOP实现系统日志记录功能。通过定义`SysLog`注解和配置相应的AOP切面,可以在方法执行前后自动记录日志信息,包括操作的开始时间、结束时间、请求参数、返回结果、异常信息等,并将这些信息保存到数据库中。此外,还使用了`ThreadLocal`变量来存储每个线程独立的日志数据,确保线程安全。文中还展示了项目实战中的部分代码片段,以及基于Spring Boot 3 + Vue 3构建的快速开发框架的简介与内置功能列表。此框架结合了当前主流技术栈,提供了用户管理、权限控制、接口文档自动生成等多项实用特性。
23 8
|
20天前
|
机器学习/深度学习 算法 数据可视化
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
本文探讨了在量化交易中结合时序特征和静态特征的混合建模方法。通过整合堆叠稀疏降噪自编码器(SSDA)和基于LSTM的自编码器(LSTM-AE),构建了一个能够全面捕捉市场动态特性的交易系统。SSDA通过降噪技术提取股票数据的鲁棒表示,LSTM-AE则专注于捕捉市场的时序依赖关系。系统采用A2C算法进行强化学习,通过多维度的奖励计算机制,实现了在可接受的风险水平下最大化收益的目标。实验结果显示,该系统在不同波动特征的股票上表现出差异化的适应能力,特别是在存在明确市场趋势的情况下,决策准确性较高。
58 5
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
|
1月前
|
机器学习/深度学习 人工智能 并行计算
【AI系统】Kernel 层架构
推理引擎的Kernel层负责执行底层数学运算,如矩阵乘法、卷积等,直接影响推理速度与效率。它与Runtime层紧密配合,通过算法优化、内存布局调整、汇编优化及调度优化等手段,实现高性能计算。Kernel层针对不同硬件(如CPU、GPU)进行特定优化,支持NEON、AVX、CUDA等技术,确保在多种平台上高效运行。
84 32
|
1月前
|
存储 机器学习/深度学习 人工智能
【AI系统】计算图优化架构
本文介绍了推理引擎转换中的图优化模块,涵盖算子融合、布局转换、算子替换及内存优化等技术,旨在提升模型推理效率。计算图优化技术通过减少计算冗余、提高计算效率和减少内存占用,显著改善模型在资源受限设备上的运行表现。文中详细探讨了离线优化模块面临的挑战及解决方案,包括结构冗余、精度冗余、算法冗余和读写冗余的处理方法。此外,文章还介绍了ONNX Runtime的图优化机制及其在实际应用中的实现,展示了如何通过图优化提高模型推理性能的具体示例。
57 4
【AI系统】计算图优化架构
|
16天前
|
机器学习/深度学习 存储 人工智能
基于AI的实时监控系统:技术架构与挑战分析
AI视频监控系统利用计算机视觉和深度学习技术,实现实时分析与智能识别,显著提升高风险场所如监狱的安全性。系统架构包括数据采集、预处理、行为分析、实时决策及数据存储层,涵盖高分辨率视频传输、图像增强、目标检测、异常行为识别等关键技术。面对算法优化、实时性和系统集成等挑战,通过数据增强、边缘计算和模块化设计等方法解决。未来,AI技术的进步将进一步提高监控系统的智能化水平和应对复杂安全挑战的能力。
|
21天前
|
机器学习/深度学习 前端开发 算法
婚恋交友系统平台 相亲交友平台系统 婚恋交友系统APP 婚恋系统源码 婚恋交友平台开发流程 婚恋交友系统架构设计 婚恋交友系统前端/后端开发 婚恋交友系统匹配推荐算法优化
婚恋交友系统平台通过线上互动帮助单身男女找到合适伴侣,提供用户注册、个人资料填写、匹配推荐、实时聊天、社区互动等功能。开发流程包括需求分析、技术选型、系统架构设计、功能实现、测试优化和上线运维。匹配推荐算法优化是核心,通过用户行为数据分析和机器学习提高匹配准确性。
67 3
|
19天前
|
前端开发 搜索推荐 安全
陪玩系统架构设计陪玩系统前后端开发,陪玩前端设计是如何让人眼前一亮的?
陪玩系统的架构设计、前后端开发及前端设计是构建吸引用户、功能完善的平台关键。架构需考虑用户需求、技术选型、安全性等,确保稳定性和扩展性。前端可选用React、Vue或Uniapp,后端用Spring Boot或Django,数据库结合MySQL和MongoDB。功能涵盖用户管理、陪玩者管理、订单处理、智能匹配与通讯。安全性方面采用SSL加密和定期漏洞扫描。前端设计注重美观、易用及个性化推荐,提升用户体验和平台粘性。
52 0
存储 人工智能 自然语言处理
74 6
|
19天前
|
监控 Java 数据中心
微服务架构系统稳定性的神器-Hystrix
Hystrix是由Netflix开源的库,主要用于微服务架构中的熔断器模式,防止服务调用失败引发级联故障。它通过监控服务调用的成功和失败率,在失败率达到阈值时触发熔断,阻止后续调用,保护系统稳定。Hystrix具备熔断器、资源隔离、降级机制和实时监控等功能,提升系统的容错性和稳定性。然而,Hystrix也存在性能开销、配置复杂等局限,并已于2018年进入维护模式。
26 0

热门文章

最新文章

下一篇
开通oss服务