用scala实现一个sql执行引擎-(下)

执行

上一篇讲述了如何通过scala提供的内置DSL支持,实现一个可以解析sql的解析器,这篇讲如何拿到了解析结果-AST以后,如何在数据上进行操作,得到我们想要的结果。之前说到,为什么选择scala作为这个引擎的实现,之一是scala提供了方便的DSL实现支持,其二是因为作为一门函数式编程语言,scala提供了丰富对于集合操作的函数。此外,函数在scala中是一个独立的类型,所以能够把现有的函数进行组合,得到更为强大的函数(和上一篇提到的用解析组合子组合已有的解析器得到更强大的解析器一样)。

首先,我们需要弄清楚普通sql语句的执行顺序,一般来说,sql的书写顺序为

  • SELECT[DISTINCT]
  • FROM
  • WHERE
  • GROUP BY
  • HAVING
  • UNION
  • ORDER BY

但是,执行顺序为

  • FROM
  • WHERE
  • GROUP BY
  • HAVING
  • SELECT
  • DISTINCT
  • UNION
  • ORDER BY

本次实现的sql执行不支持join,所以省去了union部分,但是大致顺序差不多,如果把一个List<Map>想象成一个数据库的表,那么执行顺序可以用下图所示,图中标绿色的箭头表示可以并发执行,聚合函数的执行是不能并发的,但是因为已经把数据给分组了,故可以在更高的一个层次并发。

了解了大致的执行流程,下面说一下各个流程执行所用到的函数。

  • where子句
    where子句的执行,利用了 filter函数,将不符合条件的数据给过滤掉。举个例子,下面这个段代码,将列表中的奇数给过滤掉。

    scala> val L = List(1,2,3,4,5,6)
    L: List[Int] = List(1, 2, 3, 4, 5, 6)
    scala> L filter(_%2==0)
    res2: List[Int] = List(2, 4, 6)

    对每个元素进行判断这个步骤其实是可以并发执行的,你只需要这样写,就能进行安全的并发操作。

    scala> L.par.filter(_%2==0).toList
    res4: List[Int] = List(2, 4, 6)

    在scala_sql引擎中,实现where的函数为

    def where(where: Option[SqlExpr]): Table = {
          where match {
            case None => table
            case Some(x: SqlExpr) => table filter (evalWhereEachRow(_, x))
          }
        }

    其中evalWhereEachRow(_,x)是另外一个函数,第一个参数是table中的一列,即一个Map对象,第二个参数是由sql解析得到的AST中,对应where子句的部分。

  • groupBy子句
    scala中也提供了对于集合的groupBy操作,接着上个例子

    scala> L groupBy(_%2)
    res6: scala.collection.immutable.Map[Int,List[Int]] = Map(1 -> List(1, 3, 5), 0 -> List(2, 4, 6))

    上面这个函数,把L这个list根据奇偶分组。
    在scala _sql引擎中,实现groupBy的函数为

     def evalGroupBy(table: Table, groupby: SqlGroupBy): Seq[Table] = {
        val keys: Seq[String] = groupby.keys map {
          case x: FieldIdent => x.name
        }
        table.groupBy(row => keys.map(row(_))).map(_._2).toSeq
      }

结论

DSL主要有两种,内部DSL和外部DSL,对于外部DSL,需要一个解析器来解析DSL的脚本,得到能够让程序处理的数据结构,这种数据结构通常是一种AST。实现需要的解析器,大体有两种方式:

  • 手工写一个,例如druid中的sql解析模块。
  • 利用ANTRL等解析生成器,通过编写语法规则,生成一个解析器。

近年来随着函数式编程慢慢得到工业界的关注,利用parser combinator(解析组合子)的方式来编写解析器实现DSL也进入了大众视野。

时间: 2024-10-08 04:56:52

用scala实现一个sql执行引擎-(下)的相关文章

用scala实现一个sql执行引擎-(上)

