谷歌对外发布了云 Spanner Beta 版

阅读数:1190 2017 年 3 月 5 日

话题:数据库Google语言 & 开发架构AI

谷歌已经为她的全球分布式关系型数据库服务云 Spanner对外发布了 Beta 版。作为谷歌云平台的一部分,它同时提供 ACID 事务和高可用性,看起来像是颠覆了 CAP 理论。

Spanner 已经在谷歌内部广为使用了,现在正在向公众开放。它是一个可管理的云数据库,可以作为谷歌云平台的一部分使用,而且不会涉及底层的基础设施。

Spanner 看起来和传统关系型数据库一样,有 ACID 事务、SQL、关系型模式等。但是,它是分布式的,在地理上跨谷歌基础设施,可以满足日益增长的更大事务处理量。除此之外,它还有强一致性,在提供数据服务时只有几毫秒的延迟。

CAP 理论证明一个数据库系统不可能同时满足以下三种特性:可用性、一致性和分区容忍性。关系型数据库倾向于牺牲可用性,而 NoSQL 数据库则用最终一致性换来了高可用性。

事实上 Spanner 也没有颠覆 CAP 理论,它只是在功能上看起来像是这样而已。谷歌基础设施副总裁 Eric Brewer解释到:

Eric Brewer:这意味着根据 CAP 的定义,Spanner 就是一个 CA 系统了吗?从技术上来说可以直截了当地回答“不是”,但从实际效果来说,却可以认为是“是”,用户可以认为它就是 CA 的而直接使用。

Brewer 总结道,在 Spanner 系统中,出现网络分区的可能性是 1 比 105。如果这种情况真的发生了,系统会选择一致性,从技术的角度看就是 CP 的。但是,由于这种可能性极低,所以也可以就认为它是可用的。

在 Brewer 的白皮书中,他解释这种级别的可靠性的基础在于 Spanner 是运行在谷歌全球自建网络中的。Spanner 的网络包从来不会发到公共互联网中,而且由于冗余级别非常之高,像切断光纤之类的灾难性事件也不会导致断网。

还有一些第三方,比如Cloudera的分布式系统工程师Henry Robinson也认可这样的说法,他解释道:

Henry Robinson:可以从这个角度去考虑:CAP 理论告诉我们每个系统都会有她自己的阿基里斯之踵,或者说是软胁,这就意味着在一定时间之内要放弃 C 或者放弃 A。谷歌则把 Spanner 的软胁深深地埋在了某个黑洞里。

为了确保 ACID 特性,Spanner 实现了典型的分布式事务模型——两阶段提交。Brewer 解释说尽管这个模型要求所有的成员都必须在线,因此有些降低可用性,但 Spanner 通过使用一个Paxos组来绕过了这个问题,换句话说,当某些成员不在的时候,一个多数选举的结果也可以生效。

Spanner 也使用了谷歌的全球同步的锁 TrueTime。Brewer 说 TrueTime 同时使用了 GPS 接收器和原子时钟来保证时间的准确性。它可以正确地为分布式事务打上时间戳,从而保证外部一致性。

面向公众的云 Spanner 仍然是 Beta 版,现在还可以在线上免费试用

阅读英文原文Google Launches Cloud Spanner Public Beta