为什么Prometheus不适合用作长期时序数据存储？

本地存储用于长期保存的核心弊端 #

• 资源占用随存储周期线性上涨：Prometheus 本地存储为了保障实时查询、告警的性能，做了大量内存级优化，保存的时间序列越多、数据跨度越长，内存和磁盘消耗就越高。如果保留超过1年的全量指标，单实例往往需要TB级以上的高性能存储，且查询老旧数据时会大幅拉高整机负载，直接影响实时监控的核心功能稳定性。
• 无原生分布式能力，单点风险高：Prometheus 本地存储和单实例强绑定，没有内置集群扩容能力，既不能通过加节点分摊长期存储的压力，也没有多副本冗余机制，单节点磁盘故障就会导致所有历史数据丢失。
• 存储成本控制能力差：没有分级存储功能，冷热数据全部存在高性能磁盘上，也没有针对冷数据做高压缩比优化，长期存储的磁盘开销比专门优化过的TSDB高30%~50%，投入产出比极低。

官方提及的两个概念解释 #

Prometheus的本地存储并非为持久长期存储设计，外部方案可提供扩展保留周期与数据耐久性。

扩展保留周期 #

指可以不受单节点硬件上限约束，灵活调整数据保留时长，从数月到数年甚至永久保存都可实现，且查询跨数年的历史数据时，不会影响实时监控、告警的正常运行。

数据耐久性 #

指数据写入后丢失的概率极低，专业的长期存储方案通常会提供多副本冗余、自动快照备份、跨可用区容灾等能力，数据耐久性普遍可达99.999999999%，单节点故障、磁盘损坏都不会导致历史数据丢失。

Prometheus本地存储无法实现上述能力的核心原因 #

• 设计定位差异：Prometheus 从立项开始的核心定位就是近实时监控告警，所有设计取舍都偏向最近几小时、几天数据的查询效率和告警响应速度，从一开始就没有考虑跨年级别长期存储的需求。
• 缺少分布式架构支撑：扩展保留周期需要分布式集群做水平扩容来承载海量历史数据，Prometheus 本身没有原生的分布式存储层，单实例的硬件上限就是数据可保留的最长周期上限。
• 无高可靠数据保障机制：Prometheus 本地存储默认没有多副本冗余、自动备份校验的能力，一旦磁盘出现故障，很容易出现数据损坏、丢失的情况，达不到长期存储要求的高耐久性标准。
• 缺少冷数据适配逻辑：针对长期存储的冷数据归档、高压缩比二次压缩、冷查询资源隔离等优化能力，Prometheus 本地存储都不具备，保留周期拉得越长，运行稳定性越差、成本越高。

内容的提问来源于stack exchange，提问作者Anton