如何理解MySQL冷热数据分离设计

数据库开发入门

数据量的增长其实随着互联网的发展一直在爆发式的增长，因为各种数据都在不断的被原样替换或者经过一些修改和补充，被复制到互联网的各个角落，为了适应海量的增长互联网数据，从后端和架构来看，数据库的发展一般经历了“单库单表->主从读写分离->分表分库->NoSQL-> NewSQL”这样的一个过程。

一开始，我们把数据堆在一张数据表里；后来，为了导入为了提高性能并增加数据扩展能力，我们采用了“主从读写分离”和“分表分库”的方法，前者只需要在主从实例之间同步数据，不会造成太大影响针对现有业务，而后者则需要利用一套业务逻辑方法来合理制定分表、分库的策略；而后来NoSQL的出现，打破了传统关系数据库的一些固有限制。他们有不同的类型。有的是为了解决高性能读写的需求，有的是为了解决海量数据存储的需求，还有的是需要数据结构本身。可扩展；

不同类型的NoSQL解决不同问题的侧重点不同，而如今出现的NewSQL往往将数据库视为黑盒服务。你仍然可以按照传统的数据库协议的使用方式来使用（比如与传统MySQL的使用方式相同），但数据存储服务本身可以兼具较高的读写性能，并且可以轻松实现水平扩展。 NewSQL并不是一个全新的东西。我们可以将其视为将之前积累的数据库技术与分布式技术相结合的综合解决方案。它让使用数据服务的人们几乎不再需要考虑性能和扩展问题，而尽可能地利用数据。该服务内部实现了高可用性、高性能和可扩展性。

“热数据”和“冷数据”

简单了解了数据库的发展历史之后，我们来介绍一下目前我们在数据存储方面遇到的问题以及一些业务背景。

作为气象大数据服务商，随着我们积累的数据量和类型的增加，我们发现迫切需要全球层面统一的数据路径规划和规范湖很多时候，我们从数据源获取的数据需要立即分发给线上用户并供内部项目使用。如果只是简单的按需实现，数据流程会非常混乱。基于这样的考虑，我们引入了“热数据”（“线上数据”）和“冷数据”（“线下数据”）的概念：

这实际上并不是一个新概念。许多数据服务公司都有类似的设计。我们只是根据我们的业务特点借用了这个。概念，尽管它们的含义可能与您在其他地方看到的类似概念不同。

根据我们具体的业务场景，“热数据”这条线实际上已经有效运行，即我们从数据中心获取数据。数据源并以最快的速度存储在高性能存储介质中，然后使用 HTTP 协议进行分布式，这些数据都是实时更新的最新数据。对于某些类型的数据，我们还需要在可视化项目中查看历史变化并进行简单的聚合和计算。这意味着数据需要积累一段时间，我们还需要一些可以持久存储的介质。

以实时天气为例。当我们收集到数据后，我们立即将最新的数据存储在Redis中。从数据积累的角度来说，我们也将新的数据写入到MySQL中。这是我们之前的做法。然而，随着数据量的快速膨胀，MySQL很快就会出现问题。对于单个MySQL表有“亿”行，操作会变得越来越困难，大规模的数据提取或数据插入操作可能会让整个MySQL无法提供服务，w这对于在线业务来说非常困难。是不可接受的。

离线数据中心的实现

提出“冷数据”的概念后，我们意识到那些长期存在的历史数据实际上需要存储在“冷数据”数据中center pool 这里，在线时MySQL只需要保留最近一段时间的数据即可。另外，为了不改变现有项目使用数据的方式，降低数据库用户的门槛，我们需要兼容MySQL单表使用协议，无论是在线数据库还是“离线数据”数据中心。

