PolarDB-X源码解读系列:DML之Insert流程

2022/7/29 1:23:00

本文主要是介绍PolarDB-X源码解读系列:DML之Insert流程,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

简介: Insert类的SQL语句的流程可初略分为:解析、校验、优化器、执行器、物理执行(GalaxyEngine执行)。本文将以一条简单的Insert语句通过调试的方式进行解读。

在阅读本文之前,强烈建议先阅读《PolarDB-X源码解读系列:SQL 的一生》,能够了解一条SQL的执行流程,也能知道GalaxySQL(CN)的各个组件,然后再阅读本文,了解Insert的具体实现过程,加深各个组件的理解。
Insert类的SQL语句的流程可初略分为:解析、校验、优化器、执行器、物理执行(GalaxyEngine执行)。本文将以一条简单的Insert语句通过调试的方式进行解读。
建表语句:

 

#一个简单的PolarDB-X中的分库分表sbtest

CREATE TABLE `sbtest` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`k` int(11) NOT NULL DEFAULT '0',

`c` char(120) NOT NULL DEFAULT '',

`pad` char(60) NOT NULL DEFAULT '',

PRIMARY KEY (`id`)

)dbpartition by hash(`id`) tbpartition by hash(`id`) tbpartitions 2;

 

#调试语句

insert into sbtest(id) values(100);

 

解析

 

连接上PolarDB-X后,执行一条Insert语句insert into sbtest(id) values(100);PolarDB-X接收到该字符串语句后,开始执行该SQL,可见TConnection#executeSQL:

准备执行该SQL语句,ExecutionContext会保留该Sql执行的参数、配置、等上下文信息,该变量会一直陪伴该Sql经过解析、校验、优化器、执行器,直到下发给GalaxyEngine(DN)。
PolarDB-X执行该SQL时,需要先获取执行计划,可见代码TConnection#executeQuery:

 

ExecutionPlan plan = Planner.getInstance().plan(sql, executionContext);

 

