数据库优化之数据冷热分离

数据冷热分离：根据数据的访问频率和业务重要性，将数据分为冷数据和热数据，冷数据存储在存储在低成本、低性能的介质中，热数据存在高性能存储介质中。

热数据：经常被访问和修改且需快速访问

冷数据：不经常访问，对当前项目价值较低，但需长期保存

冷热数据区分方法

时间区分：按数据的创建时间、更新时间、过期时间，确定一定时间段，之内的数据为热数据，之外为冷数据。如订单系统 1 年前的订单数据为冷数据，1 年内的订单数据为热数据。适合数据访问频率和时间强相关。

访问频率区分：高频访问为热数据，低频访问为冷数据。如内容系统浏览量低的文章为冷数据，浏览量高的文章为热数据。这种方法需记录数据的访问频率，成本较高，适合访问频率和数据本身强相关。

数据冷热分离的优缺点

优点：热数据查询性能得到优化（用户绝大部分操作体验会更好）、节约成本（冷热数据不同存储需求，选择对应的数据库类型和硬件配置，如将热数据放 SSD ，将冷数据放 HDD ）

缺点：系统复杂性和风险增加（需要分离冷热数据，数据错误的风险增加）、统计效率低（统计的时候可能需要用到冷库的数据）

冷数据的迁移

业务层代码实现：对数据进行写操作时，触发冷热分离逻辑，判断数据是冷还是热，冷数据就入冷库，热数据就入热库。这种方案影响性能且冷热数据的判断逻辑不太好确定，还需修改业务层代码，一般不会使用。

任务调度：可以利用 xxl-job 或者其他分布式任务调度平台定时去扫描数据库，找出满足冷数据条件的数据，然后批量地将其复制到冷库中，并从热库中删除。这种方法修改的代码非常少，非常适合按照时间区分冷热数据的场景。

监听数据库的变更日志 binlog ：将满足冷数据条件的数据从 binlog 中提取出来，然后复制到冷库中，并从热库中删除。这种方法可不用修改代码，但不适合按照时间维度区分冷热数据的场景

冷数据的存储

冷数据存储要求：容量大，成本低，可靠性高，访问速度可以适当牺牲。

冷数据存储方案：

• 中小厂：直接使用 MySQL/PostgreSQL 即可（不改变数据库选型和项目当前使用的数据库保持一致），比如新增一张表来存储某个业务的冷数据或者使用单独的冷库来存放冷数据（涉及跨库查询，增加系统复杂性和维护难度）
• 大厂：Hbase（常用）、RocksDB、Doris、Cassandra

如果预算充足，使用 TiDB 分布式关系型数据库，一步到位。TiDB 6.0 正式支持数据冷热存储分离，可降低 SSD 使用成本。使用 TiDB 6.0 数据放置功能，可在同一个集群实现海量数据的冷热存储，将新的热数据存入 SSD，历史冷数据存入 HDD。