ES存储生命周期

type
status
date
slug
summary
tags
category
icon
password
name
昨天迁移es存储的时候遇到了warm存储空间不足的问题,反复移动了几个日志文件到 cold 存储还是没解决这个问题,趁此来好好理解一下es的存储的区别。
查看了 es 的官方说明,索引生命周期管理(ILM)是在 6.7 后面才引出的功能,总结来说数据的存储分为以下几个:
  • Hot(热)阶段
    • 在此阶段,数据被频繁查询和修改。索引保持在高性能的硬件上,如使用 SSD 存储。
    • 策略通常包括将数据设置为只写,以便快速地索引新数据。
  • Warm(温)阶段
    • 当数据不再那么频繁被访问或更新时,它会转移到温阶段。
    • 在这一阶段,可以执行一些优化操作,如更改索引的分片数,以减少资源的使用,同时保持必要的访问速度。
  • Cold(冷)阶段
    • 数据在这个阶段很少被访问,但仍需保留。
    • 数据通常会被迁移到成本更低的存储上,如使用普通硬盘(HDD)。可以进一步压缩索引以节省空间。
  • Delete(删除)阶段
    • 最终,当数据不再需要时,会进入删除阶段。
    • 在这个阶段,索引会被彻底删除以释放资源。
也即是说,es 会根据你的配置(Kibana 或 REST API)来分配 ILM 策略,分配合适的存储方式来达到降本增效。
回到项目,这是个部署到 aws 上的 es 集群,本身会用到叫做UltraWarm storage和Cold storage的功能,该功能会启动以下三种index
Hot Indices:热索引,可读可写,使用ES存储
Warm Indices:暖索引,可读不可写,底层使用S3
Cold Indices:冷索引,不可读不可写,底层使用S3
再来看看那天的操作,将 cold 存储的内容移动到 warm 中,然后显示了下面的错误。
notion image
 
Loading...

© Dreamin 2021-2024