区块链上的“SQL”

导读

《F1：A Distributed SQL Database That Scales》是Google构建的用于支持广告业务的分布式关系型数据库系统。作为一个混合型数据库系统，它结合了高可用、NoSQL数据库的扩展性以及传统SQL数据库的一致性和可用性。F1数据库整体基于Google Spanner构建，Spanner主要为上层的F1提供了跨数据中心的数据复制功能和一致性保证。而F1通过使用结构化数据分层架构模型和合理的应用设计，来降低数据备份带来的延迟，并提供了全功能的SQL支持。该论文也成为很多厂商实现合约中的SQL功能的重要参考。

区块链执行SQL的可能性

业务系统中的数据是以结构化的组织存在，使用结构化语言查询可以极大提升业务人员访问数据的便捷性。

SQL(Structured Query Language，结构化查询语言)是一种特定目的的编程语言，广泛应用于关系数据库管理系统，例如大家所熟知的MySQL、Oracle等。SQL是高级的非过程化编程语言，它允许用户在高层数据结构上工作，不需要用户指定对数据的存放方法，也不需要用户了解其具体的数据存放方式，这种灵活的方式自然衍生出了很多优秀的SQL执行引擎。

以我们熟知的MySQL为例，其中就包括了InnoDB、MyIsam和Memory等执行引擎，不同的执行引擎之间各有优劣，在不同的使用场景上会发挥出不同的作用，但是其向上的表现却是一致的，由此我们衍生出了在传统区块链的基础上来构建高效可用的SQL执行引擎的设计思想。

存储引擎从很大程度上限制了执行引擎的实现，传统的区块链系统一般会采用键值对的NoSQL数据库，将产生的状态数据以键值对的形式进行存储，同时方便世界状态的计算。为了保证区块链底层的存储结构不发生大的变化，我们需要设计一个方式，尽可能将SQL执行引擎建立在键值对数据库之上。在Google的F1中本身就是基于NoSQL数据库进行扩展，这让在区块链上执行SQL有了一定的可能性。

然而问题在于，要想解决区块链上执行SQL语句，就必须要解决SQL语句的编译问题以及如何将SQL的结构化数据保存到KV数据库当中，这也是我们本篇分享的主要内容：SQL编译与数据存储。

SQL编译

同大部分语言一样，SQL编译主要是将SQL语言转化为AST(Abstract Syntax Tree，抽象语法树)，然后才能基于生成的语法树来设计我们的执行引擎。

既然谈到了编译，必然离不开在编译原理中离不开的两个话题：