浅析OceanBase数据库的向量化执行引擎

OceanBase数据库官方博客2024-09-22 19:08

本篇博客是偏数据库系统概念性的内容，不会深入到 OceanBase 中各个算子和表达式的在向量化中的详细设计和实现。

背景

为了提升OceanBase社区版用户解决问题的效率，OceanBase官方不久前推出了《OceanBase 从入门到实践》系列课程。在第七期直播课程后，我们收到了不少用户的提问，表示在查阅学习资料或笔记时，对其中提到的诸如"rowset=16"或"rowset=256"这样的信息存在理解上的困惑，不清楚这其具体含义。如下代码中的示例。这里的 rowset 信息和 OceanBase 执行引擎的向量化执行技术相关，这篇博客就正好作为 AP 性能专题的内容之一，在解答这个用户问题的同时，也为大家介绍一下 OceanBase 执行引擎的向量化执行技术。

obclient [test]> create table t1(c1 int, c2 int);
Query OK, 0 rows affected (0.203 sec)

obclient [test]> explain select count(*) from t1 where c1 = 1000;
+------------------------------------------------------------------------------------+
| Query Plan                                                                         |
+------------------------------------------------------------------------------------+
| =================================================                                  |
| |ID|OPERATOR         |NAME|EST.ROWS|EST.TIME(us)|                                  |
| -------------------------------------------------                                  |
| |0 |SCALAR GROUP BY  |    |1       |4           |                                  |
| |1 |└─TABLE FULL SCAN|t1  |1       |4           |                                  |
| =================================================                                  |
| Outputs & filters:                                                                 |
| -------------------------------------                                              |
|   0 - output([T_FUN_COUNT_SUM(T_FUN_COUNT(*))]), filter(nil), rowset=16            |
|       group(nil), agg_func([T_FUN_COUNT_SUM(T_FUN_COUNT(*))])                      |
|   1 - output([T_FUN_COUNT(*)]), filter([t1.c1 = 1000]), rowset=16                  |
|       access([t1.c1]), partitions(p0)                                              |
|       is_index_back=false, is_global_index=false, filter_before_indexback[false],  |
|       range_key([t1.__pk_increment]), range(MIN ; MAX)always true                  |
+------------------------------------------------------------------------------------+
14 rows in set (0.033 sec)

火山模型执行引擎

向量化执行引擎是提升 AP 能力的利器之一，也为 2021 年 OceanBase TPCH 打榜夺冠做出了重要贡献。不过如果要学习向量化引擎，首先需要了解一下传统的数据库执行引擎模型 ------ 火山模型。

火山模型（Volcano Model）也被称为迭代模型（Iterator Model），是最著名的查询执行模型，早在 1990 年就在论文《Volcano, an Extensible and Parallel Query Evaluation System》中被提出。大多数关系型数据库都采用了这种模型，例如 Oracle、MySQL、DB2、SQLServer 等等。

在火山模型中，一个查询计划会被分解为多个算子（Operator）。每个算子就是一个迭代器，都要实现一个 next() 接口，通常包括三个步骤：

    • 调用儿子算子的 next() 方法，获取儿子算子返回的计算结果；
    • 对儿子算子返回的计算结果，执行当前算子的计算动作，得到计算结果；
    • 返回一行计算结果给父亲算子。

说明：
论文里算子的的 next() 接口，在 OceanBase 的代码里叫 ObOperator::get_next_row()。

通过火山模型，查询执行引擎可以优雅地将任意算子组装在一起，而不需要考虑每个算子的具体处理逻辑。查询执行时会由查询树自顶向下嵌套调用 get_next_row() ，数据则自底向上地被拉取处理。所以，这种处理方式也称为拉取执行模型（Pull Based）。为了更好地理解火山模型的拉取执行过程，这里继续看上面这个聚合计算的例子：

select count(*) from t1 where c1 = 1000;

说明：

图中的 Tuple 是一个元组，也就是下层算子向上层算子返回的一个计算结果行。

如上图所示：

    • 步骤 1 - 步骤 3，聚合算子 Aggregate 先通过调用 get_next_row() 方法触发下面这些算子逐层调用孩子算子的 get_next_row() 方法。
    • 步骤 4 - 步骤 6，TableScan 算子获取到存储层的数据，吐行给 Filter 算子，Filter 算子完成过滤条件 c1 = 1000 的计算，吐结果行给负责聚合计算的 Aggregate 算子。
    • 步骤 7，Aggregate 算子通过反复调用 next 方法获取到需要的一批数据，最终完成聚合计算，返回计算结果。

