Google Spanner的革命，NoSQL谢幕，NewSQL登场 已翻译 100%

最近，Google发布了一篇关于Spanner的论文，介绍他们覆盖全球的可货币化信息组织工具。阅读着这篇文章，我又嗅出了其中蕴含的隽永味，就像Google其它的优秀论文一样。非常经典。Jeff Dean早在2009年就已经预言过Spanner的庞大规模。时至今日，Spanner看似已经完完全全地上线了，只等处理那“横跨成百上千个数据中心、几千万台计算机中的数兆条记录。” 天哪。

牛人们还要对Spanner进行进一步的评估，我期待着更多拥有敏锐洞察力的评论和文章。实在是有太多东西需要研究和了解了。然而，对我触动最深的其实是这篇论文里埋藏很深的一节，它介绍的是Google从NoSQL滑向NewSQL的动机。一段精彩的引文:

我们相信，相对于在没有事务的环境下编程，利用应用程序来处理过多使用事务而导致的性能问题反而是更好的选择。

听起来有点讽刺——不正是Bigtable启动了NoSQL/最终一致性/key-value数据库的狂潮吗？

可以看到，大量批评NoSQL所针对的问题同样也发生在了Google自己身上。而只有Google，以典型的Google方式，依靠先进的理论和技术的完美融合，解决了这些问题。成果就是——程序员们可以在扩展性和可用性的同时，得到真正的事务、模式和查询语言。

且看完整的文字:

Spanner向应用提供了以下数据功能：一个基于模式化的、准关系型表的数据模型，一门查询语言，以及通用的事务。我们之所以转而支持这些功能，是出于多种因素的考虑。对模式化准关系型表和同步复制的支持是受Megastore[5]的流行所驱动。

Google内部有300个以上的应用使用Megastore(尽管它的性能很弱)，原因在于它的模型比Bigtable更简单，而且还支持跨数据中心的同步复制。(Bigtable只支持最终一致性的复制)。例如，Gmail、Picasa、Calendar、Android Market和App Engine，都使用Megastore。

类似SQL的查询语言同样也很必要，从Dremel[28]这个交互式数据分析工具的流行就可见一斑。最后一点，由于缺少跨行事务，Bigtable受到了大量批评，Percolator[32]是为解决这个问题而生的众多方案之一。

一些专家声称，由于性能和可用性方面的问题[9,10,19]，两阶段提交显得过于昂贵，无法支持。但我们相信，对程序员们来说，相比事务缺席，使用事务、甚至是由于过多使用事务而不得不处理相关的性能问题反而是更好的选择。在Paxos上使用两阶段提交能够缓解可用性方面的问题。

代价呢？看起来应该是时延，不过，虽然我们并没有进行测试，也可以看出这种时延问题并不严重。无论如何，Google认为处理时延比对付事务的缺乏要容易得多。我觉得这很吸引人。不由得回想起这么多年来RDBMS和NoSQL之间喋喋不休的争吵，真是无趣啊。

不知道Amazon能不能把他家的高可用购物车应用放到Spanner上去？

Spanner会用Bigtable那样的方式，成为我们的未来吗？

这篇论文会像Bigtable的论文一样，掀起热潮吗？恐怕不会。这类项目的推动力完全在开源组织，而现在还很少有组织需要支持全球范围的事务(至少目前还很少)，大部分人仍然在用Bigtable的方式做事，所以恐怕要等上一段时间才会看到开源界进行这方面的行动。

影响开源界努力的还有一个不利因素，那就是Spanner使用了GPS和原子钟硬件。纯软件的项目比较容易获得成功。但愿云服务商们能更进一步，提供更专业化的服务。它们应该把云内时间同步作为基本功能。可惜啊，我们仍然局限在「云即互联网」的模型中，还未能进入「云即专业、高效软件容器」的世界。

另外还有一个不利因素。身为磁盘方面的大师，Google把Spanner放在一个全新的文件系统(Colossus，巨人)上可以说是毫不奇怪。在磁盘的运用方面，谁能跟Google比？如果我们现在再去沿着Spanner的路子研究磁盘，显然是没法做得过Google了——在这方面，它已经领先了我们N多年。那么，也许跳过一代，直接研究RAM/SSD会比较有意义一点。这一次，开源界是不是不应该再亦步亦趋地跟着Google走，而应该试着转换一下目光，在其它切入点努力地创新一下？