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