Spanner-Chinese.pdf

本翻译论文源于厦门大学计算机系数据库实验室林子雨老师的云数据库技术资料专区 /cloud_database_view Google Spanner （中文版） 翻译者：厦门大学计算机系教师 林子雨 翻译时间：2012 年9 月 E-mail: ziyulin@ 个人主页：/linziyu 【摘要】：Spanner 是谷歌公司研发的、可扩展的、多版本、全球分布式、同步复制数据库。 它是第一个把数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。本文描述 了Spanner 的架构、特性、不同设计决策的背后机理和一个新的时间API ，这个API 可以暴 露时钟的不确定性。这个API 及其实现，对于支持外部一致性和许多强大特性而言，是非常 重要的，这些强大特性包括：非阻塞的读、不采用锁机制的只读事务、原子模式变更。 【关键词】Google Spanner, Bigtable, distributed database 【全文目录结构】 1. 介绍 2. 实现 2.1 Spanserver 软件栈 2.2 目录和放置 2.3 数据模型 3. TrueTime 4. 并发控制 4.1 时间戳管理 4.2 细节 5. 实验分析 5.1 微测试基准 5.2 可用性 5.3 TrueTime 5.4 F1 6. 相关工作 7. 未来的工作 8. 总结 致谢 参考文献 1 介绍 Spanner 是一个可扩展的、全球分布式的数据库，是在谷歌公司设计、开发和部署的。 在最高抽象层面，Spanner 就是一个数据库，把数据分片存储在许多Paxos[21]状态机上，这 些机器位于遍布全球的数据中心内。复制技术可以用来服务于全球可用性和地理局部性。客 户端会自动在副本之间进行失败恢复。随着数据的变化和服务器的变化，Spanner 会自动把 数据进行重新分片，从而有效应对负载变化和处理失败。Spanner 被设计成可以扩展到几百 万个机器节点，跨越成百上千个数据中心，具备几万亿数据库行的规模。 应用可以借助于Spanner 来实现高可用性，通过在一个洲的内部和跨越不同的洲之间复 制数据，保证即使面对大范围的自然灾害时数据依然可用。我们最初的客户是F1[35]，一个 第 1 页/共19 页 翻译：厦门大学计算机系教师 林子雨 /linziyu 本翻译论文源于厦门大学计算机系数据库实验室林子雨老师的云数据库技术资料专区 /cloud_database_view 谷歌广告后台的重新编程实现。F1 使用了跨越美国的 5 个副本。绝大多数其他应用很可能 会在属于同一个地理范围内的 3-5 个数据中心内放置数据副本，采用相对独立的失败模式。 也就是说，许多应用都会首先选择低延迟，而不是高可用性，只要系统能够从1-2 个数据中 心失败中恢复过来。 Spanner 的主要工作，就是管理跨越多个数据中心的数据副本，但是，在我们的分布式 系统体系架构之上设计和实现重要的数据库特性方面，我们也花费了大量的时间。尽管有许 多项目可以很好地使用BigTable[9]，我们也不断收到来自客户的抱怨，客户反映BigTable 无 法应用到一些特定类型的应用上面，比如具备复杂可变的模式，或者对于在大范围内分布的 多个副本数据具有较高的一致性要求。其他研究人员也提出了类似的抱怨[37]。谷歌的许多 应用已经选择使用Megastore[5]，主要是因为它的半关系数据模型和对同步复制的支持，尽 管Megastore 具备较差的写操作吞吐量。由于上述多个方面的因素，Spanner 已经从一个类 似BigTable 的单一版本的键值存储，演化成为一个具有时间属性的多版本的数据库。数据被 存储到模式化的、半关系的表中，数据被版本化，每个版本都会自动以提交时间作为时间戳， 旧版本的数据会更容易被垃圾回收。应用可以读取旧版本的数据。Spanner 支持通用的事务， 提供了基于SQL 的查询语言。 作为一个全球分布式数据库，Spanner 提供了几个有趣的特性：第一，在数据的副本配 置方面，应用可以在一个很细的粒度上进行动态控制。应用可以详细规定，哪些数据中心包 含哪些数据，数据距离用户有多远（控制用户读取数据的延迟），不同数据副本之间距离有 多远（控制写操作的延迟），以及需要维护多少个副本（控制可用性和读操作性能）