Dynamo和Bigtable对比
数据结构化问题
首先要提到的是两者存储数据属性上的区别,虽然两者都是以key/value形式进行存储,但Dynamo偏向存储原数据,因为其所存储的数据是非结构化数据,对value的解析完全是用户程序的事情,Dynamo系统不识别任何结构数据,都统一按照binary数据对待;而Bigtable存储的是结构化或半结构化数据(web数据特点就是介于结构化和非结构化之间,因此称为半结构化数据。我这里不展开说它了,不了解半结构化数据的赶紧去google一下吧!),其value是有结构的数据——就如关系数据库中的列一般,因而可支持一定程度的Query(比如可按单列进行)。这点上看Bigtable更接近数据库(接近而不是等价!至于和关系数据库的具体区别可去google 一下,网上论述可不少!);另外, Bigtable所存储的数据都是以字符串格式实现,所以对主建或者列(以及其自动加上的时间戳)排序都是以字符序进行,而dynamo的键值并非以字符串存储,而是统一经过md5算法转后成16字节md5_key存储的,因此对数据的访问必须知道key才可进行,故而对扫表(用游标)或者query访问则无能为力。当然在dynamo的基础上,配合一些方式我们实现query也并不可能,一些具体方式我们后面慢慢探讨!
控制与存储架构比较
Dynamo是采用DHT(分布哈希表,请参看有关资料吧)作为基本存储架构和理念,这个架构最大特点是能让数据在环中“存储”均匀,各存储点相互能感知(因数据需要在环内转发,以及相互之间进行故障探测,因此需要节点之间的通讯),自我管理性强,因为它不需要Master主控点控制,有点是无热点,无单点故障危险——插一句,目前新浪的memcachedb(改造memcached,增加了持续化能力)其实可认为是这种架构的最简单代表(数据进入系统后,使用DHT算法均匀的发送到存储节点上,而最后存储引擎采用Berkelery DB,将数据持续化到本地硬盘)。
Bigtable的控制是采用传统的server farm形式,使用一个主控服务器+多个子表服务器构成。而数据存储形式是采用多维Map的稀疏结构,可看成是由多个列表组成,所谓稀疏是说每条记录并非要求有全列。其数据(包括索引,日志,记录数据)最终是存储在分布文件系统DFS之上——数据被以DFS所特有的文件形式分布存储在各各节点之上。相比DHT的存储环自管理技术,它需要有master主控服务器来负责监控各客户存储节点(分配子表,失效检测,负载均衡等),另外索引文件的根也是集中存储,需要客户端首先读取(之后可以采用预读和缓存的技术减少读取索引表的次数)。这种集中控制的做法有一个缺陷就是系统存在单点故障 —— 因此单点需要高可用性,如记录恢复日志或双机备份等——但好处是更人为可控,方便维护,且集中管理时数据同步易于方便——显然,更新集中存储的原数据(如数据索引或节点路由等)相比DHT环中各个节点存储的原数据(如membership,即各点的路由关系)需要利用“闲谈机制”依次通知式地进行渐近更新要容易许多。
负载均衡问题
负载均衡(意义在于数据存储均衡和访问压力均衡)对于Dynamo系统而言是天生的优势,因为它采用了DHT方式将数据都均匀存储到各个点了,所以没有热点在(或者说要热,则环中所有的点一起热),各点的数据存储量和访问压力应该都是均衡的(这点由md5算法特性决定)。 另外这里还要提一下Dynamo系统中的Virtual Node概念——VNODE 可看成一个资源容器(类似于虚拟机),存储作为一个服务运行于其中。引入VNODE 目的在于将资源管理粒度单元化。 比如一个VNODE 让你且只让你管理5G硬盘,500M内存等,那么你就只能使用这么多资源。这样有两个显而易见的好处:1 方便管理不同配置的异构机器,比如资源多的机器多部署一些VNODE ,而资源少的机器少不部署一些VNODE 。 2 对于扩容大有好处,因为DHT环中加入一个新节点,如果想保持数据均匀分布的特性,那么必须将全环的数据都要移动才有可能,这样无疑增加了网络震荡,因此最理想的方式是在环内每个点都进行扩容,这样就只需要移动旁边节点的数据了。那么单增加一个或几个机器显然不能均匀分配环的其他存储点旁,因此需要将一台物理机器划分成众多个VNODE ,这样才有可能能将这些VNODE 比较均匀的散布在环内其他节点旁了。随着逐步添加机器,那么数据均匀性逐步提高,可见这是一种逐渐式的数据均衡过程。
对于Bigtable的负载均衡是也是基于传统上server farm :依靠一个master服务器监视子表 server的负载情况,根据所有子表服务器的负载情况进行数据迁移的,比如将访问很热的列表迁移到压力轻的子表服务器上(数据最终还是落在了chunk server —— DFS上的存储服务点,从层级结构上来说处于子表服务器之下)。具体做法你可参见他们的论文,总的来说有没有太多创新。