|
|
Google 同学有个好习惯,每隔一段时间会发表一些论文介绍一下他们公司内部使用的 infrastructure,这次的 OSDI 上他们拿出了新一代的分布式数据库 Spanner。论文的链接在这里:http://research.google.com/archive/spanner.html。 _, W' e$ B" S0 Q, t
0 y% G# W' @8 R8 w0 ~文章我还没有来得及细看,不过 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 存储的。5 z, |& s1 G* \, Y& b$ R% [: v0 u1 Y
* t8 D+ i+ i4 n" ^/ s$ {1 |6 D0 e# K不过不管怎么说,没有 transaction 毕竟是很不方便。而且,bigtable 的设计是在同一个集群内的分布式系统,那么对于 Google 同学这样需要在全球各地部署的企业,还存在一个集群之间 data replication 的问题 —— 逻辑上是同一个数据库,但是数据需要在亚洲、欧洲、美洲各有一份,然后三个集群各自都可以写这个数据,还要保持互相之间一致性,也是件麻烦事。据我得到的消息,Google 同学也正在努力设法解决这个问题,目前的成果就是 Spanner。
# J' _& J1 b3 }# R9 O0 m" t) m& t1 `- T& K
按 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 进步多少了。. M( R8 C+ A+ F; _" S. ?4 N
, B9 S5 D& v1 u+ n
看论文去了。也拭目以待 Google 能否真的象 bigtable 一样成功运用 spanner 解决新的问题。6 x; d1 Q6 o, n3 r5 T7 Z$ N
! `9 i2 k/ Y4 g( H. c: s
|
评分
-
查看全部评分
|