把 OceanBase 的向量化开关关掉，就可以看到类似于上图的执行计划树。

-- 关掉向量化开关，让后面的 SQL 默认走类似于火山模型的单行计算模式
alter system set _rowsets_enabled = false;

-- 大家可以发现，在下面这个计划里，看不到类似于上面那个计划里的 rowset 值了
explain select count(*) from t1 where c1 = 1000;
+------------------------------------------------------------------------------------+
| Query Plan                                                                         |
+------------------------------------------------------------------------------------+
| =================================================                                  |
| |ID|OPERATOR         |NAME|EST.ROWS|EST.TIME(us)|                                  |
| -------------------------------------------------                                  |
| |0 |SCALAR GROUP BY  |    |1       |6           |                                  |
| |1 |└─TABLE FULL SCAN|t1  |1       |6           |                                  |
| =================================================                                  |
| Outputs & filters:                                                                 |
| -------------------------------------                                              |
|   0 - output([T_FUN_COUNT_SUM(T_FUN_COUNT(*))]), filter(nil)                       |
|       group(nil), agg_func([T_FUN_COUNT_SUM(T_FUN_COUNT(*))])                      |
|   1 - output([T_FUN_COUNT(*)]), filter([t1.c1 = 1000])                             |
|       access([t1.c1]), partitions(p0)                                              |
|       is_index_back=false, is_global_index=false, filter_before_indexback[false],  |
|       range_key([t1.__pk_increment]), range(MIN ; MAX)always true                  |
+------------------------------------------------------------------------------------+
14 rows in set (0.010 sec)

OceanBase 的计划只有两个算子，比上面这张图上的看上去更简单些。因为 OceanBase 中的每一个算子都包含了 Filter 的功能，所以不需要独立的 Filter 算子。可以在上面的计划里看到，TABLE SCAN 算子里也有 filter([t1.c1 = 1000]) 的信息。计划里的 SCALAR GROUP BY 算子就是负责不需要进行 group by 分组的聚合计算，对应图中的 Aggregate 算子。

火山模型的优点是处理逻辑清晰，每个算子只要关心自己的处理逻辑即可，耦合性低。但是它的缺点也非常明显，主要是两点：

    • get_next_row() 虚函数在每个算子处理每行数据时都要调用一次，调用次数过多，造成 CPU 资源的浪费。在 OLAP 查询数据量大的场景中，问题尤为明显。
    • 数据以行为单位进行处理，不利于充分发挥现代 CPU 的特性。

向量化执行引擎及其优势

向量化模型最早是在 MonetDB-X100（Vectorwise）系统的论文 《MonetDB/X100: Hyper-Pipelining Query Execution》中提出的，不同于传统的火山模型按行迭代的方式，向量化引擎采用按批迭代方式，可以在算子间一次传递一批数据。向量化引擎被提出后，因为可以有效提高 CPU 利用率并充分发挥现代 CPU 的特性，很快就被广泛应用到了现代数据库引擎设计中。

如上图所示，与数据库传统的火山模型迭代类似，向量化模型也是通过 PULL 模式从算子树的根节点层层拉取数据。区别于 get_next_row() 调用一次传递一行数据，向量化引擎通过 get_next_batch() 一次传递一批数据，并尽量保证该批数据在内存上紧凑排列。

减少虚函数调用的开销

向量化引擎第一个显而易见的优势，就是大幅减少了框架函数的调用次数。假设一张表有 1 亿行数据，按火山模型的处理方式，每个算子均需要执行 1 亿次 get_next_row() 的迭代才能完成查询。如果使用向量化引擎，假设一个向量的大小为 1024 行数据，那么在同样的查询中，get_next_batch() 的调用次数会小于 10 万次（ 1 亿 / 1024 = 97657 ），大大降低了虚函数调用次数，节省了 CPU 的开销。

在本文开头的用户问题里，计划中的 rowset 就是表示一个 batch（或者叫一个向量）中有多少行数据。

-- 打开向量化开关
alter system set _rowsets_enabled = true;

-- 设置每个向量的大小是 16 行
alter system set _rowsets_max_rows = 16;