很快我们开始考虑NewSQL方案，TiDB自然而然地进入了我们的视野。这是一个既兼容现有数据使用方式又可以实现数据水平扩展的完美解决方案。然而，不幸的是，与我们当前作为“离线数据”的角色相比，构建最小版本的 TiDB 数据集群的成本仍然有点高存储中心，我们的库存服务基本都是基于阿里云。 ，所以最终我们选择了阿里云最近推出的云数据库PolarDB。这期间我们还研究了很多其他的数据库解决方案，比如DRDS、OceanBase、Google Cloud Spanner、Amazon Aurora等。

数据同步和数据过期

下线后数据存储中心，我们开始考虑如何将“热数据”转化为“冷数据”，同时也让在线数据库超过时间窗口的历史数据自动过期。另外，由于内部可视化项目也希望看到实时的直播数据，所以离线数据最好能够快速获取最新的直播数据。

既然是两个MySQL（集群）之间的实时数据传输，那么很自然的想到我们可以在主从节点之间做一个类似binlog的数据同步机制。这种同步可以在几秒钟内完成。电平延迟，完全交流实时性能方面可以接受。但这不能是简单的数据同步，因为离线数据无法同步在线数据的过期操作。更具体地说，我们可以总结为：MySQL从节点同步主节点的所有数据添加和数据修改操作，但不同步数据删除操作。

经过研究，我们发现 TiDB 提供的同步工具 Syncer 可以实现这一点。我们只需要在配置中注明过滤掉DELETE DML语句即可。示例如下：

 [[skip-dmls]] db-name = "weather_data" tbl-name = "weather_now_history" type = "delete"

数据过期计划可以直接借助MySQL自带的EVENT和PROCEDURE机制来完成。首先我们可以创建一个删除数据的PROCEDURE：

CREATE DEFINER=`weather`@`%` PROCEDURE `weather_data`.`del_old_data`(IN `date_inter` int) BEGIN 从weather_data删除.weather_now_history 其中 datetime < date_sub(curdate(), 间隔 date_inter day); END

该PROCEDURE函数的作用是删除weather_now_history表中date_inter日之前的数据。然后我们创建另一个事件：

CREATE EVENT del_old_data ON SCHEDULE EVERY 1 DAY STARTS '2023-12-25 10:08:35.000' ON COMPLETION PRESERVE ENABLE DO call del_old_data(30)

持续改进

上述具体业务场景更多的是针对“热数据”和“冷数据”的分离和转化问题进行解决，这意味着解决方案不具有通用性，可能存在当我们以后遇到其他数据库或者不同的数据使用场景时不再适用。

此外，很多时候，“热数据”和“冷数据”的划分并不是那么明确。对“冷数据”的需求可能会转变为对“热数据”的需求。我们需要保持灵活性。切换机制保证数据源只捕获一次（“热数据”和“冷数据”不应该分开捕获），并且捕获的数据可以自由流向“热数据”或“冷数据”线路进行使用，这意味着我们应该在数据捕获和数据存储之间创建另一层隔离。

要实现数据采集和数据存储的隔离，我们可以使用“发布/订阅模型”：简单来说，数据采集服务获取到数据后将数据发布到消息队列中，如下存储服务任意订阅这个消息队列然后存储，这样数据源只需要取一次e.我们可以把它当作热数据、冷数据，甚至可以把它当作热数据和冷数据，进行切换。这也很简单。这是后续系统架构可以改进的地方。

另外，对于我们可能产生的数据规模来说，仅仅在线下数据中心使用PolarDB是不够的。我们还需要一种成本更低的数据存储解决方案来存储平时很少使用的长期数据。会议访问的一些数据需要“归档”。这时，一些基于列存储的NoSQL数据库可能会派上用场。

数据治理需要一个长期持续的过程，我们还在结合自身业务场景进行探索。

感谢您的阅读。以上就是《如何理解MySQL的冷热数据分离设计》的内容。经过文章的学习，相信大家都会明白如何理解MySQL的冷热数据分离设计。我们有了更深的认识这个问题的发现，具体的用法还需要在实践中验证。在此，小编将为大家推送更多相关知识点的文章，欢迎关注！