数据库调优--冷热分离

冷热分离的简介：

冷热分离就是在处理数据的时候，将数据分为冷库和热库，冷库存放到走到终态的数据，不经常使用的数据，热库存放还需要修改和经常使用的数据。

什么情况下我们可以使用冷热分离：

1，数据走到终态后，只有读的需求，没有写的需求，比如说订单走到终态，就不会再有状态变更，

2，用户能接受新旧数据分开查询，比如某些电商默认只让查3个月以内的订单，要想查询3个月以外的，就得访问其他的页面。也就是说不会出现同时查询冷、热数据的需求。

一、冷热数据都用mysql

需要考虑的问题：

1，怎么判断一个数据用冷数据还是热数据

一般情况下我们可以根据主表的字段来确定，比如说创建时间，状态。在我们使用的过程中，具体怎么区分冷数据和热数据，还得根据具体的业务需要、

冷：只执行select查，不进行增删改 ，的终态称为冷数据

热：需要频繁进行增删改查的数据成为热数据

例：

1. 根据时间区分冷热数据，3个月以上的判为冷数据，3个月以内的判为热数据
2. 根据状态，被标记为已完结的判为冷数据，被标记为运输中的，未完结的判为热数据

下单->配送中->已完成  （正向流程）
下单->退货退款（仅退款） ->已完成(逆向流程)
终态：无论是产品的逻辑设计还是程序设计都得保证让数据走向终态。

最终态都是要被判为已完成的冷数据存入冷库

2，如何触发冷热分离

触发冷热分离有三种方案

1，业务代码来实现。当表的数据变更时，每次变更都进行一次判断，看看能不能进入到冷库，如果能，就放到冷库，删除热库数据（实时性最强，改动最大）

2，通过监听mysql的binlog日志（低延迟）

3，通过定时任务，定时扫描，将能放到冷库的数据进行归档（高延时，不能做到实时性）

3，如何实现冷热分离

实现冷热分离就是判断数据是否能进入到冷库，如果能，插入冷数据，删除热数据，但是需要我们注意几点：

1，事务一致性问题：需要我们研发做好兜底方案。

最常用的就是加一个字段，用来标志数据是否可以进入到冷数据，然后定时任务每天去扫描看看数据是否一致。

2，数据量大的问题

可以采用批处理的方式，即一次性可以对多条数据进行处理

3，并发处理

当数据非常大的时候，采用批处理也达不到要求，就要采用多线程，这里要做好锁，可以用数据库锁来实现。

4，如何使用冷热分离

可以根据前端页面来区分

5，历史数据如何迁移

可以编写java程序来进行迁移，如果采用的是定时任务方案，不需要关注。

6，为什么说数据库表数据量大要优化：

1，查询慢，影响体验

2，如果数据量非常大，可能一个查询，就把数据库整宕机了。

7，低耦合高内聚

耦合：就是模块间的关联度，低耦合就是关联度要小（例如减少继承和友元，全局变量），可以理解为方法之间的依赖，如果改一个方法，其他方法都需要修改的话，这是高耦合，反之就是低耦合

内聚：模块的功能，高内聚就是模块的功能要尽可能简洁，最好一个模块只完成一个功能

二、冷数据存放到hbase

上面第一期，冷热数据都用mysql，存在两个问题：

用户还是会存在查询冷数据的场景。并且用户在查询冷数据的时候依旧很慢。

那么就需要一种数据库，可以存放上亿的数据，并且支持简单的组合关键字查询，并且存放的数据不会在变更。所以我们采用hbase来实现。

hbase是一种天然支持分布式的数据库，因为他是非关系型数据库，每个表之前都没有实际的联系，hbase同一行的数据没有存放到一起，所以hbase只能做一些简单的查询，实现不了复杂的查询。

关系型数据库：mysql，pgsql，oracle，不同表里的字段都有联系

优点：可以实现复杂的业务逻辑

缺点：相比非关系型数据库性能会差一些

非关系型数据库：redis，hbase，es

优点：查询效率更高

缺电：不能实现复杂的业务逻辑

冷热分离的弊端：

对业务要求非常高，要求冷热数据不能同时查询，冷数据不能被修改，冷数据不能进行复杂的查询，但是他的性价比非常高，可以快速的实现项目的优化，可以实现快速拓展，如果空间不够了要新增机器时，只需要配置多一个节点就可以实现拓展。