【分布式系统工程实现】GFS&Bigtable设计的优势

标签: 分布式架构 | 发表时间:2010-11-13 02:08 | 作者:日照 hikerlive
分享到:
出处:http://rdc.taobao.com/blog/cs

目前,知名度比较高的通用存储系统包括:Google GFS&Bigtable,Amazon Dynamo,Microsoft Azure存储系统及Yahoo PNUTS。其中,GFS&Bigtable,Azure存储系统及Yahoo PNUTS都有总控节点,Amazon Dynamo采用去中心化的P2P设计。

Amazon Dynamo看起来很优美,比如Dynamo论文中提到的技术比较酷,Dynamo没有中心节点,可以支持更大的系统规模。然而,Dynamo不是我心目中的理想架构,因为Dynamo有一致性的问题,系统设计复杂但解决的问题有限。如果需要保证一致性,就必须要求同一时刻对同一份数据只有一个更新节点,Dynamo显然不符合要求,可能出现数据丢失等不一致的情况。虽然对于很多场景能够通过冲突合并来解决,另外,Dynamo由于采用一致性Hash的方法进行数据分布,数据不是连续存储的,不能支持高效的扫描操作,所以数据模型只能是简单的<Key, Value>模型,不能支持类似数据仓库这种需要扫描某个用户且单个用户数据量可能特别大的应用场景。总之,去中心化的系统一般有两个问题:1, 一致性问题;2, 顺序扫描效率低下

Microsoft Azure和普通NOSQL系统设计差别挺大的。普通的NOSQL系统一般是从业务出发,支持某一类业务必要的特性,而Microsoft Azure针对的主要用户为企业级用户,设计从SQL全集出发,尽量支持能够支持的SQL特性。和Yahoo PNUTS一样,Microsoft Azure采用单层设计,不同的是,Yahoo PNUTS通过将操作日志写入到可靠的消息中间件来简化系统其它部分的设计,Microsoft Azure将操作日志Replication功能做为子表服务节点的一个模块(用户使用的Azure数据库实例相当于一个子表),保证操作日志至少同步到两台机器才返回给客户端。抛开Microsoft Azure由于兼顾过多的SQL特性导致的工程复杂度及性能损耗,Microsoft Azure架构的一个问题是:由于每个子表的操作日志分开,多个子表之间的操作日志无法聚合,所以,单机支持的子表个数有限,比如Microsoft Azure限制单机的Azure数据库实例最多为650个。如果单个子表太大,负载平衡效果必然不够好;如果单个子表较小,比如常见的256MB一个子表,单机服务的数据有限。Microsoft Azure的设计可参考论文

Yahoo PNUTS采用消息中间件Yahoo Message Broker来进行操作日志的可靠存储。虽然多个子表将操作日志写入到不同的Queue,不过在消息中间件中,每个Message Broker可以服务很多的Queue,多个子表写入的操作日志仍然可以因为写入一台机器而进行聚合。Yahoo PNUTS的主要问题是消息中间件本身的扩展性,由于消息中间件为了避免复杂性设计成一个同构的系统,消息中间件本身存储的数据量不能太大。线下的计算,比如MapReduce批处理,计算过程中更新量很大,消息中间件不能胜任。(同构系统的问题参考系统可扩展性文章)

GFS和Bigtable两层的设计是一个几乎完美的组合。GFS本质上是一个弱一致性系统,可能出现重复记录、记录乱序等各种问题(后续有文章专门分析原因),Bigtable是GFS之上的一个索引层,为了服务百PB级别的应用,采用两级的B+树索引结构。GFS保证成功的记录至少写入一次并由Bigtable记录索引,由于Bigtable是一个强一致性系统,整个系统对外表现为强一致性系统。为了保证Bigtable的强一致性,同一时刻同一份数据只能被一台机器服务,且Bigtable论文中的Tablet Server对每个Tablet是没有备份的。当Tablet Server宕机时,由于只需要排序很少的操作日志并且加载服务的Tablet的索引,宕机恢复可以做到一分钟以内。Bigtable分裂和迁移到只需要修改或者加载索引数据,因此效率很高,整个系统的扩展性很好。GFS&Bigtable架构广受质疑之处主要体现在两个方面:

1, GFS&Bigtable架构实时性不好。

2, Bigtable Tablet Server的单点问题。

第一个对Bigtable实时性的质疑,大体有两个原因:第一点是由于Bigtable的Tablet和GFS的Chunk可能不在一台机器上,读取操作可能要走网络;第二点是由于Bigtable每次随机读取都需要读取一块数据,比如16K, 32K或者64K。第一点可以通过本地化策略来解决,第二点由于磁盘的寻道时间一般为8~10ms,读取一整块的overhead不会太高,且Bigtable系统内部的Block Cache和Key-Value Cache可以解决很多问题。开源的HBase和Hypertable由于缺少大规模应用环境还不够稳定,实时性确实做得不好,不过这不是架构本身的问题,而是架构的复杂性导致的实现问题。

第二个对Bigtable的质疑,我们可以通过多数据中心的Replication来解决:同一个数据中心内部的Bigtable系统保证强一致性,机房之间通过回放操作日志进行数据同步,保证最终一致性。同一时刻只有一个集群提供写服务,其它集群提供读服务。当然,对应用方来说仍然是一整套系统,当某台Tablet Server宕机时,只影响短时间部分数据的写服务,读服务如果不要求强一致性不受影响。

