海量智库第5期｜Vastbase G100核心技术介绍之【SQL by pass技术】

[Vastdata_Beijing]

导语

SQL by pass的主要作用是针对某些简单的SQL生成的查询计划。如果查询计划是一个符合特定条件的查询计划，那么可以跳过原有迭代器模型的执行步骤，直接执行查询计划，将原有查询计划的初始化、执行、终结三个步骤集中到一个相邻的代码逻辑中执行，从而缩短了代码路径，使得热代码更加集中，最终能够加速查询计划的执行。

SQL by pass的核心原理

在传统关系数据库中，对于SQL处理一般分为三个阶段：

Ø 词法语法分析：主要是将用户的输入文本（SQL）转化成一个内部的数据结构，一般称之为语法解析树，并验证语法的正确性，最终得到一个表示SQL的语法解析树。

Ø 查询优化：将前一个阶段的语法解析树，进行基于规则以及基于物理代价的优化，生成一个最优的查询计划。

Ø 执行查询计划：将前一阶段生成的查询计划予以执行（一般采用迭代器的方式），将结果返回给用户。

为了加速SQL的处理，针对前两个阶段，一般使用类似query plan cache的方式，以避免对SQL进行重复的解析和生成查询计划，例如使用常见的PBE方式（prepare bind execute）。

对于第三个阶段，为了加速查询计划的执行，在很多数据库中采用了基于LLVM的JIT技术，这种主要是在典型的OLAP应用中，针对特定的逻辑生成固定的字节码，提高CPU的执行效率。而在我们面对的OLTP场景中，创新的使用了SQL by pass来提高查询计划的执行效率。

SQL by pass的主要作用

SQL by pass的主要作用是针对某些简单的SQL生成的查询计划。如果查询计划是一个符合特定条件的查询计划，那么可以跳过原有的迭代器模型的执行步骤，直接执行查询计划，将原有查询计划的初始化、执行、终结三个步骤集中到一个相邻的代码逻辑中执行，从而缩短了代码路径，使得热代码更加集中，最终能够加速查询计划的执行。

查询计划只能是满足下列条件的update insert delete select 语句的查询计划：

·不能有子查询；

·对于select语句，查询计划的最上层节点只能是一个index scan或是index only scan节点,如果SQL语句中出现limit 以及offset，则limit和offset语句的参数必须是一个大于0的整数；

·对于insert语句，必须只有一个结果表，并且只能有一个plan节点，并且不能有UPSERT操作，结果列的类型只能是基础类型，对结果表不能有DML操作；

·对于update语句或是delete语句，不能有UPSERT操作，也不能有排序，必须只有一个结果表，并且最上层节点只能有一个plan节点，这个节点也只能是index scan或是index only scan。

 

SQL by pass的使用过程

Ø 首先，我们创建一张表test_bypass_sq1，并在后两个字段上建立索引。

 

Ø 然后我们可以看到简单插入一条数据的时候，就使用了SQL by pass的加速，因为这个插入操作的执行计划满足我们前面提到的条件：

Ø 注意，会话级别的参数enable_opfusion控制是否开启SQL by pass这个特性，目前是默认打开。当我们关闭这个参数之后，就会发现相同的操作有了不同的执行过程：

Ø 因此，没有特殊情况，记得一定不要将该会话参数设置为off。

对于一些简单的select 操作，除了enable_opfusion这个参数外，我们需要额外设置一些参数，使得生成查询计划的顶层节点上是index scan或是index only scan，才能最终使用SQL by pass方式来执行。

我们在向test_bypass_sq1插入3条数据之后，执行下面的SQL，可以看到并未使用SQL by pass:

Ø 因为使用了bitmap scan来扫描表，我们禁止掉bitmap scan之后，依然没有使用SQL by pass：

Ø 因为优化器选择了seq scan。我们禁止优化器选择seq scan之后：

Ø 优化器为test_bypass_sq1这个表选择了index scan，最终执行时，使用了SQL by pass的执行方式。

同理，对于下面的SQL，优化器为test_bypass_sq1这个表生成了index only scan，最终执行时，执行引擎使用SQL by pass方式来加速执行：

Ø 而对于一些复杂的查询，则不能使用SQL by pass：

Ø 因为生成的查询计划的最上层节点不是所预期的index scan 或是index only scan 节点，而是一个aggregate节点。

因此，在使用SQL by pass特性时，我们需要关注上述参数、以及该特性对于查询计划的要求，使得优化器能够生成满足SQL by pass的查询计划，最终执行引擎能够使用该技术来加速查询计划的执行。

使用SQL by pass前后对比

为了对比SQL by pass技术对性能的提升作用，我们采用了如下硬件配置：

1.cpu，kenpeng920，64核*2

2.内存，32GB *24

3.硬盘，3.2TB*4

4.网卡，25GE光纤网卡

使用Vastbase G100数据库，根据TPCC 1000仓，分别针对打开与关闭SQL by pass时，获取tpmC进行性能对比；下面是实际的性能数据：

性能测试数据

通过测试结果，可以看到：

打开了SQL by pass之后，性能提升了15%左右。

 

【海量智库】

海量数据最新成立的技术专栏

我们会定期为大家输送技术干货文章

欢迎更多技术人员

与我们探讨交流

稿件请投递：[e-mail]

[motangup]

干货赞一个