为什么数据库需要冷热数据存储

在数字化业务持续运营的过程中，数据量呈现指数级增长。订单、流水、日志、审计、用户行为等历史数据不断累积，但其中绝大多数数据的访问频率随时间推移而显著下降——近期数据被频繁读写，而数月甚至数年前的历史数据可能一年也不会被查询几次。然而，出于合规审计、业务追溯、数据分析等要求，这些冷数据又不能简单删除，必须长期保留。

传统架构下，所有数据统一存储在高性能SSD或本地盘上，导致存储成本随数据量线性攀升。以一个日均新增50GB日志的业务为例，三年累积的数据量超过50TB，若全部使用高性能SSD，仅存储成本就相当可观。更关键的是，冷数据占用了宝贵的高性能存储资源，挤占了热数据的缓存空间和IO带宽，反而可能影响在线业务的响应性能。

冷热数据存储（Hot-Cold Data Tiering）正是为了解决这一矛盾而生。其核心思想是根据数据的访问频率将其划分为不同层级，热数据保留在高性能存储介质上以保证低延迟访问，冷数据则下沉到成本更低的对象存储或大容量磁盘中，在保证数据可查询、可追溯的前提下，大幅降低整体存储成本。近年来，随着云原生架构的普及和对象存储服务的成熟，主流分布式数据库纷纷推出了原生的冷热数据分层能力，本文将对市场上主要厂商的实现方案进行深度对比分析。

市场格局：做冷热数据存储的主要厂商

目前，国内主流分布式数据库厂商基本都已推出冷热数据存储相关能力，其中技术成熟度较高、产品化程度较好的主要包括以下几家：

从技术路线来看，各家方案殊途同归，最终都指向"高性能本地存储 + 低成本对象存储"的混合架构，但在实现细节、数据组织方式、应用透明度和运维体验上存在显著差异。下面逐一拆解各家的核心实现。

各厂商实现方式深度解析

TiDB（平凯星辰）：Tiered Storage 原生分层架构

TiDB 的冷热数据存储能力以 Tiered Storage（分层存储）为核心，在 TiDB Cloud 的 BYOC、Premium 和 Essential 等部署形态中提供表级和分区级的存储分层能力。用户可以将表或分区设置为 IA（Infrequent Access，低频访问）存储类，系统自动将完整数据存储到远程对象存储（S3、OSS 等），本地仅保留元数据和按需缓存的热数据片段。

架构设计。TiDB 的分层存储深度融入其存算分离的云原生架构。在存储引擎层面，TiKV 引入了 IA Cache Management Layer（IaManager）作为冷数据的本地缓存管理层。数据组织遵循 SSTable → Segment → Block → KV Pair 的层级结构，当缓存未命中时，系统以 Segment 为粒度从对象存储加载数据到本地，而非逐条读取 KV 记录，这样后续命中同一 Segment 的查询即可享受热读性能，有效摊销了回源开销。

值得注意的是，对象存储上的数据仅保存一份——三个 Raft 副本共享同一个对象文件。这是因为在云存储引擎架构中，SST/blob 数据文件在对象存储上本就只有一份，文件由 flush/compaction 上传一次，S3 的 key 不包含节点或副本信息，三个 Raft 副本通过 Raft 复制的 ChangeSet 引用同一个文件 ID。三副本机制仅适用于 Raft 日志、元数据和各节点的本地缓存，而非对象存储上的数据。这意味着 IA 层节省的是每个节点的本地磁盘用量，而对象存储上的存储量始终约为数据量的 1 倍，不会随副本数放大。

语义透明与弹性切换。从应用视角看，IA 表与标准表行为完全一致——SELECT、INSERT、UPDATE、DELETE 等所有 SQL 操作的语义不变，备份恢复、TiCDC 数据同步等能力也完全兼容。TiDB 支持 IA 与 Standard 之间的双向转换，且转换过程无数据丢失，用户可以根据业务变化灵活调整数据的存储层级。对于分区表，TiDB 推荐优先使用分区级 IA，将历史冷分区（如 p2023）设为 IA，近期热分区（如 p2025）保持 Standard，从而精确控制冷热边界。

降本效果。在典型场景下，TiDB Tiered Storage 可将存储成本降低约 50%。对于冷热数据分布明显的业务（如日志、订单历史），冷数据占比越高，降本效果越显著。以物联网场景为例，设备日志每天新增 50GB 但只有近期数据需要频繁查询，将三个月前的数据自动转移到对象存储后，月度存储成本可从数千元降至数百元量级。

