Spanner 是谷歌的可伸缩、多版本、全球分布、支持同步复制的数据库,它是第一个在全球范围内传递数据且保证外部一致的分布式事务的系统。论文叙述了它的架构、特征、许多设计的依据和一个新的可以暴露时钟不确定性的API。
简介
开篇叙述了 Spanner 的一些特性,在全球分布的 Paxos 状态机上进行 data sharding,利用复制保证整体可用性和地域局部性,客户端会自动在副本间进行failover,当数据数量或者服务器数量改变时,Spanner 会自动进行 data resharding,且它还支持在不同机器(甚至数据中心间)迁移数据以此来进行负载均衡或者应对突发的错误。
接着作者讲述了 Google 内部 Bigtable 和 Megastore 的一些问题,前者对于复杂可变的模式,或者需要大范围强一致性复制的场合不适用;后者的写吞吐量很差,即使是它的半关系型数据模型和对实施复制的支持很好,但是也非完美的选择。最后的结果是,Spanner 从一个与 Bigtable 相似的 KV 存储进化成了一个数据多版本的数据库。数据存储在模式化、半关系型的表中;数据有版本的区分,数据在 commit 的时候会为每个版本生成一个 timestamp,旧版本会受制于垃圾回收机制;同时应用也可以读旧版本的数据。Spanner 支持通用的事务,提供了基于 SQL 的查询语言。
接着作者概括了一些 Spanner 的特性:第一是应用可以自己细粒度的控制数据复制的配置项,包括哪个 datacenter 包含什么数据、数据离用户多远(控制读延迟)、副本间距多远(控制写延迟)、有几个副本(决定可用性和容灾等级),数据也可以在 datacenter 之间流动,以平衡资源使用。第二 Spanner 实现了两个分布式数据库的难点,(1)外部一致的读写操作 (2)在一个 timestamp 下全球一致的跨数据中心的读操作。这些特性使得 Spanner 可以在全球层面上,支持一致性备份、一致的 MapReduce 任务执行,和对 schema 原子更新操作,即使是事务正在进行中也可以。
怎么实现的呢?作者也说了得益于 Spanner 为事务分配一个全球意义的 commit timestam