一文来聊一聊MySQL HeatWave
本篇文章给大家带来了关于MySQL的相关知识,其中主要介绍了关于MySQL HeatWave的相关内容,MySQL HeatWave 是一个内置高性能内存查询加速器的 MySQL 云服务;借助该服务,我们无需对当前应用进行任何更改,即可将混合工作负载的 MySQL 性能提高数个量级;下面一起来看一下,希望对大家有帮助。
MySQL 作为全球最欢迎的数据库,已在交易场景叱咤风云多年。在 2020 年底,OCI(Oracle Cloud Infrastructure)推出了一个黑科技插件,它弥补了 MySQL 在分析场景的短板,Oracle 官方称它比 Aurora 快 1400 倍,比 Redshift 快 6.5 倍,而且还能以二分之一的成本完成这些工作,它就是 MySQL HeatWave。
MySQL HeatWave 简介
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 数据库来支持 OLTP 和 OLAP;
数据以分区的方式存储在内存中;
应用程序无需做任何更改。
MySQL HeatWave 技术架构
整体架构
MySQL HeatWave 的架构如下图所示,它以一个插件的形式存在于整个 MySQL 数据库系统当中,它不会直接面对应用程序,可以理解为 MySQL HeatWave 挂在了 MDS 之下,用户无需修改原有的数据访问方式。
MySQL HeatWave 插件对应着若干个 MySQL HeatWave Node。MySQL HeatWave 的数据在内存中以列存的方式存储,其持久化的数据是存放在对象存储中,可在 Node 失效后快速完成恢复。
列存
HeatWave 的数据以列存方式存储在内存中,便于向量化处理,同时数据在加载到内存前会进行编码和压缩,可提高性能和减少内存占用,从而降低客户的成本。
基于行存数据做水平分区,基于水平分区,可以将查询在节点级并行执行来加速 scan、join、group-by、aggr 和 top-k 等算子,同时分区规划是与底层 RAPID 定制化硬件适配的。
分区内部将数据按照schema定义组织成列式存储,以引入向量化执行,每个向量化计算的单位是16KiB 的 vector,各列对应行的vector组合在一起成为 chunk,每个 partition 会有多个 chunks。
为了适配 DMS,vector 又划分为多个 tile,每 64 行组成一个tile作为数据传输的最小单元。
为了减少内存的使用,所有存储的数据都会做编码或压缩。
MySQL HeatWave 功能
以下内容摘自 Oracle 官网,地址为 link/4228bfbd579799d63cb20810ef5c04d1
一个 MySQL 数据库满足 OLTP 和 OLAP 两种需求
- 对 ETL 无依赖
- 提供实时分析
- 增强安全性
- 无需修改应用程序
- 支持 MySQL 数据库所支持的 BI 和数据可视化工具
- 可在公有云和用户的数据中心使用
高性能内存查询加速器
- 采用大规模扩展和高性能架构设计
- 针对云进行了优化
- 针对高事务处理量和连接进行了优化
In-database 机器学习
- 无需额外的机器学习服务
- 利用机器学习生命周期自动化,节省时间并减轻工作量
- 可解释的机器学习模型
MySQL 自动驾驶
- 自动配置
- 自动线程池
- 自动分片预测
- 自动编码
- 自动查询计划优化
- 自动数据安置
MySQL 湖仓一体(beta)
- TPC-H 性能优于同类产品
- 快速分析所有数据
- 可扩展的管理、处理数据架构
- 机器学习驱动自动优化,提升性能并节省时间
实时弹性
- 在高峰时间始终保持稳定的高性能,成本更低且无停机时间
- 避免过度预配实例
全托管数据库服务
高级安全性
- 通过密钥生成和数字签名进行非对称加密
- 数据脱敏
- SQL 白名单
MySQL HeatWave 工作原理
RAPID 引擎支持语句中相关函数;
RAPID 引擎执行时间评估少于 InnoDB 的执行时间。
当同时满足以上两个条件时,将由 RAPID 引擎,也就是 MySQL HeatWave 来处理相关业务请求。
在启用 MySQL HeatWave 插件后,对于接收到的请求,MDS 会通过两个条件来判断该请求是否走 RAPID 引擎,MySQL HeatWave 所使用的引擎是 RAPID,在研发阶段 MySQL HeatWave 的名字就是“RAPID”。
MySQL HeatWave 数据加载
加载方式
对于 MySQL HeatWave 的数据,可通过如下三种方式进行加载:
- 手动加载数据,每次加载一张表;
- 通过自动并行方式加载数据,通过 Autopilot 的方式可并行执行,效率较高;
- 通过 MySQL HeatWave 的控制台,以可视化的操作来完成数据加载,这种方式目前仅限在 AWS 上进行操作。没错,这里确实是只有 AWS 支持 MySQL HeatWave 控制台,AWS 快了 OCI 一步。
在初次数据加载时可能会耗时久一些,在完成数据加载后,MySQL HeatWave 会自动地保持与 InnoDB 数据一致,这里值得关注的是,自动同步变更数据的模式是异步的,最多可能要用户接受 200ms 的数据延迟,也就是说 MDS 上的数据变更不会等待 MySQL HeatWave 的反馈。
同步方式
MDS 会根据如下策略对数据进行同步:
每 200 ms;
当变更传输缓冲区达到 64MB 时;
在 MDS 中,经过 DML 变更的数据被后续的 HeatWave 查询需要读取时。
MySQL HeatWave 部署方式
公有云
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 支持部署在用户的数据中心,可满足合规要求,让数据驻留在用户的数据中心。这样的部署方式具备以下特点:
具有独立的 OCI 云区域,由 Oracle 托管;
满足数据驻留在用户数据中心的需求;
满足低延迟的需求。
MySQL HeatWave 性价比
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 性价比最高。
MySQL HeatWave 费用
在 Oracle 公益课堂中,我们可以了解到 MySQL HeatWave 的大概使用成本,对于这张图我们只需要关注下半部分,对于 2T 数据量的环境,每月的成本约为 1260 美元。
其中包括了 MDS 费用、MDS 存储的费用和 HeatWave 的费用。
MySQL HeatWave 多云差异
OCI 和 AWS
HeatWave 在 OCI 和 AWS 两朵云的 Roadmap 上的差异是比较有趣的,前面已提到可视化的数据加载只能通过 AWS 来完成,不只是这项能力,通过下图来看,AWS 在用户体验上要优于 OCI。
(https://www.oracle.com/mysql/#roadmap)
在 OCI 中需要使用控制台时,将会跳转到 AWS。
Azure
对于 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 的延迟问题(异步传输)。
推荐学习:mysql视频教程
以上就是一文来聊一聊MySQL HeatWave的详细内容,更多请关注其它相关文章!