-- 计划中可以看到执行时的向量值大小（rowset=16）
explain select count(*) from t1 where c1 = 1000;
+------------------------------------------------------------------------------------+
| Query Plan                                                                         |
+------------------------------------------------------------------------------------+
| =================================================                                  |
| |ID|OPERATOR         |NAME|EST.ROWS|EST.TIME(us)|                                  |
| -------------------------------------------------                                  |
| |0 |SCALAR GROUP BY  |    |1       |4           |                                  |
| |1 |└─TABLE FULL SCAN|t1  |1       |4           |                                  |
| =================================================                                  |
| Outputs & filters:                                                                 |
| -------------------------------------                                              |
|   0 - output([T_FUN_COUNT_SUM(T_FUN_COUNT(*))]), filter(nil), rowset=16            |
|       group(nil), agg_func([T_FUN_COUNT_SUM(T_FUN_COUNT(*))])                      |
|   1 - output([T_FUN_COUNT(*)]), filter([t1.c1 = 1000]), rowset=16                  |
|       access([t1.c1]), partitions(p0)                                              |
|       is_index_back=false, is_global_index=false, filter_before_indexback[false],  |
|       range_key([t1.__pk_increment]), range(MIN ; MAX)always true                  |
+------------------------------------------------------------------------------------+
14 rows in set (0.021 sec)

充分发挥现代 CPU 的特性

数据紧密排列，提升 Cache 友好性

OceanBase 在向量化执行过程中，会尽量保证该批数据在内存上紧凑排列，产生的中间数据会以列的形式进行组织。比如我们一个 batch 是 256 行数据, 那我们内存排布中 c1 的 256 行数据就会都连续存放, 然后 c2 的 256 行数据也连续存放, 计算 concat(c1, c2) 表达式还是 256 行一起计算，最后将结果放入到该表达式预分配的结果值的内存空间中。

由于中间数据连续，CPU 就可以通过预取指令快速把即将进行计算的数据提前加载到 L2 cache 中，以此减少 memory stall 的现象，提升 CPU 的利用率。在算子函数内部，函数也不再是一次处理一行数据，而通过批量处理连续数据的方式进行计算，可以提升 CPU DCache 和 ICache 的友好性，减少 Cache Miss。

减少分支预测失败对 CPU 流水线的破坏

论文《DBMSs On A Modern Processor: Where Does Time Go?》中介绍了分支预测失败对数据库性能的影响。由于 CPU 中断了流水执行，重新刷新流水线，因此分支预测失败对数据库处理性能的影响很大。SIGMOD13 的论文《Micro Adaptivity in Vectorwise》也对分支在不同选择率下的执行效率有详细论述，见下图。

由于数据库 SQL 引擎逻辑比较复杂，在火山模型下，条件判断逻辑出现频率普遍较高。

// 单行计算流程的伪代码，处理 256 行数据，要进行 256 次 if 的判断：
for (auto row_no : 256) {
  get_next_row() {
    if (A) {
      eval_func_A();
    } else if (B) {
      eval_func_B();
    }
  }
}

但在向量化执行时，可以在算子和表达式内部，最大限度地避免条件判断。例如避免在 for 循环内部出现 if 判断，从而避免分支预测失败对 CPU 流水线的破坏，大幅提升 CPU 的处理能力。

// 向量化计算流程伪代码，处理 256 行数据，只需要进行 1 次 if 的判断：
get_next_batch() {
  if (A) {
    for (auto row_no : 256) {
      eval_func_A();
    }
  } else if (B) {
      for (auto row_no : 256) {
      eval_func_B();
    }
  }
}

利用 SIMD 指令加速计算

由于向量化引擎处理内存连续数据，因此向量引擎可以很方便的把一批数据装载到向量寄存器中。然后通过 SIMD 指令，替换传统的标量（Scalar）算法，进行向量（Vector）计算。SIMD 指令可以使 CPU 同时对一批数据并行执行相同的计算动作，从而减少这批数据计算所需要的 CPU 的周期数。

上图右侧展示了典型的 SIMD 计算，两组四个连续存储的数据元素被并行计算，CPU 会根据 SIMD 指令，对每对相应的数据元素（A1 和 B1，A2 和 B2，A3 和 B3，A4 和 B4）同时执行相同的运算。四个并行计算的结果也会被连续存储。

