Google 在 OSDI '12 介绍了它的新一代的分布式数据库 Spanner
Google 同学有个好习惯，每隔一段时间会发表一些论文介绍一下他们公司内部使用的 infrastructure，这次的 OSDI 上他们拿出了新一代的分布式数据库 Spanner。论文的链接在这里：http://research.google.com/archive/spanner.html。文章我还没有来得及细看，不过 Spanner 这个系统我是早有耳闻。Google 同学在大规模分布式的数据存储和处理方面实力是很强的，算是他们的看家本领之一。早几年他们在 OSDI '06 的时候发布了介绍 bigtable 的论文，影响也很大。Bigtable 也是一种分布式数据库，和传统的关系数据库不同，bigtable 关注的重点是如何把数据分散到一个集群中的数十乃至数千台机器上去，提供 PB/EB 级别的存储容量以及在此之上的大规模并行处理。所以 bigtable 只保证单行数据的一次读写是原子性的，而不支持关系数据库那样的 transaction。同时为了弥补没有 transaction 的缺点，bigtable 的行格式比关系数据库要松散灵活很多：一行有若干定义好的 column family ，而每个 column family 下可以有数据类型相同的任意多个 column，每个 column 还可以按照时间顺序有多个 version。因此，许多在关系数据库中使用多行甚至多表组织的数据，在 bigtable 里可以直接用一行来处理和存储。这几年，bigtable 应该是 Google 同学内部使用最广泛的数据存储方式，Google Web Search 的索引数据，应该就是用 bigtable 存储的。
不过不管怎么说，没有 transaction 毕竟是很不方便。而且，bigtable 的设计是在同一个集群内的分布式系统，那么对于 Google 同学这样需要在全球各地部署的企业，还存在一个集群之间 data replication 的问题 —— 逻辑上是同一个数据库，但是数据需要在亚洲、欧洲、美洲各有一份，然后三个集群各自都可以写这个数据，还要保持互相之间一致性，也是件麻烦事。据我得到的消息，Google 同学也正在努力设法解决这个问题，目前的成果就是 Spanner。
按 Spanner 论文的摘要，这玩意是一个“scalable, multi-version, globally- distributed, and synchronously-replicated database.”，scalable 和 multi-version 应该意味着 spanner 继承了 bigtable 的特点，globally-distributed 应该意味着它是跨集群的，synchronously-replicated 应该意味着它解决了上一段提出来的 data replication 和一致性的问题。这里没提到 transaction ，估计十有八九还是不能实现传统关系型数据库的 transaction 的 ACID ，就是不知道能够比 bigtable 进步多少了。
看论文去了。也拭目以待 Google 能否真的象 bigtable 一样成功运用 spanner 解决新的问题。
没有transction级别的保证，谁敢相信他们的数据完整性？另外，感觉这东西本质上属于层次数据库，很老的东西了，不过可分布是个亮点。
说到synchronously-replicated，估计是有时间段的，而且不可能是实时，否则时差和数据量压力将是大问题。 不过不管怎么说，没有 transaction 毕竟是很不方便
展开讲一下，岂不是更好。。。 老兵帅客 发表于 2012-9-18 01:38 static/image/common/back.gif
没有transction级别的保证，谁敢相信他们的数据完整性？另外，感觉这东西本质上属于层次数据库，很老的东西 ...
mysql团队层撰文批评过bigtable，直指其开历史的倒车，抛弃了关系理论几十年的成果，把数据处理技术细节的重担又扔给了本应关注业务的码农。不过话说回来了，关系数据库面对海量数据的及时响应确实力所不及，而新的理论又没有出现，现实需求又需要这么个东西，在这个历史阶段中，必然会不断诞生这类实践产物，直到新的理论出现。 本帖最后由 gordon 于 2012-9-18 11:10 编辑
profer 发表于 2012-9-18 10:32 static/image/common/back.gif
mysql团队层撰文批评过bigtable，直指其开历史的倒车，抛弃了关系理论几十年的成果，把数据处理技术细节 ...
强，都是Google的fans ，据Google的人说，Google早期用的就是mysql，并且为mysql 提供了若干bug 和新特性的源代码。
Google重启炉灶，新开一套，肯定有自己的原因的。
另外很多时候都是先有实践后有理论的，其实就是工作中碰到一个问题，在解决问题中产生一个方法，一个方法变成了一个理论。
老兵帅客 发表于 2012-9-18 01:38 static/image/common/back.gif
没有transction级别的保证，谁敢相信他们的数据完整性？另外，感觉这东西本质上属于层次数据库，很老的东西 ...
浏览了一下，支持事务。使用行版本的方式避免了大量的锁，这点在分布式数据库上尤其重要。另外，似乎支持传统关系模型，至少可以通过SQL语言来做数据查询。 code_abc 发表于 2012-9-18 11:57 static/image/common/back.gif
浏览了一下，支持事务。使用行版本的方式避免了大量的锁，这点在分布式数据库上尤其重要。另外，似乎支持 ...
它那个支持事务是很有限的，于是程序员就得自己来处理那些事情。可以通过SQL来做数据查询不意味着支持关系模型。 今天粗略地浏览了一遍文章，发现 Spanner 比我原来设想的要强。和 bigtable 只支持单行锁和原子操作不同，spanner 同学已经支持 transaction 了（主贴只引用了摘要的第一句话，结果第二句话就是 transaction ……），文章声称 spanner 的 transaction 已经能够实现 external consistency，很有意思。一致性的具体实现依赖于 Paxos state machine 上的结论，这个东西我不懂，还得另外先花时间看懂了再说。 profer 发表于 2012-9-18 10:32 static/image/common/back.gif
mysql团队层撰文批评过bigtable，直指其开历史的倒车，抛弃了关系理论几十年的成果，把数据处理技术细节 ...
Google 很多东西都收到过类似的批评，用 MapReduce 进行数据处理也曾经被人称为巨大的倒退。我个人对此是不以为然的。不同领域有不同需求，互联网的上的大数据应用，所谓的“业务逻辑”一般不复杂，实践中 bigtable 这一类分布式的、key-value mapping 风格的基础设施在使用上并不比关系型数据库麻烦到哪里去，相反关系型数据库要想处理好这个海量数据的问题，各种分库分表手工 sharding 的 trick，给程序员的负担恐怕只会更重。 对是否支持transaction比较感兴趣,能否继续介绍一下。
若支持事务,则将来对db2/oracle/mysql的威胁就太大了。 {:189:} 我们早就看oracle不顺眼了。{:189:} 学习了，路过； 貌似天猫用的就是SPANNER，居然还是被热情的光棍们搞当机了。 学习了。谢谢。 我爱莫扎特 发表于 2012-11-17 18:21
貌似天猫用的就是SPANNER，居然还是被热情的光棍们搞当机了。
天猫应该改用阿里云自己的数据库了，去年双11之前改的。
页:
[1]