CockroachDB架构——SQL层

ChockroachDB架构的SQL层向开发人员公开SQL API并将SQL语句转换成数据库其他部分使用的键值操作。
--注意：
1）如果您还没有准备好，我们建议您阅读架构概览部分。

一.概览
一旦CockroachDB部署，开发人员只需通过连接串连接到簇并发送SQL语句开始工作。
因为CockroachDB节点行为都是对称的，开发人员能向任何节点发送请求（这意味着CockroachDB能与负载据衡器很好的工作）。无论哪个节点作为"网关节点（gateway node）"接收到请求，都像其他层一样处理该请求。
当开发人员向簇发送请求时，它们作为SQL语句到达，但数据最终作为键值对从存储层进行写和读。为了处理这些，SQL层将SQL语句转换成传递到事务层（transaction layer）的KV操作的一个计划（plan）。
1.与其他层交互
与CockroachDB其他层的关系，SQL层：
将请求发送给事务层。

二.组件
1.关系结构（Relational structure）
开发人员可以体验以关系结构存储在CockroachDB中的数据，即，行和列。一组行和列组织到表中。表的集合组织数据库。您的簇能包含很多数据库。
因为这个结构，CockroachDB提供典型的类似约束（例如：外键）的关系特性。这让应用开发人员相信数据库将确保应用数据的一致性结构；数据校验不必单独建进应用逻辑中。
2.SQL API
CockroachDB实施大部分ANSI SQL标准以表明它的关系结构。
重要的是，通过SQL API，我们也让开发人员就像通过任何SQL数据库那样使用ACID语义的事务（begin,end,commit,等。）
3.PostgreSQL线协议
SQL查询通过PostgreSQL线协议到达您的簇。这使得您的应用通过支持大多数PostgreSQL兼容的驱动和很多像GORM(Go)和Hibernate(Java)PostgreSQL ORM就可以连接到簇。
4.SQL解析器、计划器和执行器
您的节点最终接收到客户端的SQL请求后，CockroachDB解析该语句，创建查询计划和执行该计划。
1）解析
接收到的查询针对我们的yacc文件进行解析（其描述我们支持的语法），并将每个查询的字符串版本转换为抽象的语法树（AST）。
2）逻辑计划
AST随后三阶段中被转换为查询计划：
--AST被转换为高级逻辑查询计划。在该转换期间，CockroachDB也进行语义分析，这包括检查查询是否有效，名字解析，消除不必要的中间计算，以及确定中间结果使用什么数据类型。
--逻辑计划通过总是有效的转换优化进行简化。
--逻辑计划通过评估执行该查询的很多可能方法的搜索算法进行优化，并选择一个最低成本的执行计划。
优化阶段的结果是一个优化过的逻辑计划。这可以通过explain命令进行观察。
3）物理计划
物理计划阶段基于范围位置信息决定哪些节点参与该查询的执行。这是CockroachDB决定将查询分布到数据存储最近的地方进行某些计算的阶段。
物理计划的结果是一个物理计划，且能用explain(distsql)进行观察。
4）查询执行
物理计划的组件送到一个或多个节点以执行。每个节点上，CockroachDB产生一个逻辑处理器来计算一部分查询。逻辑处理器在节点内或节点间通过逻辑数据流进行相互通信。查询的组合结果送到接收查询的第一个节点，并进一步被送至该SQL的客户端。
每个处理器使用查询操作标量值的编码格式。这是和SQL中所用不同的二进制格式。因此，列在SQL查询中的值必须被编码，并且，逻辑处理器间的通信数据及从磁盘读取的数据，送回至SQL客户端前必须被解码。
5）向量化查询执行
如果开启了向量执行，物理计划被送至节点通过向量化执行引擎进行处理。
接收到物理计划后，向量化引擎从磁盘批量读取表数据，并将数据从行格式转换成列格式。这些批量列数据存储于内存中，以便引擎在执行期间能快速访问它们。
向量化引擎使用特殊的、预编译的函数，这些函数对列数据的特定类型的数组进行快速迭代。引擎处理每列数据时这些函数的列输出存储于内存中。
处理输入缓冲中的所有列数据后，引擎将列输出转换回行格式，并接着讲处理的数据行返回到SQL接口。一批表数据完全处理后，引擎按批处理后续的表数据以进行处理，指导查询执行完成。
5.编码
虽然SQL查询以可解析字符串编写，但CockroachDB低层主要按字节处理。这意味着在SQL层、查询执行，CochroachDB必须将SQL表示数据流从字符串转换为字节，并将低层返回的字节转换成能被传回客户端的SQL数据。
对索引列，该字节编码保留其表示数据类型的同样顺序也是重要的。这是因为CockroachDB最终按照排序的键值映射的方式存储数据。按照其表示数据同样顺序存储数据可以让我们高效的扫描KV数据。
但是，对非索引列（例如：非主键列），CockroachDB而是用一种消耗较少空间但不保留顺序的编码（被称为"值编码（value encoding）"）
6.DistSQL
因为CockroachDB为分布式数据库，我们已经为有些查询开发了一个分布式SQL（DiskSQL）优化工具，其可以极大的提升涉及很多范围的查询性能。虽然DistSQL的架构值得编写自己的文档，这个粗略解释能提供一些其工作机制的洞察。
非分布式查询，协调节点接收匹配查询的所有数据行，并接着进行整个数据集的任何计算。
但是，对DistSQL兼容的查询，每个节点对其包含的数据行进行计算，并接着将结果（而非整个数据行集）送至协调节点。协调节点接着从每个节点汇聚结果，并最终将单个响应返回客户端。
这极大的减少了带到协调节点的数据量，且利用了以被充分证明的并行计算的概念，最终减少了完成复杂查询所消耗的时间。此外，这也处理以存储于该节点上的数据，使得CockroachDB处理比单个节点存储大得多的数据行集。
为了分布式方式运行SQL语句，我们引进了两个概念：
1）逻辑计划：类似上面描述的AST/planNode树，它表示流过各计算阶段的抽象（非分布式）数据流。
2）物理计划：物理计划概念上是逻辑计划节点到运行cockroach的物理机器的映射。逻辑计划节点根据簇拓扑被复制和指定。就像上面的planNode，物理计划的这些组件在簇上被调度和运行。

三.与其他层的技术交互
1.SQL层和事务层
来自被执行的planNode的KV操作被送至事务层。

四.个人看法
1.现在每款称为库的成熟产品，都具备的组件层，这也充分体检了SQL之美。