Spannervs.F1：谷歌两大数据管理利器的整体对比及关联

http://www.csdn.net/article/2013-10-10/2817138-f1-and-spanner-holistically-compared

自2012年9月搜索巨头Google发布Spanner论文已有一年之久&＃xff0c;期间各种对比可以说是数不胜数。近日&＃xff0c;ThoughtWorks India技术总监Srihari Srinivasan&＃xff08;曾供职于Philips Consumer Electronics、Ivega Corp等多家企业&＃xff09;总整体上对比了Google的两个数据库系统&＃xff0c;并分析了两个系统之间的联系及配合机制。以下为译文&＃xff1a;

F1设计的主旨

• 系统可以添加资源进行纵向扩展
• 无需改变应用程序就具备数据分片及均衡的能力
• 对事务支持ACID特性
• SQL的全支持&＃xff0c;同时支持索引

Spanner目标

• 最主要的目的就是跨数据中心的管理及复制数据
• 数据的重分片及均衡能力
• 主机间数据的自动迁移

从整体上看F1

1. F1建立于Spanner之上&＃xff0c;Spanner的特性包括&＃xff1a;分布事务间&＃xff08;2PC&＃xff09;提供强一致性、基于时间戳的整体排序、通过Paxos进行同步复制、容错、数据的自动均衡等。

2. 通过F1增加的特性&＃xff1a;

• 在整体数据上分配SQL查询&＃xff0c;并提供join能力
• 索引的事务一致性
• 异步模式转变
• 使用新的ORM库

F1的架构

1. 用户通过客户端库交互。

2. 任何服务器都可以接收SQL查询请求。

3. F1客户端需要通过一个本地负载均衡器&＃xff0c;有助于降低延时。如果需要&＃xff0c;它会负责把请求转发到本地/最近数据中心里的F1服务器。

4. F1与Spanner的服务器会位于同一个数据中心。

5. Span-server会从Colossus File System&＃xff08;GFS继任者&＃xff09;中获得数据。

• 每个span-server都搭配了一个称为Tablet的存储抽象&＃xff0c;通常负责100-1000个tablet实例。这些Tablet数据储存在类似B-Tree的一组文件及预写入日志上&＃xff0c;这些文件都位于CFS之上。
• 在tablet之上&＃xff0c;每个span-server同样还实现了1个Paxos状态机。

6. F1服务器大部分都是无状态的&＃xff0c;鉴于其不负责数据存储&＃xff0c;因此添加及删除起来非常方便&＃xff0c;不会涉及到数据转移。

7. F1进程通过主从方式组织&＃xff0c;F1 master首先接收查询&＃xff0c;然后再委托给slave处理。

8. Master同时还负责slave poll的维护。

9. 系统的吞吐量可以通过增加F1 master、F1 slave及span-server的数量完成。

10. 数据储存通过Spanner处理

• Spanner将数据行分割成bucket抽象&＃xff0c;称之为1个目录——共享1个通用前缀的连续key集合。血统关系通过目录实现。
• 添加1个span-server将导致跨Spanner tablet的数据重新分配&＃xff0c;但是却不会波及到其它的F1服务器&＃xff0c;这个操作对F1服务器完全透明。
• 鉴于数据在不同地理位置上的多个数据中心同步&＃xff0c;提交的延时将非常高&＃xff08;50-150毫秒&＃xff09;。

11. 系统同样包含了只读副本&＃xff0c;这些副本将不会计算到Paxos算法中。只读副本只用于读的快照&＃xff0c;因此支持OLTP和OLAP的负载隔离。

数据模型——分层架构

• 从逻辑层看F1&＃xff0c;它的数据模型非常类似RDBMS&＃xff1b;此外&＃xff0c;F1中的表格可以用分层模式组织。
• 分层中&＃xff0c; root table对应的行被称为root row。
• Root row的child table对应行被储存在单独的Spanner目录中。
• 客户端应用程序通过调用INTERLEAVE IN声明数据库架构的层次。
• 目录表格的每行都拥有一个键K&＃xff0c;连同子表中所有行一起&＃xff0c;从K开始按照字典顺序递增组成一个目录。
• 每个子表格都与父表格中的行聚合并交叉。
• 论文中还强调了读、写操作可以从分层架构中获得的好处&＃xff0c;然而在实际上&＃xff0c;分层架构并不是F1中唯一的模型。
• F1中的索引具有事务性并且完全一致&＃xff0c;在Spanner中使用单独的表进行存储&＃xff0c;键则使用索引键与被索引表格主键的串连。
• 使用两种类型的物理存储布局——Local及Global。

F1中的查询处理

F1中的查询管理类似于当下多数的SQL-on-Hadoop解决方案&＃xff0c;比如Cloudera的Impala、Apache Drill及无共享并行数据库。

查询的生命周期

• 每个查询都会配备一个协调节点&＃xff0c;这个节点负责接收SQL查询请求。
• 协调器会负责计划执行以及从结果的接收&＃xff0c;并做结果的聚合、排序及过滤&＃xff0c;最后会将结果返回给客户端。
• 基于数据被不停的分割&＃xff0c;计划器还负责分割长度的制定&＃xff0c;以最小化查询的时间。
• 基于被处理数据及分割范围&＃xff0c;计划器/优化器甚至会对预处理数据进行再分配。

网络延时的处理

F1的主数据存储就是Spanner&＃xff0c;可以看成是一个远端数据资源&＃xff0c;因此F1 SQL同样可以访问远端低延时数据资源。

访问远端数据资源产生的延时通过查询不同阶段的批处理及流处理缓和&＃xff0c;同时查询操作符经过特定的设计为处理管道后续阶段传输尽可能多的数据。

最后

自2012年起&＃xff0c;F1系统就负责了AdWords广告活动的数据管理。AdWords是个庞大的生态系统&＃xff0c;设计数百的应用程序及数千的用户。数据库里的资料超过100TB&＃xff0c;每秒处理数十万请求&＃xff0c;每天扫描上百万亿的数据行。可用性达到5个9&＃xff0c;对比传统的MySQL系统&＃xff0c;即使在计划外宕机时&＃xff0c;延时都不会显著增加。

原文链接&＃xff1a; F1 and Spanner Holistically Compared&＃xff08;编译/仲浩 审校/周小璐&＃xff09;