MySQL 作为全球最欢迎的数据库,已在交易场景叱咤风云多年。在 2020 年底,OCI(Oracle Cloud Infrastructure)推出了一个黑科技插件,它弥补了 MySQL 在分析场景的短板,Oracle 官方称它比 Aurora 快 1400 倍,比 Redshift 快 6.5 倍,而且还能以二分之一的成本完成这些工作,它就是 MySQL HeatWave。
目前网络上关于 MySQL HeatWave 的资料相对较少,我通过已有的资料和 B 站公开课视频初探 MySQL HeatWave,梳理出本篇笔记。
本文发布时间为 2022 年 11 月,由于产品更新的客观情况,本文部分信息会存在实效性,请以官方文档为准。(MySQL :: MySQL HeatWave User Guide :: 1 Overview)
MySQL HeatWave 是一个内置高性能内存查询加速器的 MySQL 云服务。借助该服务,我们无需对当前应用进行任何更改,即可将混合工作负载的 MySQL 性能提高数个量级。
相比传统的分析场景,MySQL HeatWave 可以让用户无需再使用单独的分析数据库、单独的机器学习 (ML) 工具以及提取、转换和加载(ETL)复制。同时,借助 MySQL HeatWave 机器学习,开发人员和数据分析师可以在 MySQL HeatWave 中构建、训练、部署和解释机器学习模型,无需将数据迁移到单独的机器学习服务中。
目前 MySQL HeatWave 可在 OCI(Oracle Cloud Infrastructure)、AWS(Amazon Web Services)和 Microsoft Azure 上使用。
MySQL HeatWave 可以附加到 MDS(MySQL Database Service)来支持分析类查询,它不会暴露给应用程序。MySQL HeatWave 的数据库是以列存形式存储在内存当中。
简单了解 MySQL HeatWave,首先了解如下三条内容即可:
MySQL HeatWave 的架构如下图所示,它以一个插件的形式存在于整个 MySQL 数据库系统当中,它不会直接面对应用程序,可以理解为 MySQL HeatWave 挂在了 MDS 之下,用户无需修改原有的数据访问方式。
MySQL HeatWave 插件对应着若干个 MySQL HeatWave Node。MySQL HeatWave 的数据在内存中以列存的方式存储,其持久化的数据是存放在对象存储中,可在 Node 失效后快速完成恢复。
HeatWave 的数据以列存方式存储在内存中,便于向量化处理,同时数据在加载到内存前会进行编码和压缩,可提高性能和减少内存占用,从而降低客户的成本。
以下内容摘自 Oracle 官网,地址为 https://www.oracle.com/mysql/#rc30p6
一个 MySQL 数据库满足 OLTP 和 OLAP 两种需求
高性能内存查询加速器
In-database 机器学习
MySQL 自动驾驶
MySQL 湖仓一体(beta)
实时弹性
全托管数据库服务
高级安全性
当同时满足以上两个条件时,将由 RAPID 引擎,也就是 MySQL HeatWave 来处理相关业务请求。
在启用 MySQL HeatWave 插件后,对于接收到的请求,MDS 会通过两个条件来判断该请求是否走 RAPID 引擎,MySQL HeatWave 所使用的引擎是 RAPID,在研发阶段 MySQL HeatWave 的名字就是“RAPID”。
对于 MySQL HeatWave 的数据,可通过如下三种方式进行加载:
在初次数据加载时可能会耗时久一些,在完成数据加载后,MySQL HeatWave 会自动地保持与 InnoDB 数据一致,这里值得关注的是,自动同步变更数据的模式是异步的,最多可能要用户接受 200ms 的数据延迟,也就是说 MDS 上的数据变更不会等待 MySQL HeatWave 的反馈。
MDS 会根据如下策略对数据进行同步:
MySQL HeatWave 可支持在 OCI(Oracle Cloud Infrastructure)、AWS(Amazon Web Services)和 Microsoft Azure 上使用。
所需的 HeatWave 节点数取决于数据大小,OCI 和 Azure 最多支持 64 个节点。在亚马逊网络服务(AWS)上,一个HeatWave集群最多支持128个 节点。
混合部署是指本地部署 OLTP + 云端部署 OLAP 的方式,在这种混合部署中,客户可以使用 MySQL 复制将本地 MySQL 数据复制到 OCI 或 AWS 的 MySQL HeatWave,而无需通过 ETL 来满足分析业务需求。
这种混合部署方式需要考虑数据延迟情况,在“数据加载”中已介绍,InnoDB 和 HeatWave 间数据是异步进行传输的,加上网络的延迟,需要考虑数据的实时性问题。据了解目前中国区没有 MySQL HeatWave。
OCI 支持部署在用户的数据中心,可满足合规要求,让数据驻留在用户的数据中心。这样的部署方式具备以下特点:
MySQL HeatWave 和 Amazon Redshift 「最快的实例」进行性能对比,对 19 次 TPC-H 测试结果进行几何平均计算后,MySQL HeatWave 比 Amazon Redshift 速度快 2.7 倍,成本仅为 Amazon Redshift 的三分之一。
MySQL HeatWave 和 Amazon Redshift 「低成本实例」进行性能对比,MySQL HeatWave 性能上要领先 Amazon Redshift 17 倍以上,投入成本持平。
从官方公布的性价比数据看,相比图上其他几款产品,MySQL HeatWave 性价比最高。
在 Oracle 公益课堂中,我们可以了解到 MySQL HeatWave 的大概使用成本,对于这张图我们只需要关注下半部分,对于 2T 数据量的环境,每月的成本约为 1260 美元。
其中包括了 MDS 费用、MDS 存储的费用和 HeatWave 的费用。
HeatWave 在 OCI 和 AWS 两朵云的 Roadmap 上的差异是比较有趣的,前面已提到可视化的数据加载只能通过 AWS 来完成,不只是这项能力,通过下图来看,AWS 在用户体验上要优于 OCI。
(https://www.oracle.com/mysql/#roadmap)
在 OCI 中需要使用控制台时,将会跳转到 AWS。
对于 Azure 用户,仍然可以使用 MySQL HeatWave 服务,它是通过 Azure VNET 连接 OCI 的 MySQL HeatWave,也就是说,实际上使用的还是 OCI 的环境。
目的是为 Azure 用户提供原生用户体验,私有互联的方式将网络延迟控制在 2ms 内。
(https://www.oracle.com/cloud/azure/oracle-database-for-azure/)
MySQL HeatWave 可支持在 OCI(Oracle Cloud Infrastructure)、AWS(Amazon Web Services)和 Microsoft Azure 上使用,也支持将 OCI 部署到用户数据中心。
启用 MySQL HeatWave 插件后,用户可以通过一个 MySQL 服务来满足业务在 TP 和 AP 的需求,而无需修改业务。通过内部流程自动地完成数据同步,不需要单独维护 ETL,可保持架构简洁。自动驾驶(AI)和湖仓一体的能力给用户更多期待。
MySQL HeatWave 弥补了 MySQL 在分析场景的能力,对于中小型企业有非常大的意义。
其中有两方面不足之处,值得用户关注:InnoDB 的存储(扩展限制)及数据一致性问题。
扩展限制:MySQL HeatWave 可以提供扩展能力,但 MySQL InnoDB 存储问题没有在本质上被解决掉,InnoDB 面对海量数据的情况,仍存在较大挑战。
数据一致性:对于数据一致性要求较高的场景,需要考虑 InnoDB 到 HeatWave 的延迟问题(异步传输)。
[1] MySQL :: MySQL HeatWave User Guide :: 1 Overview
[2] Pushing Cloud MySQL Performance The Oracle Way (nextplatform.com)
[3] MySQL · HTAP · 分析型执行引擎 (taobao.org)
[4] Oracle 公益课堂:MDS & Heatwave
[5] HeatWave | Oracle 中国
[6] MySQL HeatWave Database Service | Oracle