自己怎样创建网站wordpress 主题模板下载失败

当前位置： 首页 > news >正文

自己怎样创建网站,wordpress 主题模板下载失败,福建老区建设网站,站长工具seo综合查询怎么用文章目录 一. 关系代数的基本知识二. 查询优化三. SQL语句的解析顺序1. FROM2. WHERE3. GROUP BY4. HAVING5. SELECT 四. Apache Calcite中的基本概念1. Adapter2. Calcite中的关系表达式2.1. 关系表达式例子2.2. 源码底层结构 3. Calcite的优化规则4. Calcite的Trait–算子物理… 文章目录 一. 关系代数的基本知识二. 查询优化三. SQL语句的解析顺序1. FROM2. WHERE3. GROUP BY4. HAVING5. SELECT 四. Apache Calcite中的基本概念1. Adapter2. Calcite中的关系表达式2.1. 关系表达式例子2.2. 源码底层结构 3. Calcite的优化规则4. Calcite的Trait–算子物理属性5. Calcite的Calling Convention调用约定6. Calcite内建算子 本文主要描述Calcite 相关的基础性内容。 关系代数基础概念查询优化简单介绍sql关键字解析顺序calcite基础概念 上篇了解了【源码分析】 Calcite 处理流程详解calcite架构、处理流程以及就一个运行示例进行源码分析之后我们对calcite有了一定的认知但有些细节还未说明所以本篇讨论对 Calcite 相关的基础性内容进行说明。希望通过本篇能够对Calcite的原理细节有一个更加清晰的了解。 一. 关系代数的基本知识 在学习Apache Calcite的一些基本概念之前首先要弄懂关系表达式并且要知道SQL与关系表达式的关系因为Calcite的最核心的概念就是关系表达式。 关系代数是关系型数据库操作的理论基础关系代数支持并、差、笛卡尔积、投影和选择等基本运算。关系代数也是 Calcite 的核心任何一个查询都可以表示成由关系运算符组成的树。 在 Calcite 中它会先将 SQL 转换成关系表达式relational expression然后通过规则匹配rules match进行相应的优化优化会有一个成本cost模型为参考。 关系代数相关内容简单总结如下 二. 查询优化 查询优化主要是围绕着 等价交换 的原则做相应的转换相关文章 数据库查询优化入门: 代数与物理优化基础 三. SQL语句的解析顺序 一个sql语句是按照如下的顺序解析的 1. FROM FROM后面的表标识了这条语句要查询的数据源。和一些子句如1-J1笛卡尔积1-J2ON过滤1-J3添加外部列所要应用的对象。FROM过程之后会生成一个虚拟表VT1。 (1-J1)笛卡尔积 这个步骤会计算两个相关联表的笛卡尔积(CROSS JOIN) 生成虚拟表VT1-J1。(1-J2)ON过滤 这个步骤基于虚拟表VT1-J1这一个虚拟表进行过滤过滤出所有满足ON 谓词条件的列生成虚拟表VT1-J2。(1-J3)添加外部行 如果使用了外连接保留表中的不符合ON条件的列也会被加入到VT1-J2中作为外部行生成虚拟表VT1-J3。 2. WHERE 对VT1过程中生成的临时表进行过滤满足where子句的列被插入到VT2表中。