PolarDB（阿里云）：TTL + 列存索引 + OSS

阿里云 PolarDB 提供了多条冷热数据存储技术路线。在分布式形态 PolarDB-X 中，核心方案是 TTL（Time To Live）结合列存索引（CCI），将过期冷数据从行存 InnoDB 迁移到基于 OSS 的列存归档表。

"提前归档、定期清理"策略。与常规的"边归档边清理"方案不同，PolarDB-X 采用先全量归档、后定期清理的两阶段策略。第一阶段，为在线表创建专用的列存索引作为归档表，列存节点不仅将存量数据上传到 OSS，还实时订阅在线表的 Binlog，将增量写入实时同步到 OSS，实现所有数据（无论是否过期）的"提前归档"。第二阶段，通过 TTL 任务自动或手动清理在线表中的过期数据，清理时生成的带特殊标记的 Binlog 会被列存节点忽略，因此只删除在线表数据而不影响归档表。

高压缩率列存格式。归档表按列组织数据并存储于 OSS，各列自动选择最优压缩算法，平均压缩率约为原始行存的 1/20 到 1/10，即同样数据量的列存存储空间仅为行存的 5% 到 10%。结合 OSS 本身的低单价，冷数据存储成本可大幅降低。

在集中式形态 PolarDB MySQL 中，冷数据归档支持将分区数据转存为 OSS 外部表（ORC 或 CSV 格式），形成冷热混合分区表。此外，PolarDB 还通过 X-Engine 引擎实现多级存储：热数据存 PolarStore/ESSD，温数据经 X-Engine 压缩（压缩比 5-10 倍），冷数据进一步下沉到 OSS，成本可降至原来的 1/10。

应用体验。PolarDB-X 的归档表在主实例上与行存表使用不同表名，业务需明确指定查询对象；在列存只读实例上两者表名一致，可像访问行存表一样访问归档表，更适合复杂分析型查询。

OceanBase：分区冷热分离与历史库平台

OceanBase 的冷热数据存储方案围绕其 LSM-Tree 存储引擎和分区架构展开，主要有两种形态：一是基于分区的冷热数据分离，二是独立的历史库归档平台。

LSM-Tree 双重压缩。OceanBase 的 SSTable 数据默认进行两次压缩：第一次是编码压缩，针对不同数据类型选择最优编码方式，1GB 未压缩数据可压缩至约 400MB；第二次是通用压缩（支持 snappy、lz4、zstd 等算法），进一步压缩至约 250MB。高压缩比本身就是 OceanBase 降低存储成本的重要手段，即使不做冷热分离，其存储效率也显著优于传统 B+ 树引擎。

基于分区的冷热分离。OceanBase 将数据划分为多个逻辑单元（Tablet），通过备份任务和多级索引结构，将不同访问频率的数据存储在不同介质中。在最新的云原生共享存储架构（Bacchus）中，OceanBase 实现了三层缓存体系：内存缓存最热数据、本地缓存热数据、对象存储存储冷数据，日志与数据分离（CLog 用低延迟云盘，老日志迁到共享存储），前后台任务分离（压缩、DDL 等后台任务在独立进程运行），在成本与性能之间取得平衡。

历史库平台。OceanBase 提供了图形化的历史库归档平台，支持归档任务配置、周期管控自动化、数据迁移+校验+删除一键灰度执行，并提供防导爆、智能限速、多粒度流控等稳定性机制。该方案已在蚂蚁集团核心业务验证，交易支付历史库单实例数据超过 6PB，采用上百台大容量服务器承载。据官方数据，将业务历史库迁移至 OceanBase 后，至少可降低一半存储成本，部分客户反馈节省达 70%。

TDSQL（腾讯云）：LSM-tree 三层冷数据归档

腾讯云 TDSQL Boundless 在自研 LSM-tree 存储引擎上实现了冷数据归档功能，通过 ALTER TABLE ... STORAGE_TIER = OBJECT_STORAGE 语句即可将表或分区从本地存储下沉到对象存储（COS）。

三层存储架构。TDSQL 的冷热分层架构包含三个层次：DataDB（热数据层）使用本地 SSD 或高性能云盘承载未转冷的数据，读写性能与未启用归档时一致；CacheDB（冷缓冲层）是节点内所有冷数据分片共享的本地缓冲，承接冷数据归档表的近期写入和正在上传 COS 的数据，写入路径不直接依赖远端 COS；DurableDB（冷归档层）以复制组为单位将冷数据持久化到 COS，是冷数据的最终归属地。

