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

2022-06-01 00:00:00 功能 数据库 支持 自己的 语法

闲来无事翻译一篇文章,是关于谷歌的全球分布式数据库 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 语句的分析工具。

  • ZetaSQL:https://github.com/google/zetasql

  • 还是那句话,不是所有的公司都是谷歌,要想自己的产品被绝大数人使用,那么就得选择能被大多数人接受的方式,比如 SQL,坚持自己的技术不放弃的话,虽一时领先,但终只能像 MapReduce 沦为历史的淘汰品。

下一步

下一步 Spanner 会持续改进 SQL 的语法,以与标准的 SQL 语法兼容。通过使用标准的 SQL 语法,也可以帮助 Spanner 兼容大多数 ORM 框架。

除此以外,Spanner 还会努力弥补上相比传统关系型数据库缺失的功能,比如建表时支持默认值和自增 ID 等。

终,Spanner 选择了妥协。



来源 https://www.modb.pro/db/71411

相关文章