几种云架构的介绍

Dynamo 和 Bigtable
Dynamo是Amazon公司开发的并有详细的论文
Bigtable是Google公司开发的且也有详细的实现论文

下面将针对两者在存储数据的要求、体系架构、扩容、负载均衡、容错、数据存取及查询等方面进行一些简单的分析比较

a. 存储数据的要求
两者都是Key-Value形式进行存储

Dynamo偏向存储原数据,其所存储的数据是非结构化数据,对value的解析完全是用户程序的事情,不识别任何结构数据,都统一按照binary数据对待

Bigtable存储的是结构化或半结构化数据(web数据特点就是介于结构化和非结构化之间),其value是有结构的数据——就如关系数据库中的列一般,因而可支持一定程度的Query(比如可按单列进行)

Bigtable所存储的数据都是以字符串格式实现,所以对主建或者列(以及其自动加上的时间戳)排序都是以字符序进行,而dynamo的键值并非以字符串存储,而是统一经过md5算法转后成16字节md5_key存储的,因此对数据的访问必须知道key才可进行,故而对扫表(用游标)或者query访问则无能为力。当然在dynamo的基础上,配合一些方式我们实现query也并不可能.

b. 控制与存储架构
Dynamo是采用DHT(分布哈希表,请参看有关资料吧)作为基本存储架构和理念,这个架构*大特点是能让数据在环中“存储”均匀,各存储点相互能感知(因数据需要在环内转发,以及相互之间进行故障探测,因此需要节点之间的通讯),自我管理性强,因为它不需要Master主控点控制,有点是无热点,无单点故障危险

Bigtable的控制是采用传统的server farm形式,使用一个主控服务器+多个子表服务器构成。而数据存储形式是采用多维Map的稀疏结构,可看成是由多个列表组成,所谓稀疏是说每条记录并非要求有全列。其数据(包括索引,日志,记录数据)*终是存储在分布文件系统DFS之上——数据被以DFS所特有的文件形式分布存储在各各节点之上。

Server farm相比DHT的存储环自管理技术,它需要有master主控服务器来负责监控各客户存储节点(分配子表,失效检测,负载均衡等),另外索引文件的根也是集中存储,需要客户端首先读取(之后可以采用预读和缓存的技术减少读取索引表的次数)。这种集中控制的做法有一个缺陷就是系统存在单点故障 —— 因此单点需要高可用性,如记录恢复日志或双机备份等——但好处是更人为可控,方便维护,且集中管理时数据同步易于方便——显然,更新集中存储的原数据(如数据索引或节点路由等)相比DHT环中各个节点存储的原数据(如membership,即各点的路由关系)需要利用“闲谈机制”依次通知式地进行渐近更新要容易许多。

c. 容错问题
Dynamo和Bigtable都不是实验室应付领导参观,或者是炫耀技术的Demo,而是要实实在在进行商业运营的产品,因此首先要考虑的是机器成本问题!

*节约的方式就是采用普通PC服务器(目前市场价格大约2/3千元就能买到存储1T数据的机器——自然是没有显示器,声卡这些外设的)作为存储机器。

这些PC服务器自然是没有显示器,声卡这些外设的)作为存储机器。但做过大数据处理的人都知道,IDE/STAT硬盘的稳定性和寿命是无法和真正服务器中的SCSI硬盘相媲美(除硬盘外的其余部件的稳定性和寿命也一样和服务器差距颇大),在压力下损坏那是家常便饭——据Google说,1000台机器的集群中,平均每天坏掉一台机器——因此设计之初就将硬件故障认为是常态的,也就是说容错成为设计优先考虑的问题了。

Dynamo和Bigtable的数据都是冗余存放,也就是说一份数据会被复制成数份(副本数是可以根据数据要紧程度指定的),并被分散放在不同的机器上,以便发生机器宕机(偶然性宕机或网路不通属于临时故障,而硬盘坏掉则是永久故障,永久故障需要进行故障恢复——从副本恢复数据)时还有可用副本可继续提供服务——通常存放三个副本就已经可以高枕无忧了,因为要知道三个副本同期坏的可能性小到了 1000*1000*1000分之一

Dynamo 的冗余副本读写策略比较有趣,它定义了:N,W,R三个参数。其中N代表系统中每条记录的副本数,W代表每次记录成功写操作需要写入的副本数,R代表每次记录读请求*少需要读取的副本数。(详细参见论文)

Bigtable的容错问题论文中没有详细讲

d. 扩容问题
Dynamo将md5 key所围成的环行区间,尽量划分的粒度细一些,也就是多分成一些较小的区间/段(一个段对应存在硬盘上的一个数据表),但是要求一个物理机器不只存储一个段,而是存储连续区间的一组段表,并且在扩容期间不停服务

可参见Hypertable(Bigtable的开源C++实现)

e. 负载均衡问题
对于Dynamo系统而言是天生的优势,因为它采用了DHT方式将数据都均匀存储到各个点了,所以没有热点在(或者说要热,则环中所有的点一起热),各点的数据存储量和访问压力应该都是均衡的(这点由md5算法特性决定) – 注意Dynamo的Virtual Node概念

Bigtable的负载均衡是也是基于传统上server farm :依靠一个master服务器监视子表 server的负载情况,根据所有子表服务器的负载情况进行数据迁移的,比如将访问很热的列表迁移到压力轻的子表服务器上(数据*终还是落在了chunk server —— DFS上的存储服务点,从层级结构上来说处于子表服务器之下)

f. 数据存取和查询问题
都支持主建的随机查询

如果需要按照列进行查询,或者需要range的query查询,则Dynamo就无能为力了

Bigtable并没有关系数据那么强,对于query的支持也仅仅是支持条件是单个列,不能以多列为目标进行复合条件查询,更别说join查询

Simpledb 值的研究一下

Hbase
Hadoop的一个子项目,类似于Bigtable , *适合使用Hbase存储的数据是非常稀疏的数据(非结构化或者半结构化的数据)。Hbase之所以擅长存储这类数据,是因为Hbase和Bigtable一样,是列导向的存储机制

Couchdb
Apache下的一个面向文档存储,由Erlang开发而成,和其他新型存储系统一样它同样是分布存储系统,具有很好的扩展性。但不同在于没有任何统一的 schema可言,数据组织是平坦的,无行无列。如果需要查询等操作,则借助于用户自己提供的聚合与过滤算子,以Map/Reduce方式进行对文档信息进行全文检索处理——这个角度上说它也能实现类似数据库的查询,可方式方法完全不同——但它提供了一个view的数据关系逻辑接口,对用户而言,可以想象成传统的表

Simpledb
amazon公司开发的一个可供查询的分布数据存储系统,它是Dynamo键值存储的补充和丰富,目前用在其云计算服务中。其具体实现方式没有论文公开

Pig
yahoo捐献给apache的一个很有趣项目,它不是一个系统,而是一个类SQL语言, 具体目标是在MapReduce上构建的一种高级查询语言。目的是把一些运算编译进MapReduce模型的Map和Reduce中,允许用户可以自己的功能. Pig支持的很多代数运算、复杂数据类型(tuple,map)、统计运算(COUNT,SUM,AVG,MIN,MAX)和相关数据库检索运算(FILTER,GROUP BY,ORDER,DISTINCT,UNION,JOIN,FOREACH … GENERATE)

原文链接:https://blog.csdn.net/lzz313/article/details/5333630