Google Spanner初探

Google在前几天发布了一篇提交给OSDI’12的论文,《Spanner: Google’s Globally-Distributed Database》,微博上讨论非常热烈,但真正去看完论文以后,比较失望

Spanner是基于BigTable的思路开发的,相比BigTable,它多了这么几个功能:

1. 不牺牲数据一致性的前提下,实现了跨数据中心的数据冗余,以及这样做的一个良好的副作用:数据本地化

2. 跨表,多行的事务处理

3. 树状的,半关系型的数据模型

技术上比较牛逼的是per tablet的paxos状态机组,结合GPS和原子钟实现的TrueTime,成为了跨地域数据一致性的基石,并自然而然的实现了其上的per tablet lock table,以及更上层,处理跨表或跨tablet事务的transaction manager。看到paxos和原子钟这两个关键词,许多猛人应该都可以脑补其余细节了。

可是归根到底,它还是一个key-value store,只是在data cell里也加入了时间戳。看它的所谓的半关系型数据模型,只想说:坑爹啊,这不就是在rowkey里做subkey的拼接吗。。。也难怪这段只写了草草半页

join呢?foreign key呢?secondary index呢?SQL92呢?说好的数据库呢?操作依然只是读和写,论文里都没专门讲,估计还不如之前Dremel的语义丰富

除了Google自己,“全球分布”到底有多少场景需要啊,如果不考虑跨数据中心,HBase大概也只比它少个跨表及多行的事务,而且HBase的同表多行原子操作也已经在路上了(HBASE-5229)。事务处理从来不是分布式NoSQL的命门而只是性能问题,但前面列的那几个RDB的标配功能才是分布式NoSQL的命门,没看到Spanner有改进

Spanner是BigTable的一个超集,一个改进,一个提升,但不是质的飞跃,或者说,它在数据的冗余分布上有了质的飞跃,可在功能性上只是改进而已,并不是圣杯,也不是NewSQL

论文里有个细节不知道有没有人注意到,Google自己广告业务后台(F1)从MySQL迁移到Spanner花了接近一年,当然,第一个总是会慢点

论文读的也匆忙,也许是错过了其中的要点和亮点,如有理解不对请同好指正。可还是觉得,开源界不会,也不需要,在这个事情上盲目跟进,投入产出比太低太低

(另有一事不明求解答:Spanner里的tablet和BigTable的tablet相比,含义和实现都有不同,Spanner里的tablet并不需要是一个单独连续的分片,事实上它是多个分片(directory)的组合,从而可以进行动态调整,把相关的分片聚集到同一个tablet以提高访问性能,可为什么Spanner里的tablet不再以LSM-tree的形式存储,而是采用了RDB使用的B-tree-like,更诡异的是,它同时还保留了WAL。。。这里论文并没有解释原因,这是HBase最有可能可以借鉴的地方)

 

Leave a Reply

Your email address will not be published.

使用新浪微博登陆