1. GROUP BY 这个子句会把VT2中生成的表按照GROUP BY中的列进行分组。生成VT3表。
2. HAVING 这个子句对VT3表中的不同的组进行过滤满足HAVING条件的子句被加入到VT4表中。
3. SELECT 这个子句对SELECT子句中的元素进行处理生成VT5表。 (5-1)计算表达式 计算SELECT 子句中的表达式生成VT5-1(5-2) DISTINCT 寻找VT5-1中的重复列并删掉生成VT5-2(5-3) TOP 从ORDER BY子句定义的结果中筛选出符合条件的列。生成VT5-3表ORDER BY 从VT5-3中的表中根据ORDER BY 子句的条件对结果进行排序生成VC6表。 四. Apache Calcite中的基本概念
4. Adapter 在Calcite的架构中Adapter的概念使Calcite知道如何去访问不同的数据源。一个数据源的Adapter对应有一个model一个schema一个schema Factory。 model定义了数据源的物理属性比如下面的JDBC Adapter的model {defaultSchema: db1,schemas: [{factory: org.apache.calcite.adapter.jdbc.JdbcSchema\(Factory,name: db1,operand: {jdbcDriver: com.mysql.cj.jdbc.Driver,jdbcPassword: changeme,jdbcUrl: jdbc:mysql://localhost:3306/test,jdbcUser: root},type: custom}],version: 1.0 }schema定义了数据的格式和层次。schema factory可以解析model来创建schema。 2. Calcite中的关系表达式 在 Calcite 中关系表达式通常以树形结构的形式表示。树的根节点是查询的最外层操作符例如 SELECT、FROM、WHERE 等每个操作符都有其对应的子节点子节点可以是另一个关系表达式或者具体的数据源(where: 由adapter实现)。 2.1. 关系表达式例子 如下 SQL 查询及其关系表达式 SELECT * FROM orders o JOIN customers c ON o.customer_id c.customer_id WHERE c.state CA;LogicalProject(order_id[\)0], order_date[\(1], customer_id[\)2], order_total[\(3])LogicalFilter(condition[(\)5, CA)])LogicalJoin(condition[(\(2, \)6)], joinType[inner])EnumerableTableScan(table[[MY_DB, ORDERS]])EnumerableTableScan(table[[MY_DB, CUSTOMERS]]) 说明 每个节点代表一个操作符例如 LogicalProject 代表 SELECT 操作LogicalFilter 代表 WHERE 操作LogicalJoin 代表 JOIN 操作。节点的顺序和嵌套结构代表了查询的执行顺序从下往上看和逻辑关系。节点参数包括操作符参数和子节点引用。例如 LogicalProject 的参数是输出的列子节点是它所操作的关系表达式。 理解关系表达式对于理解 Calcite 的查询优化和执行过程非常重要。 2.2. 源码底层结构 转换为关系表达式的基本逻辑 在calcite中当一个sql字符串被解析为SqlNode结构的AST树抽象语法树后并不能直接被Calcite的优化器优化。还需要通过SqlToRelConverter将SqlNode结构转换成为RelNode结构组成的树。 关系表达式算子接口与实现
   如上图所示Calcite所有的关系表达式算子都需要实现RelNode接口。其中Calcite的核心算子有TableScan, TableModify, Values, Project, Filter, Aggregate, Join, Sort, Union, Intersect, Minus, Window 与Match。 通过这些类的名字比较容易理解它们与SQL的对应关系比如TableModify对应SQL中的INSERT、UPDATE、CREATE操作Minus对应SQL中的EXCEPT操作Window对应流处理的window概念等。 Calcite中的这些核心算子都有对应的纯逻辑子类LogicalXXXSqlToRelConverter将SqlNode转换出来的RelNode树中每个节点都是这些LogicalXXX子类组成的。它们并不能生成可执行的执行计划只是用于表示SQL对应的关系表达式结构。 Adapter 对接实现 与Calcite对接的后端执行引擎的Adapter都会实现这些算子的可执行的实现。比如Cassandra adpter会有CassandraProject 在Calcite中逻辑算子转换成后端引擎实现的对应算子是在Calcite Planner优化器对RelNode树执行优化时候根据优化Rule将逻辑算子替换成对应的实际算子。 这里的adapter与flink的connector设计上是什么关系 3. Calcite的优化规则 Calcite的优化器规则可以将一个关系表达式转换成等价的关系表达式而这些优化器规则的基类都是RelOptRule。如下图的EnumerableSortRule可以将LogicalSort逻辑算子转换成Calcite内建的可执行的算子EnumerableSort。 package org.apache.calcite.adapter.enumerable;class EnumerableSortRule extends ConverterRule {EnumerableSortRule() {super(Sort.class, Convention.NONE, EnumerableConvention.INSTANCE,EnumerableSortRule);}public RelNode convert(RelNode rel) {final Sort sort (Sort) rel;if (sort.offset ! null || sort.fetch ! null) {return null;}final RelNode input sort.getInput();return EnumerableSort.create(convert(input,input.getTraitSet().replace(EnumerableConvention.INSTANCE)),sort.getCollation(),null,null);} }Sort.class在优化器运行时匹配这条规则然后优化器调用convert将原来的Sort算子转换为EnumerableSort算子。比如LogicalSort在优化器优化时会匹配到这条规则EnumerableSort就会替代LogicalSort。 除了上面的转换规则以外Calcite已经实现了许多规则可以注册到优化器中在优化时调用比如filter、project等算子下推的优化规则等。目前Calcite已经实现了两种优化器引擎基于代价优化的class VolcanoPlanner和基于经验的优化class HepPlanner。 4. Calcite的Trait–算子物理属性 在Calcite中没有使用不同的对象代表逻辑和物理算子而是使用trait来表示一个算子的物理属性。 Calcite中使用接口RelTrait来代表一个关系表达式节点的物理属性使用RelTraitDef来表示Reltrait的class。 RelTrait与RelTraitDef的关系就像java中对象与Class的关系一样每个对象都有Class。 对于物理的关系表达式算子会有一些物理属性这些物理属性都会用RelTrait来表示。 比如每个算子都有Calling Convention这一Reltrait。比如上图中Sort算子还会有一个物理属性RelCollation因为Sort算子会对表的一些字段进行排序RelCollation这一物理属性就会记录这个Sort算子要排序的字段索引、排序方向null值怎么排序等信息。 5. Calcite的Calling Convention调用约定 Calling Convention在Calcite中使用接口Convention表示Convention接口是RelTrait的直接口所以是一个算子的属性。 Calling Convention可以理解为一个特定数据引擎协议拥有相同Convention的算子可以认为都是同一个数据引擎的算子可以相互连接起来。比如JDBC的算子JDBCXXX都有JdbcConventionCalcite的内建Enumerable算子EnumerableXXX都有EnumerableConvention。 上图中Jdbc算子可以通过JdbcConvention获得对应数据库的SqlDialect和JdbcSchema等数据这样可以生成对应数据库的sql获得数据库的连接池与数据库交互实现算子的逻辑。 join场景 如果数据要从一个Calling Convention的算子到另一个Calling Convention算子的时候比如使用Calcite进行跨库join的场景。需要接口Converter的子类作为两种算子之间的桥梁将两种算子连接起来。 比如上面的执行计划要将Enumerable的算子与Jdbc的算子连接起来中间就要使用JdbcToEnumerableConverter作为桥梁。 6. Calcite内建算子 如果一个Adapter没有实现所有的核心关系表达式算子Calcite也能生成完整的执行计划完成整个数据处理过程。这是因为Calcite内建了EnumerableConvention作为Calling Convention的Enumerable算子实现了所有核心的关系表达式算子,比如EnumerableFilter,EnumerableSrt,EnumerableHashJoin等。 Enumerable算子效率不高 使用Enumerable算子效率不高而且都是在内存中处理的。比如EnumerableHashJoin算子join两个表都是在内存中处理表的所有数据数据量一大就会造成内存溢出。如果实现一个数据引擎的Adapter能提供对应算子的处理能力就应该实现这个算子将工作推到后端的数据引擎中处理避免回退到使用Enumerable算子。 参考 https://blog.csdn.net/feeling890712/article/details/106333425