解决 MySQL 的分析瓶颈,OceanBase 做了这几件事

作者简介

龙焰

OceanBase 解决方案架构师。本文根据 7 月 15 日 OB Cloud 线下巡回沙龙深圳站的现场演讲整理而成(节选)。

在日常使用数据库时,除了 OLTP 业务场景,也会有一些额外的数据分析类型的需求。但是 MySQL 的分析能力较弱,当你敲下一个复杂 SQL ,往往等到超时都没有获取结果。偏分析的 SQL 易成为慢 SQL ,影响整库性能。如果单独建设分析实例,又会抬高运维成本、迁移成本、人力成本,并且稳定性也难以保障。


OceanBase 具备企业级的优化器,准确的信息统计和可靠的 CBO 能力,支持向量化引擎和并行执行引擎。同时, OceanBase 的 HTAP 能力可以使用同一份数据、同一个引擎,帮助企业达成 TP 和 AP 两个层面的业务需求。

图片

HTAP 混合事务与实时分析处理

OceanBase 的 HTAP 能力是用一套系统同时承载 OLTP 与 OLAP 业务模式,可以帮助企业实现部分复杂的关联查询、聚合查询、排序查询场景,运维人员无需另行维护一套分析型数据库产品。这种实时分析的能力主要基于OceanBase 的企业级优化器、底层存储优化、并行执行引擎以及向量化引擎,利用一套系统、一份数据, all in one 实现。


OceanBase 提供了多种资源隔离方式:

1、租户间的隔离能力,即把 TP 和 AP 业务分为两个租户分别承载。

2、同一租户下可使用集群的从副本承载分析请求。OceanBase 提供只读地址,让一些分析场景使用弱一致性读获取结果,免除了主副本的压力。

3、同一租户下根据不同的 SQL 或用户做细粒度资源隔离。OceanBase 具备类似 Oracle resource manager 的能力,目前支持 CPU 和 IO 隔离。  

图片

OceanBase HTAP 架构

OceanBase 的 HTAP 架构如下图所示。在资源隔离方面, OceanBase 可以做 AP 和 TP 的租户隔离,也可进行用户级别甚至 SQL 级别的隔离。通过基于代价模型、可靠统计信息、高效查询优化和查询改写的 SQL 引擎, OceanBase 把复杂的 SQL 转化为可高效执行的模式,充分利用底层的单机引擎、向量化引擎以及并行执行引擎实现整个 HTAP 能力。存储引擎上支持行存、列存以及行列混存。 

图片

图片

并行执行

当一驾马车一匹马拉不动的时候,就要用多匹马来拉。优化器把一条 query 用协调器 QC 做任务拆解调度,即把一个较大的任务拆分为多个细小任务,启动多个线程来并行处理这些小任务,最终整合起来为用户提供结果数据。目前 OceanBase 支持的并行种类包括并行查询、并行 DDL 以及并行 DML 。开启并行执行的方法有多种:

1、用类似 oracle parallel hint 在 SQL 层面指定

2. 在建表的时候指定一个表的并行度

3. 针对分区表会自动开启并行模式

4、使用 OceanBase 4.0 以后的版本支持 autoDOP ,即自动感知查询类型,打开并行模式并自动调整并行度

图片

向量化引擎

在存储层面,数据库微块的内部是列存、微块之间是行存。数据经过投影过滤和扫描,在传统模型上是逐行返回,而在向量化引擎上是整批返回。OceanBase 基于以下方式实现向量化:

1、批量接口以及高效的内存布局

2、 SIMD 加速和预取加速

3、 Cache-aware  的算法
4、基于编码的 Filter 下压计算

图片

图片

HTAP 助力跑批业务

以下图 AP 场景为例,该任务分为三个步骤。

步骤一:往临时表 TMP1 中插入多个表关联查询结果;

步骤二:往临时表 TMP2 中插入临时表 TMP1 和 E 表的关联和聚合查询结果;

步骤三:往最终表里插入临时表 TMP2 和表 F /表 G 的关联结果。

每个步骤都会产生大量的结果集( 10 亿条 INSERT INTO SELECT 操作)。这个过程主要有两个挑战,第一是读取量、写入量非常大,第二是临时表的统计信息没有被及时收集的话,会给优化器选择最优执行计划造成极大困难。

OceanBase 在批量写入的时候就已经收集了统计信息,所以可以根据准确的统计信息实施最优计划生成,进而能够更快得到分析结果。 

图片

猜你喜欢

转载自blog.csdn.net/OceanBaseGFBK/article/details/132672207