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

可观 投递于 2013/02/03 12:35 (共 4 段, 翻译完成于 02-06)
阅读 14234
收藏 50
0
加载中

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

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

我们相信,相对于在没有事务的环境下编程,利用应用程序来处理过多使用事务而导致的性能问题反而是更好的选择。
findever
翻译于 2013/02/06 12:12
2

听起来有点讽刺——不正是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上使用两阶段提交能够缓解可用性方面的问题。

AlfredCheung
翻译于 2013/02/05 14:59
1

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

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

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

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

AlfredCheung
翻译于 2013/02/05 15:21
1

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

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

AlfredCheung
翻译于 2013/02/06 10:45
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(37)

halfcoder
halfcoder

引用来自“缪斯的情人”的评论

关于这个覆盖全球的可货币化信息组织工具,啥意思?
原文是“their planet enveloping tool for organizing the world’s monetizable information”,所以“可货币化信息”其实就是“可以变成钱的信息”
Eova
Eova

引用来自“缪斯的情人”的评论

关于这个覆盖全球的可货币化信息组织工具,啥意思?
粉一个
C
ChenChang

引用来自“可观”的评论

引用来自“ChenChang”的评论

引用来自“Vigorski”的评论

引用来自“哪一天”的评论

引用来自“jollyking”的评论

"相比事务缺席,使用事务、甚至是由于过多使用事务而不得不处理相关的性能问题反而是更好的选择。", 自认理解能力低, 这句话读了3遍.

使用事务固然带来很多要处理的性能问题,但这总比没有事务好的多。我的理解!老外说话就是绕。

我的翻译:我宁愿去处理由于使用事务而带来的性能问题,也不愿在缺少事务的环境下编程

原文的意思是,相对于总是在缺少事务的环境下编程,我们相信,最好是由应用程序去处理,由于过度使用事务,而出现的性能问题。

过多的事务会带来性能问题,但是相对于缺乏事务支持的情况,宁可选择前者。

不错,过多变成过度,就完美了。原文有滥用的意思
可观
可观

引用来自“ChenChang”的评论

引用来自“Vigorski”的评论

引用来自“哪一天”的评论

引用来自“jollyking”的评论

"相比事务缺席,使用事务、甚至是由于过多使用事务而不得不处理相关的性能问题反而是更好的选择。", 自认理解能力低, 这句话读了3遍.

使用事务固然带来很多要处理的性能问题,但这总比没有事务好的多。我的理解!老外说话就是绕。

我的翻译:我宁愿去处理由于使用事务而带来的性能问题,也不愿在缺少事务的环境下编程

原文的意思是,相对于总是在缺少事务的环境下编程,我们相信,最好是由应用程序去处理,由于过度使用事务,而出现的性能问题。

过多的事务会带来性能问题,但是相对于缺乏事务支持的情况,宁可选择前者。
C
ChenChang

引用来自“Vigorski”的评论

引用来自“哪一天”的评论

引用来自“jollyking”的评论

"相比事务缺席,使用事务、甚至是由于过多使用事务而不得不处理相关的性能问题反而是更好的选择。", 自认理解能力低, 这句话读了3遍.

使用事务固然带来很多要处理的性能问题,但这总比没有事务好的多。我的理解!老外说话就是绕。

我的翻译:我宁愿去处理由于使用事务而带来的性能问题,也不愿在缺少事务的环境下编程

原文的意思是,相对于总是在缺少事务的环境下编程,我们相信,最好是由应用程序去处理,由于过度使用事务,而出现的性能问题。
H
HeGuangyong
有点不了了之的味道了。 事务的本质是强调其完整性。没有事务,需要站在什么角度强调其完整性?
赵云30
赵云30
我晕 我刚下载安装了mogodb -_-
Vigorski
Vigorski

引用来自“哪一天”的评论

引用来自“jollyking”的评论

"相比事务缺席,使用事务、甚至是由于过多使用事务而不得不处理相关的性能问题反而是更好的选择。", 自认理解能力低, 这句话读了3遍.

使用事务固然带来很多要处理的性能问题,但这总比没有事务好的多。我的理解!老外说话就是绕。

我的翻译:我宁愿去处理由于使用事务而带来的性能问题,也不愿在缺少事务的环境下编程
QLi
QLi

引用来自“李马燕”的评论

我乐个去 我还没学nosql呢这东西就out了

飞马踏燕→_→
mallon
mallon
吹吧,我现在是不信了。

相比通用的数据库,这些东西只能在很狭隘的场景中应用。
返回顶部
顶部
返回顶部
顶部