描述CAP理论时我们经常会说,Dynamo是AP的系统,Bigtable是CA的系统。然而,Bigtable的分区可容忍性做得也还不错:Bigtable在机房断电,机房之间网络故障时仍然可以对外提供服务。假设在三个机房部署了三套Bigtable集群,且采用三机房五节点的方式部署了Chubby服务,任何一个机房断电或者某两个机房之间网络故障系统仍然能够对外服务。多个机房同时故障或者三个机房被分成三个区的情况理论上有可能,工程上可以认为不可能。所以,不要为了满足CAP理论上的特性而设计系统,业务需求才是本质。

总之,GFS&Bigtable设计在可扩展性,容错,负载平衡等各方面都有很大的优势,并且集群越大优势越明显,问题是整套系统过于复杂,对工程师,应用环境,管理层忍耐力都是一个考验。

相关 [系统工程 gfs bigtable] 推荐:

【分布式系统工程实现】Bigtable Merge-Dump存储引擎

- XiaoHui - NOSQL Notes
单机存储引擎解决单机读写问题,Merge-Dump存储引擎设计成一种通用的存储引擎,同时支持数据写入,随机读取和顺序扫描功能. 顺序扫描功能应用很广,比如MapReduce批处理,同一个广告主的所有关键词广告统计,用户浏览所有的收藏信息,淘宝卖家管理大量的商品等. 简单的KV系统只需要支持随机读取,而类似Bigtable这样的通用表格系统需要考虑基于主键的顺序扫描功能.

BigTable小结

- MAGI-CASPER/Peter Pan - 博客园-唯有前进值得敬仰
读完Bigtable论文小结一下. 对于Bigtable的整体理解 . BigTable将数据存储分为两部分:最近的更新存储在内存(memtable)中,较老的更新则以SSTable的格式存储在GFS,后者是主体部分,不可变的数据结构. 写操作的内容插入到memtable中,当memtable的大小达到一个阈值时就冻结,然后创建一个新的memtable,旧的就转换成一个SSTable写入GFS.

GFS架构分析

- zou - NOSQL Notes
Google文件系统(Google File System,GFS)是构建在廉价的服务器之上的大型分布式系统. 它将服务器故障视为正常现象,通过软件的方式自动容错,在保证系统可靠性和可用性的同时,大大减少了系统的成本. GFS是Google云存储的基石,其它存储系统,如Google Bigtable,Google Megastore,Google Percolator均直接或者间接地构建在GFS之上.

[转][转]LSM-Tree (BigTable 的理论模型)

- - heiyeluren的Blog
LSM-Tree理论模型:. 来源:http://www.cnblogs.com/raymondshiquan/archive/2011/06/04/2072630.html . Google的BigTable架构在分布式结构化存储方面大名鼎鼎,其中的MergeDump模型在读写之间找到了一个较好的平衡点,很好的解决了web scale数据的读写问题.

解读BigTable类NoSQL数据库的选型与设计

- - searchdatabase
  BigTable类数据库系统(HBase,Cassandra等)是为了解决海量数据规模的存储需要设计的. 这里说的海量数据规模指的是单个表存储的数据量是在TB或者PB规模,单个表是由千亿行*千亿列这样的规模组成的. 提到这个数据规模的问题,不得不说的就是现在在NoSQL市场中,最火的四种NoSQL系统依次是MongoDB,Redis,Cassandra,HBase.

后端分布式系列:分布式存储-HDFS 与 GFS 的设计差异

- - mindwind
「后端分布式系列」前面关于 HDFS 的一些文章介绍了它的整体架构和一些关键部件的设计实现要点. 我们知道 HDFS 最早是根据 GFS(Google File System)的论文概念模型来设计实现的. 然后呢,我就去把 GFS 的原始论文找出来仔细看了遍,GFS 的整体架构图如下:. HDFS 参照了它所以大部分架构设计概念是类似的,比如 HDFS NameNode 相当于 GFS Master,HDFS DataNode 相当于 GFS chunkserver.

Bigtable:一个分布式的结构化数据存储系统[中文版]

- Bian Jiang - Alex &amp;&amp; OpenCould
Bigtable:一个分布式的结构化数据存储系统. Bigtable是一个分布式的结构化数据存储系统,它被设计用来处理海量数据:通常是分布在数千台普通服务器上的PB级的数据. Google的很多项目使用Bigtable存储数据,包括Web索引、Google Earth、Google Finance.

[转载]投资是个系统工程

- - 穿过记忆的河流
原文地址: 投资是个系统工程 作者: 李白雨的投资博客.                               投资是个系统工程.                                              李白雨.     做投资的时间久了,难以避免地会碰到一些关于推荐股票的问题,直接的或者间接的.

Google的系统工程师(SA)如何工作

- freefish - Tim[后端技术]
本文根据系统管理领域知名博客 Thomas A. Limoncelli 的 What is system administration like at Google 整理而成,添加了部分笔者观点. Google的系统工程师(System Administrator)如何工作. 由于Google的服务已经集群化,系统工程师并不大量接触硬件比如做安装服务器等事情.

【分布式系统工程实现】GFS&Bigtable设计的优势

- hikerlive - 淘宝核心系统团队博客
目前,知名度比较高的通用存储系统包括:Google GFS&Bigtable,Amazon Dynamo,Microsoft Azure存储系统及Yahoo PNUTS. 其中,GFS&Bigtable,Azure存储系统及Yahoo PNUTS都有总控节点,Amazon Dynamo采用去中心化的P2P设计.