为了避免执行同一条SQL每次都要解析、校验、优化器等操作,PolarDB-X内置了PlanCache,会在PlanCache中获取该SQL的执行计划,当然,并不是根据纯字符串SQL来进行缓存,而是生成SqlParameterized,如下图所示(Planner#plan),真正缓存的是sql模板,该类中的sql变量:INSERT INTO sbtest (id)\nVALUES (?),可适用于类似的语句,代表可填入的值,不同的值都是同一类SQL语句。

如果PlanCache找不到的话,需要生成新的执行计划,具体代码见PlanCache#getFromCache:

先将字符串通过FastsqlParser解析成抽象语法树,检查有没有语法错误等,生成SqlNode,本条SQL是Insert语句,解析成SqlInsert类,然后继续根据抽象语法树获取执行计划,具体SqlInsert内容为:

简单解释几个变量:

 

  • keywords:关键字,例如:Insert Ignore语句会加Ignore关键字,代表该语句特征;
  • source:数据来源,插入数据的来源,这里是values,如果是 Insert ... Select语句,则是select语句;
  • updateList:修改信息,例如:Insert ... ON DUPLICATE KEY 语句会把修改信息保存在该变量;

 

至此,完成了字符串SQL语句到SqlNode的转变,即完成了解析部分。

 

校验

 

校验过程即检查SqlNode的语义是否正确,例如表是否存在、列是否存在、类型是否正确等等,具体入口在Planner#getPlan函数中:

 

SqlNode validatedNode = converter.validate(ast);

 

便是验证该SQL的有效性,PolarDB-X沿用了Apache Calcite框架,validate的实现也是类似的大框架,包含Scope和Namespace两个概念,在此基础上进行验证,SqlInsert类型的验证入口在SqlValidatorImpl#validateInsert(SqlInsert insert)中:

 

...

final SqlValidatorNamespace targetNamespace = getNamespace(insert);

validateNamespace(targetNamespace, unknownType);

...

final SqlNode source = insert.getSource();

if (source instanceof SqlSelect) {

   final SqlSelect sqlSelect = (SqlSelect) source;

   validateSelect(sqlSelect, targetRowType);

} else {

   final SqlValidatorScope scope = scopes.get(source);

   validateQuery(source, scope, targetRowType);

}

...

 

大体流程检查两个部分:首先,检查insert into sbtest语句是否正确;然后检查SqlInsert.source部分是否有效。本条SQL是Values,所以检查Values是否有效,如果是Insert ...Select语句,source是SqlSelect,需要检查Select语句是否有效。没有报错,则说明SQL语句语义没有错误,校验通过,可以发现还是SqlInsert:

 

优化器

 

在经过优化器之前,还需要将SqlNode(SqlInsert)转成RelNode,大体含义就是将sql语法树转成关系表达式,入口在Planner#getPlan:

 

RelNode relNode = converter.toRel(validatedNode, plannerContext);

 

具体转换过程在SqlConverter#toRel:

 

...

final SqlToRelConverter sqlToRelConverter = new TddlSqlToRelConverter(...);

RelRoot root = sqlToRelConverter.convertQuery(validatedNode, false, true);

...

 

TddlSqlToRelConverter类是PolarDB-X的转换器,继承Calcite的SqlToRelConverter类,转换SqlInsert的执行过程在TddlSqlToRelConverter#convertInsert(SqlInsert call):

 

RelNode relNode = super.convertInsert(call);

if (relNode instanceof TableModify) {

   ...

}

 

可以发现, 会调用SqlToRelConverter#convertInsert,在该方法中,会将SqlInsert转成LogicalTableModify,该类的内容如下:

可以注意到几个变量:operation:操作类型;input:输入来源,本条sql是values;
PolarDB-X内部还有新的自己的RelNode,所以还会把RelNode再转成自己定义的RelNode,入口在Planner#getPlan:

 

ToDrdsRelVisitor toDrdsRelVisitor = new ToDrdsRelVisitor(validatedNode, plannerContext);

RelNode drdsRelNode = relNode.accept(toDrdsRelVisitor);

 

转换过程在ToDrdsRelVisitor#visit(RelNode other):

 

if ((other instanceof LogicalTableModify)) {

...

    if (operation == TableModify.Operation.INSERT || ...) {

        LogicalInsert logicalInsert = new LogicalInsert(modify);

        ...

    }

}

 

Insert类型会转成LogicalInsert,就是PolarDB-X内部的RelNode,执行也是基于该类,LogicalInsert的内容如下(还有部分变量不在截图中):

大多数变量和LogicalTableModify一样,新增了像PolarDB-X特有的gsi相关变量等等。
然后便是经过优化器阶段,优化器执行过程代码在Planner#sqlRewriteAndPlanEnumerate:

 

private RelNode sqlRewriteAndPlanEnumerate(RelNode input, PlannerContext plannerContext) {

   CalcitePlanOptimizerTrace.getOptimizerTracer().get().addSnapshot("Start", input, plannerContext);

//RBO优化

   RelNode logicalOutput = optimizeBySqlWriter(input, plannerContext);

   CalcitePlanOptimizerTrace.getOptimizerTracer().get()

       .addSnapshot("PlanEnumerate", logicalOutput, plannerContext);

 

   //CBO优化

   RelNode bestPlan = optimizeByPlanEnumerator(logicalOutput, plannerContext);

 

   // finally we should clear the planner to release memory

   bestPlan.getCluster().getPlanner().clear();

   bestPlan.getCluster().invalidateMetadataQuery();

   return bestPlan;

}

 

Insert的优化器主要在RBO过程,定义了一些规则,CBO规则对Insert几乎没有改变。可以重点关注RBO的OptimizeLogicalInsertRule规则,会根据GMS(PolarDB-X的元数据管理)的信息来判断该SQL的执行计划,可能会将LogicalInsert转变成其它的RelNode去执行,方便区分不同的SQL执行方式,首先会确定该SQL的执行策略,主要分为三种:

 

public enum ExecutionStrategy {

/**

    * Foreach row, exists only one target partition.

    * Pushdown origin statement, with function call not pushable (like sequence call) replaced by RexCallParam.

    * Typical for single table and partitioned table without gsi.

    */

   PUSHDOWN,

   /**

    * Foreach row, might exists more than one target partition.

    * Pushdown origin statement, with nondeterministic function call replaced by RexCallParam.

    * Typical for broadcast table.

    */

   DETERMINISTIC_PUSHDOWN,

   /**

    * Foreach row, might exists more than one target partition, and data in different target partitions might be different.

    * Select then execute, with all function call replaced by RexCallParam.

    * Typical for table with gsi or table are doing scale out.

    */

   LOGICAL;

};

 

由于本条SQL较为简单,策略是PUSHDOWN,处理过程也比较简单,然后生成InsertWriter,该类负责生成下发到DN的SQL语句,保存在LogicalInsert中,OptimizeLogicalInsertRule处理规则较为细节,感兴趣的可以自行查看onMatch方法。
经过优化器后,还是LogicalInsert类的RelNode,至此,意味着优化器执行完毕。
最终会生成执行计划,在PlanCache#getFromCache,见下图(图中非全部变量):

ExecutionPlan.plan就是执行计划,可以发现是LogicalInsert,对于简单的Insert,PolarDB-X还会改写执行计划,代码在PlanCache#getFromCache:

 

BuildFinalPlanVisitor visitor = new BuildFinalPlanVisitor(executionPlan.getAst(), plannerContext);

executionPlan = executionPlan.copy(executionPlan.getPlan().accept(visitor));

 

insert into sbtest(id) values(100);语句执行BuildFinalPlanVisitor#buildNewPlanForInsert(LogicalInsert logicalInsert, ExecutionContext ec),因为该Insert语句比较简单,只有一个values,包含拆分键和auto_increment列,只需要根据拆分键就能确定下发到DN的哪一个分片,在CN端无需更多操作,所以会简化执行计划,在BuildFinalPlanVisitor#buildSingleTableInsert转成SingleTableOperation,并保存了分库分表规则,最终的执行计划如下:

执行计划变成SingleTableOperation,至此,执行计划生成完毕。

 

执行器

 

SQL语句生成执行计划后,将由执行器进行执行,执行入口在TConnection#executeQuery:

 

ResultCursor resultCursor = executor.execute(plan, executionContext);

 

然后会由ExecutorHelper#execute方法执行ExecutionPlan.plan,也就是前面的SingleTableOperation,执行策略有CURSOR、TP_LOCAL、AP_LOCAL、MPP,Insert类型基本都是走CURSOR,接着根据执行计划拿对应的Handler进行处理,具体可查看CommandHandlerFactoryMyImp类,例如:SingleTableOperation是MySingleTableModifyHandler,LogicalInsert是LogicalInsertHandler。会在对应的Handler里面进行执行,一般会返回一个Cursor,Cursor里面会调用真正的执行过程,调用Cursor.next便会获取结果,Insert语句的结果是affect Rows,本条SQL会创建一个
MyPhyTableModifyCursor,入口在MySingleTableModifyHandler#handleInner:

 

...

MyPhyTableModifyCursor modifyCursor = (MyPhyTableModifyCursor) repo.getCursorFactory().repoCursor(executionContext, logicalPlan);

...

affectRows = modifyCursor.batchUpdate();

...

 

根据ExecutionContext和SingleTableOperation创建一个MyPhyTableModifyCursor,然后直接执行:

 

public int[] batchUpdate() {

   try {

       return handler.executeUpdate(this.plan);

   } catch (SQLException e) {

       throw GeneralUtil.nestedException(e);

   }

}

 

这里的this.plan就是SingleTableOperation,handler是PolarDB-X的CN与DN间交互的MyJdbcHandler,可以认为是执行物理计划的handler,会根据plan生成真正的物理SQL,下发到DN执行。
由于这条SQL较为简单,CN不需要过多处理,再举一例Insert语句:insert into sbtest(k) values(101),(102);
经过优化器后,该语句的执行计划是LogicalInsert,如下图:

可以发现sqlTemplate为INSERT\nINTO ? (id,k)\nVALUES(?, ?),表名可能要换成物理表名,同时增加了一列id,因为该列是auto_increment,会有一个全局的sequence表来记录该列的值,才能保证全局唯一,插入的values的参数保留在ExecutionContext的params中,如下图:

id列的值会在真正生成物理执行计划的时候才会去获取,LogicalInsert计划适用LogicalInsertHandler来执行,执行过程:

 

public Cursor handle(RelNode logicalPlan, ExecutionContext executionContext){

   ...

   LogicalInsert logicalInsert = (LogicalInsert) logicalPlan;

   ...

   if (!logicalInsert.isSourceSelect()) {

       affectRows = doExecute(logicalInsert, executionContext, handlerParams);

   } else {

       affectRows = selectForInsert(logicalInsert, executionContext, handlerParams);

   }

   ...

}

 

会根据来源是否是Select语句选择不同的执行方式,具体执行过程在LogicalInsertHandler#executeInsert,如下:

 

...

//生成主表的物理执行计划

final InsertWriter primaryWriter = logicalInsert.getPrimaryInsertWriter();

List inputs = primaryWriter.getInput(executionContext);

...

//如果有GSI,生成GSI表的物理执行计划

final List gsiWriters = logicalInsert.getGsiInsertWriters();

gsiWriters.stream().map(gsiWriter -> gsiWriter.getInput(executionContext))...;

...

//执行所有物理执行计划

final int totalAffectRows = executePhysicalPlan(allPhyPlan, executionContext, schemaName, isBroadcast);

...

 

主表生成物理执行计划过程中,会先获取id的值,由于id也是拆分键,所以两个values会根据拆分键定位到不同的物理分库分表上,会生成有两个物理执行计划,如下:


其中dbIndex是物理库名,tableNames是物理表名,param保存了这条slqTemplate的参数值,填充上就是完整的SQL,然后执行所有物理执行计划,就完成了该SQL的执行。

 

物理执行

 

PolarDB-X中CN与DN的交互都在MyJdbcHandler中,以SingleTableOperation为例,看看具体交互过程:

 

public int[] executeUpdate(BaseQueryOperation phyTableModify) throws SQLException {

...

   //获取物理执行计划的库名和参数

   Pair> dbIndexAndParam =

           phyTableModify.getDbIndexAndParam(executionContext.getParams() == null ? null : executionContext.getParams()

               .getCurrentParameter(), executionContext);

...

   //根据库名获取连接

   connection = getPhyConnection(transaction, rw, groupName);

...

    //根据参数组成字符串SQL

    String sql = buildSql(sqlAndParam.sql, executionContext);

...

    //根据连接创建prepareStatement

    ps = prepareStatement(sql, connection, executionContext, isInsert, false);

...

    //设置参数

    ParameterMethod.setParameters(ps, sqlAndParam.param);

...

    //执行

    affectRow = ((PreparedStatement) ps).executeUpdate();

...

}

 

将物理执行计划发送到DN执行,执行完成后,根据affectRow返回到执行器,最终会把结果返回给用户,至此,一条完整SQL就执行完成。

 

小结

 

本文通过调试简单的Insert语句,介绍了PolarDB-X在解析、校验、优化器、执行器对Insert语句的处理,当然,Insert语句也有很多特殊的用法,本文并没有一一概述,感兴趣的同学可以在相应代码处进行查看。

原文链接:http://click.aliyun.com/m/1000350629/ 本文为阿里云原创内容,未经允许不得转载。

这篇关于PolarDB-X源码解读系列:DML之Insert流程的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程