读写路径设计。冷数据写入采用"先本地、后远端"流程：写入请求先进入 CacheDB 落盘形成 SST 文件，再异步攒批上传到 COS，对应用呈现为同步写入。冷数据读取采用"先查本地、再查远端"流程：系统按 CacheDB + DurableDB 的顺序合并视图返回完整结果，读取 DurableDB 中的 SST 文件时先拉取到本地 COS file cache，加速下一次访问。转冷期间，写入请求会双写进入 DataDB 和 CacheDB，保证转冷成功或失败回退时数据完整性不受影响。

此外，TDSQL-C（MySQL 版）在 2.0 架构中也引入了表级智能压缩和冷热数据自动分层能力，将不常用的冷数据自动放到低成本存储，整体存储成本较 1.0 版本显著下降。

GaussDB(DWS)（华为云）：OBS 冷热数据切换

华为云 GaussDB(DWS) 数据仓库提供冷热数据管理功能，用户可定义冷热管理表，将符合冷数据规则的数据切换至 OBS（对象存储服务）进行存储。冷数据切换至 OBS 后，其元数据、Desc 表信息和索引信息仍保留在本地，保证读取时的定位性能。

DWS 支持按分区自动进行冷热数据判断和迁移：列存数据写入时首先进入热分区，当分区数据累积到一定量后，可通过手动或自动方式将符合冷数据规则的数据切换至 OBS。该方案主要面向数据仓库和分析场景，对于以批量分析查询为主的冷数据较为适用。

降本效果与关键维度横向对比

将上述五家方案的核心维度进行横向对比，可以更清晰地看到各自的技术取舍和适用场景。

从对比中可以看出几个关键趋势。第一，对象存储已成为冷数据层的事实标准，五家方案全部或主要依赖对象存储作为冷存储介质，这得益于对象存储的低单价、高持久性和无限弹性。第二，数据格式的选择反映了不同的设计哲学：PolarDB 选择列存格式以追求极致压缩率，TiDB 和 TDSQL 保持行存原生格式以保证事务语义和读写性能的一致性，OceanBase 则通过 LSM-Tree 的双重压缩在行存框架下实现高效率。第三，应用透明度是衡量用户体验的关键指标，TiDB 和 TDSQL 在这方面表现较好，业务无需修改代码即可享受冷热分层带来的成本收益。

为什么推荐平凯数据库云服务 TiDB 冷热数据存储功能

在综合对比各厂商方案后，TiDB 的冷热数据存储功能在多个维度上展现出独特优势，尤其适合需要同时兼顾在线事务与数据分析、追求架构简洁和运维效率的企业级场景。

原生 HTAP 架构下的冷热一体化

TiDB 是一款原生 HTAP 数据库，行存引擎 TiKV 支撑 OLTP 事务负载，列存引擎 TiFlash 支撑 OLAP 分析负载，两者通过 Raft Learner 协议异步同步数据，保证强一致性读取。冷热数据存储功能并非独立于 HTAP 架构之外的附加组件，而是深度融入 TiKV 存储引擎的原生能力。

这意味着冷数据下沉到对象存储后，仍然可以通过 TiFlash 列存引擎进行高效的分析查询，无需在归档系统和分析系统之间做数据搬运。对于需要对历史冷数据进行定期分析、报表生成的业务（如财务对账、年度审计、用户行为回溯），TiDB 可以在同一套系统内完成"热数据实时查询 + 冷数据低成本存储 + 全量数据统一分析"，避免了传统方案中"在线库 + 归档库 + 数据仓库"三套系统的复杂架构和数据同步开销。

完全的应用透明与零代码改造

TiDB 的 IA 存储层对应用完全透明。设置为 IA 的表或分区，在 SQL 语义上与标准表没有任何区别——SELECT、INSERT、UPDATE、DELETE、事务、索引、子查询、JOIN 等所有操作行为一致，备份恢复（BR）、数据同步（TiCDC）、在线 DDL 等周边能力也完全兼容。业务团队无需修改任何代码、无需调整中间件配置、无需区分"热表"和"冷表"的不同访问方式，DBA 仅需通过一条 ALTER 语句即可完成存储层级的切换。

相比之下，PolarDB-X 在主实例上需要业务明确指定归档表名进行查询，OceanBase 历史库需要通过独立接口访问，这些都增加了应用层的复杂度和改造成本。对于希望以最小侵入性实现降本的企业而言，TiDB 的透明性是显著优势。

