SQL 层是 Hubble 数据库负责处理 SQL 请求的部分。SQL 层的核心职责是将 SQL 请求转换为 KV 可以处理的请求。其他层处理事务、分布式和 Shards 和物理存储到磁盘的复制。
SQL 层通过 PG 协议接收来自数据库客户端的请求。数据库客户端是任何使用数据库驱动程序与服务器通信的程序。它包括 Hubble 命令行 SQL 处理器、DBeaver、Finebi 或 Tableau 等 GUI 工具，或用 Java、Go、C/C++、NodeJS 编写的应用程序。JS、Python 或任何其他具有兼容驱动程序的语言。
PG 协议描述了从数据库客户端和服务器发送请求和接收结果的网络数据包的格式。该协议位于传输介质(如 TCP/IP 或 unix 风格的套接字)之上。使用 PG 协议，Hubble 可以充分利用支持 PostgreSQL 数据库的兼容语言驱动程序和工具。
SQL 层解析 SQL 请求，检查它的语法准确性，并确保连接具有执行请求任务的权限，然后为 SQL 语句创建一个执行计划，并继续优化该计划。
SQL 是一种声明性语言:您定义所需的数据，而不是如何获取数据。尽管 SQL 的非过程性可以提高程序员的工作效率，但是数据库必须支持一组复杂的算法来确定执行 SQL 的最佳方法。这些算法被统称为优化器。
对于几乎所有 SQL 语句，Hubble 检索所需行的方法都不止一种。例如，给定一个带有 JOIN 和 WHERE 子句的 SQL，可能有多个连接顺序和多个访问路径(表扫描、索引查找等)可用来检索数据。优化器的目标是确定最佳访问路径。
优化器使用启发式(规则)和基于成本的算法来执行工作。
SQL 优化过程的第一阶段是将 SQL 转换为适合进一步优化的规范化形式。此转换将删除 SQL 语句中的任何冗余，并执行基于规则的转换以提高性能。转换考虑到表的数据分布、添加谓词以将部分查询引导到特定范围或添加允许使用索引检索路径的谓词。
SQL 语句的优化分为两个阶段:扩展和排序。SQL 语句被转换为初始计划。然后，优化器将该计划扩展为一组等效的候选计划，其中包括连接顺序或索引等可选执行路径。然后，优化器通过计算每个操作的相对成本，利用提供每个表中数据大小和分布的统计信息来对计划进行排名。然后选择成本最低的方案。
Hubble 数据库支持向量化执行引擎，可以加快批量数据的处理速度。这个引擎将数据从面向行（row-oriented）格式转换为面向列格式。
从 SQL 到 Key-Values
正如我们前面提到的，Hubble 的数据最终存储在一个键-值存储系统中，该存储系统分布在 shards 中的多个节点上。由于 SQL 层的输出实际上是 KV 操作，因此将表和索引中的数据映射到 KV 表示也是 SQL 层的一部分。SQL 层的输出是 KV 操作。所以也就明确了，只有 SQL 层需要关心 SQL 语法，其它软件层次不需要关心 SQL 语法。
表(Tables)在KV 存储中的表示
KV 存储的每个条目都有一个 key，其结构如下:
/ < tableID > / < indexID > / < IndexKeyValues > / < ColumnFamily >
默认情况下，所有列都包含在一个默认列族中。
对于一般表，默认的 indexID 是“primary”。
如图 1-1 显示了这个映射的简化版本，省略了列族标识符。
图 1-1。 KV 到 column 映射
图 1-1 显示了表名和索引名(“primary”)作为 text，但在 KV 存储中，它们被表示为紧凑的表和索引标识符。
列族(Column Families)
在前面的示例中，一个表的所有列都聚集在单个 KV 条目的 value 部分。但是，可以使用 Hubble 的列族分割 KV 条目将其 columns 分组存储。表中的每个列族都将分配自己的 KV 条目。图 1-2 说明了这个概念——如果一个表有两个列族，那么表中的每一行将由两个 KV 条目表示。
图 1 - 2。列族（Column families) 在 KV 存储中的表
列族有很多优点。如果不经常访问的大列被分离，那么它们在行查找期间将不会被检索，这可以提高 KV 存储缓存的效率。此外，对独立列族中的列的并发操作不会相互干扰。
索引在KV存储中的表示
索引也是的 KV 结构.例如，非唯一索引的表示如图 1-3 所示
图 1-3。非唯一索引 KV 存储表示
非惟一索引的 key 包括表和索引名、键值和主键值。对于非惟一索引，默认情况下没有“值”。对于唯一索引，KV 值默认为主键的值。因此，如果 name 在前面示例中使用的库存表中是唯一的，那么在图 1-4 中就会表示 name 的唯一索引
图 1-4。唯一索引 KV 存储表示
倒排索引(Inverted Indexes)
Hubble 列可以定义为数组或 JSON 格式。
倒排索引允许对这些数组或 JSON 中包含的值进行索引搜索。在这种情况下，键值包括了 JSON 的路径和值以及主键，如图 1 - 5 所示。
图 1-5。倒排索引 KV 存储表示
倒排索引也用于空间数据。
倒排索引可能比其他索引更大，维护成本更高，因为一行中的单个 JSON 文档将为每个惟一属性生成一个索引条目。对于复杂的 JSON 文档，这可能导致每个文档有几十个索引条目。对这个问题以及替代方案，我们之后单起一个文档讨论。
涵盖索引(Covering indexes)
CREATE INDEX 的 storage 子句允许我们向 KV 索引结构的 value 部分添加额外的列。这些附加列可以简化包含映射(例如，SELECT 列表)的查询，该映射只包含这些列和索引键。例如，在图 1 - 6 中，我们看到一个关于 name 和 DateOfBirth 的非唯一索引，它使用 storage 子句将 phoneNumber 添加到 KV 值中。使用姓名和出生日期查找电话号码的查询现在可以由索引单独解析，而不需要引用基表。
图 1 - 6。涵盖索引 KV 存储表示
表定义和模式(Schema)变更
表(及其相关索引)的 schema 定义存储在一个称为表描述符的特殊键空间中。出于性能原因，表描述符被复制到每个节点上。表描述符用于解析和优化 SQL，并正确地构造表的 KV 操作。
Hubble 支持使用 ALTER TABLE、CREATE INDEX 和其他命令在线更改模式(Schema)。模式(Schema)是在离散（独立）的阶段进行更改，这允许以前的版本仍在使用得情况下，推出新的模式(Schema)。模式(Schema)更改作为后台任务运行。
启动模式(Schema)更改的节点将获得相关表描述符上的写租约。在表上执行数据操作语言(DML)的节点将拥有相关表描述符的租期。当持有写租约的节点修改定义时，它将被广播到集群中的所有节点，这些节点将释放它们对旧模式(Schema)的租约。
模式(Schema)更改可能涉及对表数据的更改(删除或添加列)和/或创建新的索引结构。当根据新模式的要求存储表的所有实例时，所有节点将切换到新模式，并允许使用新模式对表进行读写。
