Google全球级分布式数据库Spanner.pptVIP

Google全球级分布式数据库 Spanner 提纲 Spanner背景 功能 体系结构 Spanserver 目录与放置 数据模型 TrueTime Google Spanner并发控制 Spanner Spanner是个可扩展，多版本(multi-version )，全球分布式(globally-distributed )还支持同步复制(synchronously-replicated )的数据库。它是Google的第一个可以全球扩展并且支持外部一致的事务的数据库。 Spanner支持多用途的事务处理，并且提供了一个基于SQL的查询语言。作为世界级分布的数据库，Spanner更有一些令人感兴趣的特色： Spanner 1. 应用程序可以通过复制装置动态的对数据进行微控制。还可以通过制定约束条件来指定数据中心和其中包含的数据（无视数据与用户间的距离，数据与数据间的距离及数据保持的份数）。系统动态的和透明的在数据中心之间转移数据来保证资源的平衡利用。 2. Spanner有两个特性是很难在分布式数据库中实现的：读写的外部一致性和基于时间标记的全局读一致性。这让Spanner可以在全球范围内保持数据的一致备份，MapReduce一致执行和原子的Schema修改，即使是连续操作。 Spanner 这些特性保证了Spanner可以有序的在世界范围内响应事务处理，即使是分散式的事务。时间标记反应了事务的顺序。另外，序列化的时间确保了外部一致性：如果事务T1在另一个事务T2之前提交，那么T1提交的时间标记是小于T2的。Spanner能做到这些，离不开一个用GPS和原子钟实现的时间API。这个API能将数据中心之间的时间同步精确到10ms以内。 功能：无锁读事务，原子schema修改，读历史数据无阻塞。 Spanner背景 Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级，可以扩展到数百万的机器，数已百计的数据中心，上万亿的行。更给力的是，除了夸张的扩展性之外，它还能同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破CAP的枷锁，在三者之间完美平衡。 Design Goals Spanner背景 要搞清楚Spanner原理，先得了解Spanner在Google的定位。 F1 和众多互联网公司一样，在早期Google大量使用了Mysql。Mysql是单机的，可以用Master-Slave来容错，分区来扩展。但是需要大量的手工运维工作，有很多的限制。因此Google开发了一个可容错可扩展的RDBMS-F1。和一般的分布式数据库不同，F1对应RDMS( Relational Database Management System )应有的功能，毫不妥协。起初F1是基于Mysql的，不过以后会逐渐迁移到Spanner。 F1特点 7×24高可用。哪怕某一个数据中心停止运转，仍然可用。 可以同时提供强一致性和弱一致性。 可扩展 支持SQL 事务提交延迟50-100ms，读延迟5-10ms，高吞吐 众所周知Google BigTable是重要的NoSql产品，提供很好的扩展性，开源世界有HBase与之对应。为什么Google还需要F1，而不是都使用 BigTable呢？因为BigTable提供的最终一致性，一些需要事务级别的应用无法使用。同时BigTable还是NoSql，而大量的应用场景需要有关系模型。就像现在大量的互联网企业都使用Mysql而不愿意使用HBase，因此Google才有这个可扩展数据库的F1。而Spanner就是 F1的至关重要的底层存储技术。 Colossus（GFS II） [k??l?s?s] Colossus是第二代GFS，对应开源世界的新HDFS。Google文件系统GFS是构建在廉价的服务器之上的大型分布式系统。它将服务器故障视为正常现象，通过软件的方式自动容错，在保证系统可靠性和可用性的同时，大大减少了系统的成本。 GFS是Google云存储的基石，其它存储系统，如Google?Bigtable，Google?Megastore，Google?Percolator [p:klet(r)]均直接或者间接地构建在GFS之上。另外，Google大规模批处理系统MapReduce也需要利用GFS作为海量数据的输入输出。 Colossus系统架构 Colossus（GFS II） GFS将整个系统的节点分为三种角色：GFS?Master（总控服务器），GFS?Chunkserver（数据块服务器，简称CS）以及GFS?C