Elasticsearch冻结索引被废弃？一文搞懂冷层与冻结层的区别及迁移方案

Elasticsearch存储架构演进：从冻结索引到冷热分层，如何实现数据生命周期的高效管理

如果你最近在Elasticsearch的日志里看到了那个熟悉的警告——[ignore_throttled] parameter is deprecated because frozen indices have been deprecated，别慌，这不仅仅是一个参数废弃的简单提示。它背后是Elasticsearch整个数据存储哲学的一次重大转向。我刚开始接触这个警告时，也以为只是版本兼容性问题，换个客户端版本就能解决。但深入探究后才发现，这是Elasticsearch从7.x版本开始，逐步推动的一场存储架构革新。今天，我们就来彻底搞懂这场变革的核心：为什么冻结索引（Frozen Indices）要被废弃？冷层（Cold Tier）和冻结层（Frozen Tier）到底是什么？更重要的是，作为运维或开发者，我们该如何平滑、安全地将现有基于冻结索引的架构，迁移到新的分层存储方案上。

这不仅仅是解决一个警告日志的问题，而是关乎我们如何以更低的成本、更高的效率来管理海量历史数据。想象一下，那些很少被查询但必须保留的日志、监控数据、合规性记录，它们占据了集群的大部分磁盘空间，却消耗着与热数据同等昂贵的硬件资源。新的冷热分层架构，正是为了解决这种资源错配而生。接下来，我将结合具体的配置案例、迁移步骤和实战中踩过的坑，带你完成这次技术升级。

1. 理解变革核心：为何要废弃冻结索引？

要理解为什么Elasticsearch要做出这个改变，我们得先回到“冻结索引”设计的初衷。在早期版本中，冻结索引是一种将极少访问的索引“休眠”的机制。通过POST /my_index/_freeze命令，索引的元数据保留在内存中，但分片数据被卸载，查询时会临时重新加载。这听起来很巧妙，用时间换空间，对吧？

但实际用起来，痛点非常明显。首先，查询延迟不可预测。一个针对冻结索引的查询，需要先“解冻”数据分片，这个I/O密集型操作会导致查询响应时间从毫秒级骤增至秒级甚至分钟级，用户体验极差。其次，资源管理复杂。解冻过程会突然占用大量堆外内存和文件句柄，可能影响集群中其他正在运行的服务。最后，它本质上是一种“补丁”方案，而非完整的存储层级。索引要么是“热”的（全内存），要么是“冻”的（全磁盘），缺乏中间状态，无法精细地根据数据的访问频率和性能要求来分配资源。

Elasticsearch引入的数据层（Data Tiers） 概念，正是为了系统性地解决这些问题。数据层将集群的节点按角色划分为热层（Hot）、温层（Warm）、冷层（Cold），以及可选的冻结层（Frozen）。每个层级对应不同的硬件配置（CPU、内存、磁盘类型）和数据管理策略：

• 热层 (Hot Tier): 使用高性能硬件（SSD），承载最新、最常被查询的数据。写入和实时查询都发生在这里。
• 温层 (Warm Tier): 使用性价比更高的硬件（大容量SSD或高速HDD），存放近期不再写入但仍需中频查询的数据。
• 冷层 (Cold Tier): 使用大容量、低成本硬件（如HDD），存储很少被查询的归档数据。查询允许较慢，但存储成本大幅降低。
• 冻结层 (Frozen Tier): 专为极罕见查询设计，通常使用对象存储（如S3）。数据完全持久化在廉价存储上，查询时使用“可搜索快照”技术按需加载缓存，对集群资源影响最小。

这个架构的核心优势在于自动化与精细化。通过索引生命周期管理（ILM）策略，数据可以像流水一样，随着时间的推移，自动从热层迁移到冷层或冻结层。每个层级各司其职，资源利用率最大化。

注意：ignore_throttled参数被废弃，正是因为它的设计紧密耦合了旧的冻结索引机制。在新的数据层架构下，索引的“节流”状态由其所处的层级和ILM策略自动管理，不再需要这个手动干预的参数。

2. 冷层 vs. 冻结层：如何根据场景做出正确选择？

冷层和冻结层常常被放在一起讨论，因为它们都面向“冷数据”。但在技术实现、成本性能和适用场景上，两者有本质区别。选择错误，可能会导致不必要的成本开销或无法接受的查询性能。

为了更清晰地对比，我们来看下面这个表格：