谷歌的 Spanner 数据库是如何一步步支持 SQL 语法的

2022-06-01 15:13:17

闲来无事翻译一篇文章，是关于谷歌的全球分布式数据库 Spanners 的 SQL 的故事，作者 Jaana Dogan 是谷歌的一名工程师。关于 Spanner 的介绍可以参考前文：分析 Google Cloud Spanner 的架构

Spanner 之前是一个键值数据库，与现在谈论的 Spanner 是完全不同的东西。在设计之初，Spanner 就支持事务、外部一致性和透明的故障转移。到后面，Spanner 开始支持带类型的数据库表结构和其它的一些关系型数据库功能，以及支持了 SQL 功能。而现在我们正在努力改进 SQL 语法的兼容性和关系型数据库功能。

事务：访问并可能更新数据库中各种数据项的一个程序执行单元(unit)，详细的解释可以参考：https://stackoverflow.com/questions/974596/what-is-a-database-transaction
外部一致性：由 google 提出用于解决数据库事务时间先后顺序的问题。详细的解释参考：https://www.zhihu.com/question/56073588
透明的故障转移：当初始化连接出现问题无法连接时，透明的故障转移可以保证应用程序重新连接到可用服务。详细的解释可以参考：https://blog.csdn.net/cuiyan1982/article/details/80268183

早期

Spanner 刚开始是为了内部的工作场景而设计的，并没有考虑对外开放或者是做成云服务。而且由于谷歌内部使用的工具往往与外界使用的不同，是自成体系的。比如在谷歌内部的存储系统和数据库服务都有着自己的专属 API 或者是客户端。如果想要用自己喜欢的 ORM 库，抱歉，谷歌不支持，只有自己开发的 Stubby/gRPC API 和客户端。可能这会影响某些人的开发，但是，谷歌自信于能提供更好的 API 和客户端服务。

其实这段话代表着谷歌对于技术自信的态度，也解释了为什么 Spanner 在刚开始时为什么不会选择 SQL 语言，而是选择了自己独特的 API。后文则是详细描述了，为什么在谷歌使用 API 的形式开发要比使用 SQL 语言更好的理由，感兴趣的话可以阅读原文，就不翻译了。就我本人来看，不是所有的技术人才都能像谷歌那样，易用性在某种程度上要比所谓的技术领先更重要，这也是为什么 MapReduce 的开发方式终败给了 Spark，败给了 Hive。

开始了 SQL 的实验

F1 是 Spanner 开始 SQL 实验的步。F1 是 Google 开发的基于 Spanner 的分布式数据库。与 Spanner 不同的是，F1 支持：

分布式SQL查询
事务一致的二级索引
可更改的历史记录和信息流

F1 是在 Spanner 之上的协调层中实现了这些功能，并将其他功能交给给 Spanner。

F1 的目的是为了支持广告产品。考虑到广告业务的性质和广告产品的复杂性，能够方便的编写和运行复杂的查询要比其它的特性更重要（因为使用 API 的方式不容易实现复杂的查询）。Spanner 在 F1 的加持下，更适用于重业务逻辑的系统。

关于 F1 的论文可以参考：https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41344.pdf
这段话证明了 SQL 的表达能力要远远超过 API 的形式。

作为云服务的 Spanner

谷歌云将 Spanner 作为云服务之一提供给外部客户使用。在发布时，Spanner 支持用 SQL 查询数据库，而不支持 INSERT，UPDATE和 DELETE 对数据库的修改。

又因为 Spanner 本身还不是完整的可以使用的 SQL 数据库，导致了它缺少类似于 JDBC、database/sql 的驱动。只有作为云服务的 Spanner ，开始支持 SQL 的 INSERT，UPDATE和 DELETE 操作时，技术人员才会考虑去实现这些驱动。

开发人员常用的 JDBC 连接数据库的方式居然都不可用。

现在的话，Cloud Spanner 支持完整的 DDL 和 DML 语法，但是 SQL 的语法依然不是标准的 SQL 语法，类似于方言。ZetaSQL 是 Cloud Spanner 使用的 SQL 解析器和编译器（现已开源）。不仅如此，Cloud Spanner 还提供了 SQL 语句的分析工具。