前言 在实时计算中,通常是从队列中收集原始数据,这种原始数据在内存中通常是一个java bean,把数据收集过来以后,通常会把数据落地到数据库,供后面的ETL使用.举个一个简单的例子,对一个游戏来说,为了统计某个游戏,某个服务器的登陆注册 等事件,原始数据对应的java bean可能会是这样: public class Event { private String userName; private String game; private String server; private Stri

自己实现一个SQL解析引擎

自己实现一个SQL解析引擎 功能:将用户输入的SQL语句序列转换为一个可执行的操作序列,并返回查询的结果集. SQL的解析引擎包括查询编译与查询优化和查询的运行,主要包括3个步骤: 查询分析: 制定逻辑查询计划(优化相关) 制定物理查询计划(优化相关) 查询分析: 将SQL语句表示成某种有用的语法树. 制定逻辑查询计划: 把语法树转换成一个关系代数表达式或者类似的结构,这个结构通常称作逻辑计划. 制定物理查询计划:把逻辑计划转换成物理查询计划,要求指定操作执行的顺序,每一步使用的算法,操作之间的

SQL执行过程中的性能负载点

一.SQL执行过程 1.用户连接数据库,执行SQL语句: 2.先在内存进行内存读,找到了所需数据就直接交给用户工作空间: 3.内存读失败,也就说在内存中没找到支持SQL所需数据,就进行物理读,也就是到磁盘中查找: 4.找到的数据放到内存中,在内存进行数据过滤再放到会话工作空间. 5.假设会话工作空间需要暂存结果集进行排序,但空间不足的话,就会借用磁盘tmpdir,最后再将结果返回给用户. 注: 用户会话空间是内存中分配出来的一个工作空间,而innodb_buffer_pool是innodb存储引

Oracle数据库该如何着手优化一个SQL

这是个终极问题,因为优化本身的复杂性实在是难以总结的,很多时候优化的方法并不是用到了什么高深莫测的技术,而只是一个思想意识层面的差异,而这些都很可能连带导致性能表现上的巨大差异.所以有时候我们应该先搞清楚需求到底是什么,SQL本身是否合理,这些思考很可能会使优化工作事半功倍.而本文是假设SQL本身合理,从Oracle提供给我们的一些技术手段来简单介绍下Oracle数据库,该如何使用一些现有的技术来优化一个SQL执行的性能. 确定需要优化的SQL文本及当前SQL执行计划 确定SQL涉及的所有表及其

SQL Server中的执行引擎入门

简介 当查询优化器(Query Optimizer)将T-SQL语句解析后并从执行计划中选择最低消耗的执行计划后,具体的执行就会交由执行引擎(Execution Engine)来进行执行.本文旨在分类讲述执行计划中每一种操作的相关信息. 数据访问操作 首先最基本的操作就是访问数据.这既可以通过直接访问表,也可以通过访问索引来进行.表内数据的组织方式分为堆(Heap)和B树,其中表中没有建立聚集索引时数据是通过堆进行组织的,这个是无序的,表中建立聚集索引后和非聚集索引的数据都是以B树方式进行组织,

SQL Server获取下一个编码字符串的实现方案分割和进位

我在前一种解决方案SQL Server获取下一个编码字符实现和后一种解决方案SQL Server获取下一个编码字符实现继续重构与增强两篇博文中均提供了一种解决编码的方案,考虑良久对比以上两种方案的,后一种方案虽然解决了其中方案的缺点,但是依然存在的编码字符串长度的限制(最多满足8位长度),本博文提供的方案将编码字符串长度增加到19位,也可以足够项目中实现这些编码. 具体的编码规则可以参看以上两种解决方案博文中的描述,也可以进入SQL Server 大V潇湘隐者的获取下一个编码字符串问题这篇博文.

SQL Server获取下一个编码字符实现继续重构与增强

我在SQL Server获取下一个编码字符实现的博文中,虽然实现了这个问题,但是感觉维护起来比较麻烦,例如如果调整编码字符串的固定长度,就需要变更三个函数,这样的为何成本确实比较大.面向对象编程很重视讲究开放封闭原则,我认为数据库对象特别函数.存储等对象也要尽量封装成实现单一功能,维护起来简单,也方便后续人员的维护,便利别人也是便利自己. 针对编码字符串的规则,继续延伸总结如下: 1.第一个字符必须是字母A-Z中任意一个字符,其长度可以为1位.2位.3位,……,6位.7位.8位.……: 2.编码

SqlServer 中如何查看某一个Sql语句是复用了执行计划,还是重新生成了执行计划

我们知道SqlServer的查询优化器会将所执行的Sql语句的执行计划作缓存,如果后续查询可以复用缓存中的执行计划,那么SqlServer就会为后续查询复用执行计划而不是重新生成一个新的执行计划,因为复用执行计划的性能比生成执行计划的性能要高很多,所以SqlServer的这一特性可以大大提高Sql语句的执行效率.特别是对于存储过程,因为存储过程的执行计划是在存储过程第一次执行的时候生成的,存储过程的执行计划生成后就会被缓存到SqlServer的执行计划列表中,如果以后存储过程再被执行,那么存储过

SQL SERVER 2014 下IF EXITS 居然引起执行计划变更的案例分享

这个问题是在SQL SERVER 2005 升级到SQL SERVER 2014的测试过程中一同事发现的.我觉得有点意思,遂稍微修改一下脚本展示出来,本来想构造这样的一个案例来演示,但是畏惧麻烦,遂直接贴上原表,希望Leader不要叼我(当然个人觉得真没啥,两张表名而已,真泄露不了啥信息). 脚本如下所示,非常简单的一段SQL语句,我将其分为SQL1.SQL2.SQL3.  其实SQL2.SQL3是差不多的,唯一的区别在于多了一个IF EXISTS DECLARE @Operation_Code