逻辑查询计划重构优化

       目前，IoTDB在查询引擎的逻辑查询计划上主要存在以下几个问题：

2.1.1 存在问题

• 类继承关系设计不合理

       如下图2.2所示，当前逻辑查询运算符 QueryOperator 继承自SFWOperator，后者代表由Select、From、Where三个子句组成的逻辑运算符。一般来说，只有查询语句会同时包含这三个部分。但是由于IoTDB特殊的数据模型，Select子句中会包含时间序列的后缀路径，而From子句中会包含时间序列的前缀路径，为了能够简便的使用Select或From运算符中的路径存储结构，Insert或Delete等语句的逻辑运算符也继承了这一基类。这种继承关系的抽象显然是不合理的，造成了结构的混乱和存储的冗余，应该根据每个语句的实际情况增加相应的成员变量，例如DeleteDataOperator内只需要增加完整路径的数组即可。

...

图2.4 SelectOperator内部存储结构图

2.1.2 解决方案

       首先，Insert和Delete等运算符继承SFWOperator是没有必要的，因此计划为其增加需要的路径变量后，直接作为基类Operator的子类。此时，只有QueryOperator继承自SFWOperator，因此可以将SFWOperator内部的成员变量，即Select、From、Where部分，直接移至QueryOperator，从而移除SFWOperator。

...

       我们首先来看由第四部分确定的4种查询，这四种查询的主要区别在于特殊声明部分不同。我们计划先将所有查询共有的特殊声明部分抽象为SpecialClauseComponent，其中包括行数限制，行偏移量限制，是否需要包含空值列等信息。然后，再分别为这四种查询建立特殊声明子类，存储这些查询特有的信息。需要特别说明的是，AlignByDevice即按设备对齐查询是IoTDB为了满足用户对于关系表的需要设计的另一种结果集展示方式，其以时间和设备为主键，先按设备对齐，设备内再按时间对齐。该查询本质上可能是任意查询，差别仅在于结果集展示方式的不同。因此，我们计划将其作为特殊声明基类中的一个公共字段，可以与任何查询作笛卡尔积，而不是作为一个单独的特殊声明子类。Image Removed      

Image Added      

图2.6 特殊声明部分类继承结构图

       接着来看由第一部分确定的四种查询，这四种查询的主要区别自在于Select部分的对外表现不同，例如原始数据查询只包含时间序列路径，而聚合查询中还包含聚合函数。我们计划将原本分开的部分抽象为一个整体ResultColumn类，其可以根据Select部分有不同的子类表现形式，具体如下图所示（具体见宇荣部分）：

...

       最后，我们得到的整体的类图，如下图所示：

Image RemovedImage Added

图2.9 逻辑查询计划设计总类图

Select 子句

antlr语法定义

resultColumn
: expression (AS ID)?
;

expression
: LR_BRACKET unary=expression RR_BRACKET
| (PLUS | MINUS) unary=expression
| leftExpression=expression (STAR | DIV | MOD) rightExpression=expression
| leftExpression=expression (PLUS | MINUS) rightExpression=expression
| functionName=suffixPath LR_BRACKET expression (COMMA expression)* functionAttribute* RR_BRACKET
| suffixPath
| literal=SINGLE_QUOTE_STRING_LITERAL
;

functionAttribute
: COMMA functionAttributeKey=stringLiteral OPERATOR_EQ functionAttributeValue=stringLiteral
;

数据结构

ResultColumn

包含Expression和alias两个字段，封装了对Expression的操作。

Expression

本质是ANTLR语法树的内存镜像。

BinaryExpression

...