Google发布Spanner论文，宣告重回分布式事务语义

上个月，在Operating System Design and Implementation（OSDI '12）大会上，Google放出了Spanner的详细信息——Spanner是一个高可伸缩、全球复制的半关系型数据库。上周，Google又给出了论文合著者Wilson Hsieh的一个与OSDI 2012上演讲相关的视频，该视频专注于论文里的一些关键概念，InfoQ的Alex Popescu发表了一篇文章，内容是Berlin Buzzwords上Alex Lloyd提供的更多详细信息。研究证明ACID语义不需要牺牲高可伸缩性，推翻了NoSQL是高可伸缩性持久化的万灵药的想法。论文中的这句话很好地表明了这一观点：

我们认为，最好是让应用程序开发者在出现瓶颈时处理由事务使用过度引起的性能问题，而非总是在缺少事务的情况下进行编码。

Spanner项目源于Google Adwords系统在持久化方面的需要，该解决方案既要满足关系型与事务性，同时又要在全球范围内可伸缩部署。MegaStore仅部分满足这些关注点，因为在跨洲际事务时没有可预计的延时是无法实现其一致性保障的。在Spanner中，分布式事务的延时问题是通过Google的TrueTime API来处理的，这基本上是一个针对时钟不确定性（clock uncertainty）问题的解决方案。

通过大范围网络中的多个参考时间确定时钟时间时，时钟漂移和网络延时会引入时钟不确定性（在论文中用ε符号表示）。参考时间混合了GPS时间和原子时钟，通过冗余降低了它们的错误率。通过确定影响时钟不确定性的因素，将其上限控制在一个承诺的等待间隔里（两倍的ε），就能实现外部一致性保证以及其他一些好处，比如无锁读事务、非阻塞读以及原子Schema变更。因此，承诺的等待间隔直接和时钟不确定性绑在了一起，不确定性越高，等待间隔就越长，也会拖慢Spanner。然而，为了降低较长等待间隔（通常是10ms，但呈现长尾分布）带来的影响，Spanner在等待时间里执行了Paxos（一致协议）或两阶段提交的准备阶段。

Spanner的数据模型与Megastore类似，都是半关系型层次化结构模型。Timothy O'Brien在O'Reilly上的博客里对Spanner做了一个总结：

一套Spanner部署是由一些管理服务器组成的，它们是用来管理跨数据中心的多个“区域”（Zone）的。一台“区域主服务器”（Zone master）和一系列“位置代理”（location proxy）管理了成百上千的“Spanserver”，它们是在Spanner数据库中执行批量工作的。Spanserver中存储的数据单元称为“目录”（directory），每个单元中都实现了一个位于Tablet之上的Paxos状态机。Spanserver以B树的形式存储数据，使用了一个复合键，再结合上一个时间戳和一个值。

Cloudant Labs在他们的博客里指出了Spanner缺少的两块东西：

显然Spanner目前还不支持二级索引的自动处理。而且，它不支持以后能达到一致状态的“离线”访问（像CouchDB那样的离线访问）。

NuoDB为他们的解决方案申请了专利，从他们的专利描述来看，也实现了和Spanner相同的功能，但Google宣称Spanner是第一个全球复制、可伸缩的ACID数据库。围绕NoSQL vs. NewSQL之争，Spanner对您的产品和项目实现会产生何种影响呢？

查看英文原文：Google Publishes Paper On Spanner Ushering a Return to Distributed Transactional Semantics