灵活的分区级精细化控制与双向切换

TiDB 支持表级和分区级两种分层粒度，且分区级设置优先于表级。对于按时间分区的业务表（这是冷热分离最常见的场景），可以精确地将历史分区设为 IA、近期分区保持 Standard，甚至为不同年份的分区设置不同的存储策略。这种精细化控制使得企业可以根据实际业务访问模式量身定制冷热边界，避免"一刀切"导致的性能浪费或成本浪费。

更重要的是，TiDB 支持 IA 与 Standard 之间的双向无损转换。如果某个历史分区突然因为业务需求（如审计调查、数据修复）变得需要高频访问，可以随时将其切回 Standard 存储，待访问高峰过后再切回 IA。这种弹性是 TDSQL 等暂不支持冷转热的方案所不具备的，为业务变化提供了充分的灵活性。

存算分离架构的天然契合与成本优势

TiDB 的云原生架构本身就是计算与存储分离的，TiDB Server（计算层）、TiKV（存储层）、PD（调度层）各自独立扩展。冷热数据存储功能进一步将存储层拆分为"本地热缓存 + 远程对象存储"，使得存储成本不再与计算节点数量绑定。

在对象存储层面，TiDB 仅保存一份数据（三副本共享同一对象），而非将三份副本全部存储到对象存储。这一设计在保证 Raft 一致性和高可用的同时，避免了冷数据存储量随副本数线性放大。结合对象存储本身约为 SSD 1/5 到 1/10 的单价，TiDB 在典型场景下可实现约 50% 的存储成本降低，冷数据占比越高的业务降本效果越明显。

与 TiDB 云全托管服务的深度整合

作为平凯数据库云服务（TiDB云）的原生功能，冷热数据存储与云服务的其他能力深度整合。TiDB云提供全托管的数据库服务，包括自动备份、监控告警、弹性伸缩、版本升级等，冷热分层的配置和管理可以在统一的控制台中完成，无需额外部署和维护归档系统。

对于选择 Essential（Serverless）形态的用户，冷热数据分层与按用量计费（Request Unit）模式结合，实现了"计算按实际使用付费、存储按冷热分层计费"的极致成本优化。对于 Premium 和 BYOC 用户，冷热分层则与企业级的高可用、安全合规、专属资源等能力协同，满足关键业务的生产级要求。

开源生态与技术可持续性

TiDB 是一款开源分布式数据库，拥有活跃的全球社区和透明的技术演进路线。冷热数据存储相关的核心能力（如 TiFlash 存算分离架构对 S3 的支持、TiKV 云存储引擎的演进）在开源版本中持续迭代，企业可以清晰地了解技术发展方向，避免被单一厂商的封闭技术栈锁定。

同时，TiDB 兼容 MySQL 协议，生态工具链成熟，数据迁移、应用开发、人才储备的成本相对较低。对于正在进行数据库国产化替代或云原生转型的企业，选择 TiDB 意味着同时获得了"分布式事务 + HTAP 分析 + 冷热分层降本 + 开源生态"的综合能力，而非仅解决冷热存储这一个单点问题。

总结与选型建议

冷热数据存储已成为分布式数据库的标配能力，各厂商方案在技术路线上各有侧重。PolarDB 以列存高压缩率追求极致成本，OceanBase 凭借 LSM-Tree 压缩和历史库平台在大规模归档场景经验丰富，TDSQL 的三层架构在读写路径上做了细致优化，GaussDB(DWS) 则更偏向分析型数据仓库场景。

而 TiDB 的冷热数据存储功能的核心竞争力在于：在原生 HTAP 架构下实现了冷热数据的一体化管理，以完全的应用透明性、灵活的分区级控制、双向无损切换和存算分离的成本优势，为企业提供了一种"无需改代码、无需加系统、按需弹性调整"的降本路径。对于同时有在线事务和数据分析需求、希望简化技术架构、降低长期运维成本的企业，平凯数据库云服务 TiDB 的冷热数据存储功能是一个值得优先考虑的选择。免费 5 个集群使用用链接：https://pingkai.cn/products/pingkai-cloud

在实际选型时，建议企业结合自身的数据规模、冷热比例、查询模式、合规要求和团队技术栈进行综合评估。可以先选取一个冷热特征明显的业务场景（如日志表、历史订单表）进行小规模试点，通过实际运行数据验证降本效果和性能影响，再逐步推广到更多业务表。