假设我们的处理器支持 4 个元素的 SIMD 乘法操作，那就意味着它有特殊的寄存器（通常称为向量寄存器），可以同时存储四个整型数。因为 OceanBase 的向量化执行过程中数据会紧密存储，所以就可以按照如下流程编写 SIMD 代码：

  • 数据加载（_mm_loadu_si128）：首先，我们将向量 A1 A2 A3 A4 和 B1 B2 B3 B4 的各个元素加载到两个 SIMD 寄存器中。

  • 单一指令乘法（_mm_mullo_epi32）：接着，我们使用单一的 SIMD 乘法指令，同时对两个寄存器中的所有元素执行乘法操作。

  • 数据存储（_mm_storeu_si128）：最后，我们将结果从 SIMD 寄存器存储回为结果分配的内存中，得到结果向量。

    // SSE（针对x86架构）的 C++ 伪代码示例，使用 SIMD 技术进行整型向量的逐元素相乘
    #include <immintrin.h> // 包含 SSE 指令集头文件

    // 函数用于计算两个整型向量的逐元素相乘
    void simdIntVectorMultiply(const int* vec1, const int* vec2, int* result, size_t length) {
    // 确保向量长度是 4 的倍数，因为 SSE 寄存器一次处理 4 个 32 位整数
    assert(length % 4 == 0);

    // 使用 SSE 指令进行优化的循环
  for (size_t i = 0; i < length; i += 4) {

  // 加载四个整数到 xmm 寄存器（128位）
  __m128i vec1_simd = _mm_loadu_si128(reinterpret_cast<const __m128i*>(vec1 + i));
  __m128i vec2_simd = _mm_loadu_si128(reinterpret_cast<const __m128i*>(vec2 + i));

  // 执行向量乘法
  __m128i product_simd = _mm_mullo_epi32(vec1_simd, vec2_simd);

  // 存储结果回内存
  _mm_storeu_si128(reinterpret_cast<__m128i*>(result + i), product_simd);
}

    }

TPCH 性能测试

利用 TPCH 30T 数据集对 OceanBase 数据库进行 TPCH 测试，向量化执行模式相比单行执行模式，执行性能整体可以提升 2.48 倍。对于计算密集的 Q1 查询, 性能提升可以达到 10 倍以上。

在最新的 4.3 版本中，OceanBase 还对从 3.x 版本就已经支持的向量化执行引擎，进行了一次新的优化和重构，详细介绍和性能测试可以参考：这篇博客。

结语

这篇博客是 OceanBase 向量化执行引擎入门级的介绍，希望无论是 DBA 同学，还是内核研发同学，在阅读之后都能够有所收获。如果大家希望继续和作者讨论有关向量化执行的任何问题，都欢迎在这篇博客的评论区进行留言，我会第一时间对大家的问题进行回复。

相关推荐
OceanBase数据库官方博客10 小时前
半连接转内连接 | OceanBase SQL 查询改写
sql·oceanbase·分布式数据库
OceanBase数据库官方博客17 小时前
解析在OceanBase创建分区的常见问题｜OceanBase 用户问题精粹
oceanbase·分布式数据库·分区
OceanBase数据库官方博客17 小时前
半连接转内连接规则的原理与代码解析 |OceanBase查询优化
sql·oceanbase·分布式数据库
小Tomkk18 小时前
火山引擎FORCE：智算能力全面升级
android·数据库·火山引擎
IT培训中心-竺老师4 天前
OceanBase 数据库分布式与集中式 能力
数据库·分布式·oceanbase
靖顺4 天前
【OceanBase 诊断调优】—— OceanBase 数据库网络速率配置方案
网络·数据库·oceanbase
尚雷558011 天前
OceanBase 社区版 4.0 离线方式升级bp1至bp2 指南（含避坑总结）
oceanbase
五月高高11 天前
Linux部署oceanbase
linux·oceanbase
靖顺15 天前
【OceanBase 诊断调优】—— 统计信息自动收集超时导致的估行不准 SQL 选择错索引
数据库·sql·oceanbase
热门推荐
01ARM学习（31）编译器对overlay方式的支持02YOLOv8训练好模型后，追加轮数继续训练、或者提前终止训练，缩减训练轮数03玄机平台应急响应—webshell查杀04SQL 主从数据库实时备份05HCIA-datacom数通题库和录播视频资料06Docker 夺命连环 15 问07VSCode插件 —— Cody AI （免费AI助手！）08校验 GPT-4 真实性的三个经典问题：快速区分 GPT-3.5 与 GPT-4，并提供免费测试网站09(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明10组基轨迹建模 GBTM的介绍与实现（Stata 或 R）