http://www.csdn.net/article/2013-10-10/2817138-f1-and-spanner-holistically-compared
自2012年9月搜索巨头Google发布Spanner论文已有一年之久,期间各种对比可以说是数不胜数。近日,ThoughtWorks India技术总监Srihari Srinivasan(曾供职于Philips Consumer Electronics、Ivega Corp等多家企业)总整体上对比了Google的两个数据库系统,并分析了两个系统之间的联系及配合机制。以下为译文:
1. F1建立于Spanner之上,Spanner的特性包括:分布事务间(2PC)提供强一致性、基于时间戳的整体排序、通过Paxos进行同步复制、容错、数据的自动均衡等。
2. 通过F1增加的特性:
1. 用户通过客户端库交互。
2. 任何服务器都可以接收SQL查询请求。
3. F1客户端需要通过一个本地负载均衡器,有助于降低延时。如果需要,它会负责把请求转发到本地/最近数据中心里的F1服务器。
4. F1与Spanner的服务器会位于同一个数据中心。
5. Span-server会从Colossus File System(GFS继任者)中获得数据。
6. F1服务器大部分都是无状态的,鉴于其不负责数据存储,因此添加及删除起来非常方便,不会涉及到数据转移。
7. F1进程通过主从方式组织,F1 master首先接收查询,然后再委托给slave处理。
8. Master同时还负责slave poll的维护。
9. 系统的吞吐量可以通过增加F1 master、F1 slave及span-server的数量完成。
10. 数据储存通过Spanner处理
11. 系统同样包含了只读副本,这些副本将不会计算到Paxos算法中。只读副本只用于读的快照,因此支持OLTP和OLAP的负载隔离。
F1中的查询管理类似于当下多数的SQL-on-Hadoop解决方案,比如Cloudera的Impala、Apache Drill及无共享并行数据库。
查询的生命周期
网络延时的处理
F1的主数据存储就是Spanner,可以看成是一个远端数据资源,因此F1 SQL同样可以访问远端低延时数据资源。
访问远端数据资源产生的延时通过查询不同阶段的批处理及流处理缓和,同时查询操作符经过特定的设计为处理管道后续阶段传输尽可能多的数据。
最后
自2012年起,F1系统就负责了AdWords广告活动的数据管理。AdWords是个庞大的生态系统,设计数百的应用程序及数千的用户。数据库里的资料超过100TB,每秒处理数十万请求,每天扫描上百万亿的数据行。可用性达到5个9,对比传统的MySQL系统,即使在计划外宕机时,延时都不会显著增加。
原文链接: F1 and Spanner Holistically Compared(编译/仲浩 审校/周小璐)