PDF《主讲教师：林子雨 http://www.cs.xmu.edu.cn/》

? 可以同时提供强一致性和弱一致;

? 可扩展;

? 支持 SQL;

? 事务提交延迟 50-100ms,读延迟 5-10ms,高吞吐. 众所周知,Google BigTable 是重要的 NoSQL 产品,提供很好的扩展性,开源世界有 HBase 与之对应. 为什么 Google 还需要 F1, 而不是都使用 BigTable 呢?这是因为, BigTable 提供的 最终一致性 ,无法满足一些需要强事务一致性的应用的需求.同时,BigTable 还是NoSQL,而大量的应用场景需要关系模型(现在大量的互联网企业都使用 MySQL 而不 愿意使用 HBase) .因此,Google 才设计了可扩展数据库 F1,支持关系模型,而Spanner 就是F1 的至关重要的底层存储技术. 12.1.2 Colossus(GFS II) Colossus 也是一个不得不提起的技术,它是第二代 GFS,对应于开源世界的新 HDFS. GFS 是著名的分布式文件系统.第一代 GFS 是为批处理而设计的,对于大文件很友好, 吞吐量很大,但是延迟较高.所以,使用它的系统不得不对 GFS 做各种优化,才能获得良 好的性能.那为什么 Google 没有考虑到这些问题,设计出更完美的 GFS 呢?这是因为,那 个时候是

2001 年,Hadoop 出生是在

2007 年.如果 Hadoop 是世界领先水平的话,GFS 比 世界领先水平还领先了

6 年.同样地,Spanner 面世时间大概是

2009 年,等到我们看到论文 厦门大学计算机科学系研究生课程 《大数据技术基础》 主讲教师:林子雨 http://www.cs.xmu.edu.cn/linziyu

6 /

16 的时候(注:Google Spanner 英文论文于

2012 年9月发布) ,估计 Spanner 在Google 已经很 完善了, 同时可以预见到, Google 内部应该已经有更先进的替代技术在酝酿了. 最早在

2015 年才会出现 Spanner 和F1 的开源产品. Colossus 是第二代 GFS.Colossus 是Google 重要的基础设施,因为,它可以满足主流 应用对 GFS 的要求.Colossus 的重要改进有: ? 优雅 Master 容错处理 (不再有 2s 的停止服务时间);

? Chunk 大小只有 1MB (对小文件很友好);

? Master 可以存储更多的 Metadata(当Chunk 从64MB 变为 1MB 后,Metadata 会扩 大64 倍,但是 Google 也解决了). ? Colossus 可以自动分区 Metadata.使用 Reed-Solomon 算法来复制,可以将原先的

3 份减小到 1.5 份,提高写的性能,降低延迟. 12.2与BigTable、Megastore 的对比 Spanner 主要致力于跨数据中心的数据复制上,同时也能提供数据库功能.在Google 类似的系统还有 BigTable 和Megastore.和这两者相比,Spanner 又有什么优势呢? BigTable 在Google 得到了广泛的使用,但是,它不能提供较为复杂的 Schema,也无法 提供在跨数据中心环境下的强一致性.Megastore 有类似于 RDBMS 的数据模型,同时也支 持同步复制,但是,它的吞吐量太差,不能适应应用要求.Spanner 不再是类似 BigTable 的 版本化 key-value 存储,而是一个 临时多版本 的数据库.所谓的 临时多版本 是指, 数据是存储在一个版本化的关系表里面, 存储的数据会根据其提交的时间打上时间戳, 应用 可以访问到较老的版本,另外,老的版本也会被垃圾回收掉. Google 官方认为 Spanner 是下一代 BigTable,也是 Megastore 的继任者. 12.3 Spanner 的功能 从高层看,Spanner 是通过 Paxos 状态机将分区好的数据分布在全球的.数据复制是全 球化的, 用户可以指定数据复制的份数和存储的地点. Spanner 可以在集群或者数据发生变 化的时候将数据迁移到合适的地点, 做负载均衡. 用户可以指定将数据分布在多个数据中心, 不过更多的数据中心将造成更多的延迟.用户需要在可靠性和延迟之间做权衡,一般来说, 复制