【选型】热数据、温数据、冷数据：2026 年小白也能用的存储分层思路

为什么总在「该用 Redis 还是 PG」里二选一？

很多团队的架构争论，表面是技术选型，本质是 没人把数据的「温度」说清楚。

• 首页推荐列表：毫秒级、读多写少 → 热
• 去年订单明细：偶尔查、审计要留 → 温
• 七年前日志：几乎不查、合规要存 → 冷

温度不同，存储就不该同一套。2026 年云厂商把 S3、Archive、向量库、Serverless Postgres 都打包卖，选型的关键从「哪个数据库最强」变成「哪层放哪类数据」。

一张图搞懂三层

         ┌─────────────┐
  热 ──► │ Redis / 内存  │  QPS 高、允许丢一点、可重建
         └──────┬──────┘
                │ 回源
         ┌──────▼──────┐
  温 ──► │ PostgreSQL   │  事务、关系、索引、JSON 也行
         └──────┬──────┘
                │ 归档 / ETL
         ┌──────▼──────┐
  冷 ──► │ 对象存储     │  S3 / OSS / MinIO，便宜、量大
         └─────────────┘

反直觉点：Redis 里的数据，应该默认「丢了能重建」；真正不能丢的，最终仍要落 温层。

热层：Redis 不是银弹

适合：

• Session、限流计数、排行榜、短时去重
• 读多写少、可设 TTL 的缓存

不适合：

• 唯一真相源（Source of Truth）
• 复杂查询、跨键事务
• 「怕丢」又没 AOF/主从/持久化策略的数据

缓存击穿经典解法：

1. 互斥锁（只有一个请求回源）
2. 逻辑过期（旧值先返回，后台异步刷新）
3. 热点 key 永不过期 + 主动更新

# 简化：逻辑过期示意
cache = {"value": data, "expire_at": now + 300}
if now > cache["expire_at"]:
    asyncio.create_task(refresh_in_background())
return cache["value"]  # 仍返回旧值，避免 thundering herd

温层：PostgreSQL 仍是默认优解

2026 年 PG 生态更强了：JSONB、分区表、逻辑复制、pgvector（轻量向量场景）。

一条经验法则：

需要 ACID、需要 JOIN、需要「这一行不能丢」→ 先 PG，别绕路。

MySQL 不是不能用，而是问团队：谁熟、运维工具链是否现成、云托管版本是否满足。

冷层：对象存储 + 生命周期

日志、附件、备份、合规归档 → S3 兼容存储，配 Lifecycle 规则：

• 30 天热存储
• 90 天转 Infrequent Access
• 1 年后转 Archive

比「全部塞 NAS」便宜一个数量级，检索慢但本来也不常查。

2026 新变量：向量该放哪？

RAG、语义搜索火了，但 不必一上来就专用向量库：

向量是 索引类型，不是替代关系型数据库的理由。

选型自测 5 问

1. 丢了能否从温层重建？能 → 才配进热层
2. 是否需要事务与强一致？需要 → 温层
3. 查询模式是点查还是分析扫全表？后者 → 考虑 OLAP（ClickHouse 等）
4. 保留多久、谁审计？决定冷层策略
5. 团队谁会运维、半夜谁 on-call？再 fancy 的栈也要人兜底

结语

数据与存储没有「2026 年唯一正确答案」，只有 温度匹配。

先把数据分层画在白板上，再讨论 Redis 6 还是 7、PG 16 还是 17——争论会少一半，睡眠会多一小时。

你们团队温层/热层边界是怎么划的？欢迎晒架构图（打码也行）。