共计 4448 个字符，预计需要花费 12 分钟才能阅读完成。
导读
与传统关系型数据库相比，分布式数据库系统具备多集群、多节点、高并发等个性，这就须要分布式数据库的 SQL 引擎可能在满足用户惯例的 SQL 申请以外，提供多集群、多节点协同计算的能力，从而进步查问效率。本文将介绍云溪数据库的 SQL 引擎架构特点，以及其中各大服务组件的技术原理与工作流程。
分布式数据库架构
目前业界最风行的分布式数据库次要分为两种架构。一种是以 Google Spanner 为代表的 Shared nothing 架构，另一种是以 AWS Auraro 为代表的计算 / 存储拆散架构。
Spanner 是 shared nothing 的架构，外部保护了主动分片、分布式事务、弹性扩大能力，数据存储还是须要 sharding，plan 计算也须要波及多台机器，也就波及了分布式计算和分布式事务。
Auraro 次要思维是计算和存储拆散架构，应用共享存储技术，这样就进步了容灾和总容量的扩大。然而在协定层，只有是不波及到存储的局部，实质还是单机实例的 SQL 引擎，不波及分布式存储和分布式计算，这样就和传统数据库兼容性十分高。
浪潮云溪 NewSQL 数据库云溪数据库完满地继承了 Spanner 的设计理念，实现了基于对等架构的分布式 SQL 引擎。
云溪数据库的 SQL 引擎
云溪数据库的 SQL 引擎在传统的 SQL 引擎根底上，引入了分布式的概念，通过多个集群节点协同计算更高效的执行用户 SQL 查问，总体架构图如下：
SQL 引擎动态构造，蕴含五大服务
集群中每个节点 node 都独有连贯服务（Connectivity Service）、编译服务（Compile Service）和缓存服务（Cache Service）三大服务，能够实现用户的 SQL 查问执行的前端筹备工作。
同时，所有节点又独特组成了分布式的目录服务（Distibuted Catalog Service）和分布式的执行服务（Distibuted Execute Service），通过这两个服务实现了多个 node 节点的协同执行，进步了分布式 SQL 引擎的执行性能。最终将结构化数据，转化为底层存储可辨认的 KV 编码对，通过 Batch 批处理发送到事务层进行解决。
SQL 引擎执行流程
下文将对这五大服务进行开展介绍。
1. 连贯服务 Connectivity Service
云溪数据库采纳的是对等架构，集群中的任意节点都能够作为接入节点。同时，云溪数据库反对 PostgreSQL 协定，SQL 查问能够通过各种反对 PostgreSQL 协定的驱动发送到集群。
连贯服务流程如下：
用户通过后盾守护过程进行连接器治理，为每个客户端构建新的 Executor。
当用户从客户端发动指令后，从客户端接管和解包流。
执行结束后，将操作后果打包返回给客户端。
用户的每一次操作，都被认为是一个独自的事务操作。
2. 分布式目录服务 Dist Catalog Service
云溪数据库的 Dist Catalog Service 不仅实现了传统关系数据库的 schema metadata，蕴含了罕用的库、表、列、模式等数据库元数据，而且实现了元数据信息的高可用，以及分布式拜访。元数据采纳多正本存储、分布式存储，保障少于一半数据不可用的状况下，元数据信息依然可用。而且每个对等节点在启动时会间接内存化元数据路由表的第一级 Root Meta Range 数据，保障任意节点都能拜访到须要的元数据信息。
Catalog 信息发生变化时，首先会更新到元数据存储的写入节点，通过 Raft 协定同步到多正本。同时使得各个节点的 Catalog 缓存生效，在应用时进行异步的更新，保障各节点数据的一致性。
3. 编译服务 Compile Service
云溪数据库的编译服务包含了 SQL 前端和 SQL 中端性能，SQL 前端实现了传统数据库的 Scanner、Parser、SQL 语法、SQL 语义以及数据库对象和权限校验的解决，生成了 AST(形象语法树)。
SQL 中端实现了数据库的优化器的性能。优化器负责给执行引擎提供输出，它接管来自 SQL 前端解析好的 AST 树，而后须要从所有可能的打算中抉择代价最优的打算提供给执行引擎。
云溪数据库的优化器是基于 Cascades 论文实现的搜寻框架。从数据库的倒退历程来看，基于 Cascades 的搜寻框架曾经成为了业界规范，包含商业数据库 SQL Server 以及开源数据库 GP/ORCA 都采纳 Cascades 实现。编译服务的整体架构如下：
SQL 引擎编译服务结构图
如上图所示，Client 端输出的 SQL 语句通过 go-yacc 层的词法、语法、语意义解析为 AST 语法树，通过 Memo construction 转换为 CBO 初始的 Memo 树。Memo 由一些列等价的 group 组成，每个 group 示意一个逻辑等价表达式汇合，Memo 自身是树状结构化的，能够代表查问语句，然而又不蕴含大量的元数据信息，能够被缓存以进步执行效率，这点在 Cache Service 中会给出解析。结构好的 Memo 间接利用于根本的 RBO 转换。之后，Memo 数据依据统计信息通过 CBO 优化（等价挖掘和最优化 Cost）抉择转换为最优门路的打算。
RBO 依据指定的优先程序规定，对指定的表进行执行打算的抉择。比方在规定中：索引的优先级大于全表扫描。
当某些 SQL 语句的写法并不利于疾速从存储中查问数据的场景下，RBO 会对其进行相应转化，例：
SELECT * FROM t1 ,t2 WHERE t1.a > 4 AND t2.b >5;
如果先进行笛卡尔积再进行过滤条件时，则会产生很多不必要的元组。然而如果先过滤 t1 , t2 的关系，在进行笛卡尔积，那么表达式的耗费将大大减少。在进行过滤时，能做到一个 select 算子中就做到算子中，不能的话，就在具备过滤须要的列时及时做好，比方 a.a > 5 and b.b > 10 and a.c > a.b，第一个和第二个条件都能够推到 select 算子中，在这两个算子下面立刻加一个 a.c > a.b 的过滤条件。
CBO 则基于统计信息对代价进行代价预估，失去一条较优的查问门路。例如：咱们在做三个表连贯的时候，如果有统计信息的话，咱们就能够晓得，哪两个表先做连贯会使接下来执行的代价更小，因为在做 hashjoin 时，咱们总心愿小的表先进入，而后制作成一个小的 hashtable，因为 hashtable 比拟小，所以之后的大表在做 join 的时候，就会有更高的命中率。
4. 缓存服务 Cache Service
云溪数据库提供了两种类型的缓存服务，次要是用来进步数据拜访效率，缩小反复耗费。
第一种是 Session 级的 Querycache，次要是缓存用户 SQL 语句指纹对应的 Memo 树数据结构，缩小同一 Session 的 SQL 语句屡次构建逻辑打算的开销。SQL 语句指纹含有 SQL 语句的相干 Catalog 信息和权限等校验信息。
在重用 Memo 之前，会对 Memo 是否过期进行查看：解析元数据所依赖的每个数据源和 schema，以便查看齐全限定的对象名是否仍解析为雷同对象的雷同版本，检查和工夫相干的类型的结构和比拟形式，以及用户是否仍有足够的权限拜访这些对象。如果依赖项不再是最新的，则断定该 Memo 过期，须要从新构建。
第二种是集群级别的元数据相干 Cache。其中 Catalog 信息蕴含了数据库罕用的 scheme 信息和元数据路由信息。元数据路由信息由 Dist Catalog service 提供。通过元数据路由信息集群任意节点能够拜访到所有须要的元数据或者数据。
5. 分布式执行服务 Dist Execution Service
云溪数据库的 SQL 引擎整体设计模型参考了 Volcano 模型[1]，Volcano 模型的提出者是 Goetz Graefe，其 1994 年发表此文，并于 2017 年取得 Edgar F. Codd（关系模型奠基人）创新奖。
云溪数据库的分布式执行提出了一些与 Map-Reduce 相似，但与 Map-Reduce 的执行模型又齐全不同的概念。
云溪数据库的逻辑打算由优化后的 Memo 自底而上构建出一个 Plan node 树状构造，为后续构建物理打算增加一些额定的表信息，列信息等。
分布式执行的要害思维是如何从逻辑执行打算到物理执行打算，这里次要波及两方面的解决，一个是计算的分布式解决，一个是数据的分布式解决。
一旦生成了物理打算，零碎就须要将其拆分并散布到各个 node 之间进行运行。每个 node 负责本地调度数据处理器 data processors 和输出同步器 synchronizers。node 还须要可能彼此通信以将输入 output router 连贯到 input synchronizer。特地是，须要一个 streaming interface 来连贯这些组件。为了防止额定的同步老本，须要足够灵便的执行环境以满足下面的所有这些操作，以便不同的 node 除了执行打算初始的调度之外，能够绝对独立的启动相应的数据处理工作，而不会受到 gateway 节点的其余编排影响。
云溪数据库的集群中的 Gateway node 创立一个 Scheduler 调度器，它承受一组 flow，设置输出和输入相干的信息，创立本地 processor 并开始执行。在 node 对输出和输入数据进行解决的时候，咱们须要对 flow 进行一些管制，通过这种管制，咱们能够回绝 request 中的某些申请。
执行 Flow 示意图
每个 Flow 示意整个物理打算中跨节点执行的一个残缺片段，由 processors 和 streams 组成，能够实现该片段的数据拉取、数据计算解决和最终得数据输入。如下图所示：
打算执行示意图
对于跨节点的执行，Gateway node 首先会序列化对应的 FlowSpec 为 SetupFlowRequest，并通过 grpc 发送到远端 node，远端 node 接管后，会先还原 flow，并创立其蕴含的 processor 和交互应用的 stream（TCP 通道），实现执行框架的搭建，之后开始由网关节点发动驱动的多节点计算。Flow 之间通过 box 缓存池进行异步调度，实现整个分布式框架的并行执行。
对于本地执行，就是并行执行，每个 processor，synchronizer 和 router 都能够作为 goroutine 运行，它们之间由 channel 互联。这些 channel 能够缓冲信道以使生产者和消费者同步。
为实现分布式并发执行，云溪数据库在执行时引入了 Router 的概念，对于 JOIN 和 AGGREGATOR 等简单算子依据数据分布特色，实现了三种数据再散布形式，mirror_router、hash_router 和 range_router，通过数据再散布实现 processor 算子外部拆分为两阶段执行，第一阶段在数据所在节点做局部数据的解决，解决后后果，依据算子类型会进行再散布后，第二阶段会集解决，从而实现了单个算子多节点合作执行。
小结
本文介绍了基于谷歌 Spanner 论文设计的分布式 NewSQL 数据库云溪数据库的 SQL 引擎架构，并具体介绍了每个节点中的连贯服务、编译服务、缓存服务，以及零碎中的分布式目录服务、分布式执行服务五大服务组件的技术原理与工作流程。