google数据库：spanner论文的翻译！

前记：博士毕业后没怎么读论文，拿这篇论文练练手，顺便翻译，巩固一下英语，嘿嘿！

Spanner: Google全球分布式数据库

相关工作

Megastore和DynamoDB提供了一种存储服务，用于数据中心之间的一致性数据复制。DynamoDB提出了一种键值接口，另外只能进行局域内复制。跟Megastore类似地， Spanner提供一种半关系型数据模型和类似的策略语言。然而，Megastone性能不高，原因是它基于Bigtable构建，而Bigtable本身引入了大量的通讯开销。Megastone也不支持长活leaders，即多个数据复制可以启动写。在Paxos协议中，多个数据拷贝的写操作甚至在逻辑上不冲突的情况下也必定引起冲突，从而导致同一Paxos组的一秒多个写操作的吞吐量骤减。Spanner提供更高的性能，通用的事务处理和外部的一致性。

Pavlo对比了各种数据库和MapReduce的性能。通过Pavlo提出的几种方法，基于分布式键值存储的数据库功能得以提升，从而表明两方面的工作可以汇总一体。我们赞同同样的结论，但是进一步描述了集成多个层次的方法具有一定优势：比如，spanner将复制和并行控制集成从而降低了提交等待的开销。

架构在复制存储之上的分层事务的术语最早可以追溯到Gifford的博士论文。Scatter是最近一篇基于DHT键值存储的论文，其就将分层事务构建于一致性复制之上。而Spanner提出了比Scatter层次更高的接口。基于Paxos，Gray和Lamport描述了一种非阻塞提交协议。跟二态提交相比，这种协议产生更多的消息开销，从而增加了在广泛分布的组中提交操作的消息开销。Walter提供了一种用于数据中心内与快照隔离类似的方法。相对地，spanner只读事务提供了更自然的语义，因为它支持针对所有操作的外部一致性。

很多最近的工作致力于减少或消除锁开销。Calvin消除并发控制，即预分配时间戳，然后按照时间戳的顺序执行事务。HStore和Granola分别都支持各自的事务类型的分类，其中一些事务类型可避免锁。然而，没有一个系统提供外部一致性。Spanner通过支持快照隔离解决了竞争的问题。

VoltDB是一种在大范围的故障恢复下支持主从复制的sharded内存驻留数据库，却不是一种通用的复制配置。VoltDB是NewSQL的一个范例。NewSQL成为支持可扩展SQL的市场推力。很多商用数据库，比如Marklogic和Oracle的Total Recall，实现了过去读。Lomet和Li为当时的数据库描述了一种实现策略。

相对于可信的参照时钟，Farsite推导出时钟不确定性的边界（比TrueTime要不精确的多）：在Farsite中，服务器租期跟Spanner保持Paxos租期的方式一样。早先的工作采用松散的同步时钟来实现并发控制的目的。本文表明，TrueTime可以推断出Paxos状态机集合中的全球时间。

未来工作

过去一年的大半时间，我们和F1组一起将Google的广告后台从MySQL迁移到Spanner。我们积极地改进Spanner的监测和支持工具以及调整其性能。除此之外，我们致力于改善备份和恢复系统的功能和性能。目前，我们正在实现Spanner的策略语言，第二目录的自动维护和自动的基于负载的reshard。更长期的计划是，我们将研究一些特征。最优的并行读操作可能是值得探讨的策略，但是初步实验已经表明正确的实现它确实不易。另外，我们计划最后支持Paxos配置的直接改变。

倘若我们期盼许多应用在相邻较近的数据中心间拷贝数据，TrueTime可能会显著的影响性能。我们没有发现有什么不可逾越的困难将TrueTime减少1ms以内。Time-master-query间隔可以被降低，而且更好的时钟晶体也相对便宜。提升的网络技术可以减少time-master-query的延迟，或者通过一种时间分布式技术甚至可以避免延迟。

最后，还有很多值得改进的地方。尽管spanner根据节点数是可扩展的，针对复杂的SQL查询，节点本地的数据结构相对性能较差，因为这些数据结构主要为简单的键值访问设计的。数据库文献的算法和数据结构能够很大程度的提高单个节点的性能。第二，为响应客户负载自动在数据中心间进行数据自动迁移长久以来是我们的目标，但是为有效的实现这个目标，我们需要具备能以自动协调的方式在数据中心间迁移客户应用的进程。进程迁移产生了更困难的问题，即数据中心间的资源获取和分配的管理问题。

结论

总之，Spanner结合并扩展了两个研究团体的想法：从数据中心团体，一个熟悉的、易用的、半关系接口，事务和基于SQL的查询语言；从系统团体，可扩展性、自动分片、容错能力、一致性复制、外部一致性和广域分布。自从Spanner成立以来，我们使用了5年多的时间才迭代到当前的设计和实现。之所以耗费如此长的迭代周期是因为较慢地意识到Spanner不仅仅解决全球复制的名字空间问题，而要重点关注Bigtable所遗漏的数据库特征。

我们设计比较突出的方面是：Spanner特征集合的关键是TrueTime。我们已经表明了在时间API中进行时钟的不确定性的细化使得建立更强大的时间语义成为可能。另外，由于底层系统在时钟不确定性强制更严格的界限，从而更强大的语义开销减少了。作为研究团体，我们不应该在设计分布式算法时仍然依赖于松散的同步时钟。