Elasticsearch 数据层：热、温、冷和冻存储详解

Elasticsearch 将数据组织到存储层中，以平衡性能、成本和可访问性。每个层级（从用于频繁访问数据的热层，到用于极少查询的数据集的冻层）都有特定的硬件和存储特性。本指南介绍了如何为时间序列数据和通用内容数据配置、管理和自动化跨层级的数据放置。

每个 数据层 都是 Elasticsearch 集群中一组共享相同 数据节点角色 的节点，以及为该角色配置了适当大小的硬件配置文件的集合。Elastic 建议同一层级中的节点共享相同的硬件配置文件，以避免出现 热点 (hot spotting)。

您使用的数据层以及使用它们的方式取决于数据的 类别。以下数据层可用于每种数据类别

内容数据:

• 内容层 节点处理非时间序列索引（如产品目录）的索引和查询负载。

时间序列数据:

• 热层 节点处理时间序列数据（如日志或指标）的索引负载。它们存储您最近、访问最频繁的数据。
• 温层 节点存储访问频率较低且很少需要更新的时间序列数据。
• 冷层 节点存储访问不频繁且通常不会更新的时间序列数据。为了节省空间，您可以在冷层上保留 可搜索快照的完全挂载索引。这些完全挂载索引消除了对副本的需求，与常规索引相比，减少了大约 50% 的所需磁盘空间。
• 冻层 节点存储极少访问且从不更新的时间序列数据。冻层专门存储 可搜索快照的部分挂载索引。这进一步扩展了存储容量——与温层相比，最多可扩展 20 倍。

数据层的使用方式通常取决于数据的类别

• 内容数据在其整个数据生命周期内都保留在 内容层 中。

• 时间序列数据可以根据您的性能、弹性和数据保留要求，在降温数据层（热、温、冷和冻）中迁移。

  您可以使用 数据流生命周期 或自定义 索引生命周期管理 来自动化这些生命周期转换。

了解有关每个数据层的更多信息，包括何时以及如何使用它们。

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

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

内容层是必需的，通常与热层部署在同一节点分组中。系统索引和其他不属于数据流的索引会自动分配到内容层。

热层是时间序列数据的 Elasticsearch 入口点，存储您最近、搜索最频繁的时间序列数据。热层中的节点在读写方面都需要速度快，这需要更多的硬件资源和更快的存储（SSD）。为了实现弹性，热层中的索引应配置为使用一个或多个副本。

ILM 策略也可以在 hot 阶段使用 searchable_snapshot 操作，在这种情况下，热层持有 完全挂载的 可搜索快照索引，而不是常规索引。

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

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

当您不再需要定期搜索时间序列数据时，它可以从温层移动到冷层。虽然仍然可搜索，但该层级通常针对更低的存储成本而非搜索速度进行了优化。

为了获得更好的存储节省，您可以在冷层上保留 可搜索快照的完全挂载索引。与常规索引不同，这些完全挂载索引不需要副本即可实现可靠性。如果发生故障，它们可以从底层快照中恢复数据。这有可能将数据所需的本地存储空间减半。在冷层使用完全挂载索引需要快照存储库。完全挂载索引是只读的。

或者，您可以使用冷层存储带有副本的常规索引，而不是使用可搜索快照。这使您可以在更便宜的硬件上存储较旧的数据，但与温层相比，不会减少所需的磁盘空间。

一旦数据不再被查询，或者很少被查询，它可能会从冷层移动到冻层，并在此度过其生命周期的剩余时间。

我们建议您在冻层中使用 专用节点。冻层需要快照存储库，并使用 部分挂载索引 从快照存储库存储和加载数据。这减少了本地存储和运营成本，同时仍然允许您搜索冻层数据。因为 Elasticsearch 有时必须从快照存储库中获取冻层数据，所以冻层上的搜索通常比冷层上的搜索慢。

您如何配置数据层取决于您集群的部署类型。使用与您的部署相匹配的指南

• 对于 ECH 或 ECE，默认的 Elastic Cloud 部署包含一个用于热数据和内容数据的共享层，它是必需的且无法移除。要在 Elastic Cloud UI 中添加或移除温、冷或冻容量（包括通过数据迁移进行安全移除），请参阅 在 Elastic Cloud Hosted 或 Elastic Cloud Enterprise 中添加或移除数据层。
• 对于 自管理或 ECK，请分配 数据角色 (data_*)，以便您的集群在每个主机的 elasticsearch.yml 中或在 Elastic Cloud on Kubernetes Elasticsearch 资源的每个节点集的 config 下公开您需要的层级。请参阅 为自管理和 Elastic Cloud on Kubernetes 部署配置数据层。

index.routing.allocation.include._tier_preference 设置决定了索引应该分配到哪个层级。

当您创建索引时，Elasticsearch 默认将 _tier_preference 设置为 data_content，以自动将索引分片分配到内容层。

当 Elasticsearch 作为 数据流 的一部分创建索引时，Elasticsearch 默认将 _tier_preference 设置为 data_hot，以自动将索引分片分配到热层。

在创建索引时，您可以通过以下两种方式之一显式设置首选值来覆盖默认设置

• 使用 索引模板。有关详细信息，请参阅 Elasticsearch 中的索引生命周期管理 (ILM)。
• 在 创建索引 请求正文中。

您可以在创建索引后通过 更新索引设置 为首选值来覆盖此设置。

此设置还接受按优先级排序的多个层级。如果集群中没有首选层级的节点，这可以防止索引保持未分配状态。例如，当索引生命周期管理将索引迁移到冷阶段时，它会将索引 _tier_preference 设置为 data_cold,data_warm,data_hot。

要移除数据层首选项设置，请将 _tier_preference 值设置为 null。这允许索引分配到集群内的任何数据节点。将 _tier_preference 设置为 null 不会恢复默认值。对于托管索引，迁移 (migrate) 操作可能会应用一个新值来代替它。

您可以通过 轮询现有索引的设置 以查看 index.routing.allocation.include._tier_preference，从而检查其数据层首选项。

				GET /my-index-000001/_settings?filter_path=*.settings.index.routing.allocation.include._tier_preference
		

_tier_preference 设置可能会与其他分配设置冲突。这种冲突可能会阻止分片分配。当集群尚未完全 迁移到数据层 时，可能会发生冲突。

此设置不会取消当前已分配分片的分配，但可能会阻止其从当前位置迁移到其指定的数据层。要进行故障排查，请调用 集群分配解释 (cluster allocation explain) API 并指定疑似有问题的分片。

ILM 使用 迁移 (migrate) 操作自动将托管索引通过可用的数据层进行迁移。默认情况下，此操作会自动注入到每个阶段。

您可以通过以下设置在 ILM 策略中显式禁用用于数据层迁移的数据分配

"migrate": {
  "enabled": false
}
		

例如

"cold": {
       "min_age": "15m",
       "actions": {
         "set_priority": {
           "priority": 0
         },
         "migrate": {
           "enabled": false
         }
       }
     },
		

为数据层定义 "enabled": false 的 migrate 操作会 禁用自动 ILM 分片迁移。如果您（例如）正在使用 allocate 操作 手动指定分配规则，这将非常有用。