前言
云计算的概念近期可谓如火如荼,备受关注。我先前听到“云”这个名词时,非常以为太过玄乎——也不知道它用在哪里,更不了解它如何实现,总有雾里看花的感受!
好在近期工做须要的缘故,学习和开发过相似于“云计算”基础设施的内部系统,以后再回过头来看看业界两大寡头(Google,Amazon)推出各自的云计算服务,从认识上才算是真的将“云”这个天书般的概念落实。后面的文章中我将在我的理解的基础上,针对云计算的概念,体系结构,以及适用性等方面做一些不算很深刻分析和对比,但愿对你们理解云计算架构有所帮助。
第一部分 什么是云计算
云计算的标准定义留给你们去Google吧,我这里谈谈我简化理解后的云计算是什么东东:先来看云计算的产生缘由吧!——首要缘由是为了应对待处理数据爆炸式增加与当今机器存储能力和计算能力不足之间的矛盾(借用一下我国当前基本矛盾的书法:)。因为待处理数据愈来愈多(不是用多少G就能描述的范畴了。想象一下倘若要存储并计算数千万用户的访问日志,或者计算数亿个网页的Page Rank),多到了很难在一台或有限数目的存储服务器内容纳,且更没法由一台或数目有限的计算服务器就能处理这样的海量数据。—— 固然,你也许会想到买来漂亮的EMC存储阵列和HP的SUPERSTONE这样的小型机搞定一切,可是它们有点贵喽,这种砸钱的你们伙只能留给阔绰的银行、电信企业,或者国家气象局这些机构使用了—— 这时就须要能在普通机器(好比在中关村攒出的廉价PC)上分布式的存储这些数据,并能在其上分布式计算这些数据。你确定会说,这不久是分布计算吗?没错,云计算能够说是经分布计算,并行计算,网格计算一脉相承的技术路线,甚至能够说它们基因相同。但它们的给人的外貌却不一样,这是由于云计算是通过商业包装的名词,其实就是将分布存储和分布计算这种技术找了个盈利模式——将存储能力和计算能力出售给第三方企业。而第三方不需知道其数据到底存在那个机器上,也不须要知道那个机器在处理它们的数据,所以对它们来讲数据在云端,计算也在云端,大约如此,才有了“云计算”这个概念。
目前出售云计算服务的有Amazon和Google两个业界老大(据说Oracle和APPLE也开始搞了,EMC彷佛也有计划),出售的服务内容大致相同,盈利方式也大同小异(具体参看他们的网站的S3服务, EC2服务,或Google App Engine服务等)。它们技术架构虽有差别,但从概念上讲可把云计算当作是“存储云”结合“计算云”的有机结合,即“云计算 = 存储云 + 计算云”
第二部分 存储云的架构介绍
存储云概念
存储云依我看就是一个被商业包装过的分布存储系统——只不过它对第三方用户公开存储接口,用户可买容量和带宽,且规模至关宏伟的分布存储系统。关于商业模式问题咱们就很少做探讨了,你们可到其网站上仔细瞧瞧。我这里的重点是对用于存储云的分布存储系统做对比分析。(不过假如你对存储云彻底不了解,那我建议在看下面内容以前,先去读读相关的论文什么的介绍吧!以便咱们的讨论事半功倍。)
存储云结构比较——Dynamo VS Bigtable
比较典型的存储云基础系统有Amazon公司的Dynamo系统与Google公司的Bigtable系统,这两种系统不但已经开始是商用(参见S3 服务和 Google App Engine服务),并且都公开了比较详细的实现论文(尤为dynamo系统论文格外详尽——可见Amazon公司的无私和自信)。它们各自实现架构迥异,存储特性不一,但都结构优美,技术上各有可称道的地方,可谓各有千秋,却又异曲同工。
下面咱们将针对它们二者存储数据的要求、体系架构、扩容、负载均衡、容错、数据存取及查询等我以为重要的方面进行一些点到为止分析比较,以辨明良莠。
数据结构化问题
首先要提到的是二者存储数据属性上的区别,虽然二者都是以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和Bigtable都不是实验室应付领导参观,或者是炫耀技术的Demo,而是要实实在在进行商业运营的产品,所以首先要考虑的是机器成本问题!最节约的方式就是采用普通PC服务器(目前市场价格大约2/3千元就能买到存储1T数据的机器——天然是没有显示器,声卡这些外设的)做为存储机器。但作过大数据处理的人都知道,IDE/STAT硬盘的稳定性和寿命是没法和真正服务器中的SCSI硬盘相媲美(除硬盘外的其他部件的稳定性和寿命也同样和服务器差距颇大),在压力下损坏那是屡见不鲜——据Google说,1000台机器的集群中,平均天天坏掉一台机器——所以设计之初就将硬件故障认为是常态的,也就是说容错成为设计优先考虑的问题了。
鉴于上述缘由,Dynamo和Bigtable的数据都是冗余存放,也就是说一份数据会被复制成数份(副本数是能够根据数据要紧程度指定的),并被分散放在不一样的机器上,以便发生机器宕机(偶然性宕机或网路不通属于临时故障,而硬盘坏掉则是永久故障,永久故障须要进行故障恢复——从副本恢复数据)时还有可用副本可继续提供服务——一般存放三个副本就已经能够高枕无忧了,由于要知道三个副本同期坏的可能性小到了1000*1000*1000分之一。
Dynamo 的冗余副本读写策略比较有趣,它定义了:N,W,R三个参数。其中N表明系统中每条记录的副本数,W表明每次记录成功写操做须要写入的副本数,R表明每次记录读请求最少须要读取的副本数。只要W+R >N就能够保证数据的一致性。由于W+R>N时读写总会有交集——一定最少有W+R-N个读请求会落到被写的副本上,因此必然会读到“最后”被更新的副本数据(至于谁
“最后”的判断需采用时间戳或者时钟向量等技术完成——有逻辑关系前后由时钟向量判断,不然简单的用时间戳前后判断.详情去看dynamo论文吧)。这种作法相比咱们最朴素的想法——咱们直观的想法必定认为若是系统要求记录冗余N份,那么每次就写入N份,而在读请求时读取任意一份可用记录便可——要更安全,也更灵活。说其更安全是指数据一致性更能被保证:好比说客户写入一条记录,该记录有三个副本在三个不一样点上,可是其中一个点临时故障了,所以记录没有被写入/更新。那么在对该记录再读取时,若是取两点(R=2)则必然会读取到最少一个正确的值(临时故障点有可能在读是恢复,那么读出的值则不存在或者不是最新的;若临时故障点还未恢复,则读请求没法访问其上副本)。而使用咱们传统方法可能读到发生临时故障的那点,此刻就有可能读出现错误记录(旧的或者不存在),所以能够看到加大W,R可提升系统安全性;说其更灵活则是指可经过配置N,W,R这几个参数以知足包括访问方式、速度和数据安全等迥异需求的各类场景:好比对于写多读少的操做,可将W配低,R配高;想法对于写少读多的操做,则可将W配高,R配低。
Bigtable的容错问题论文中没有详细讲,我想它应该是将该任务交给其下的DFS处理了:DFS是在文件chunk(64M)写入chunk服务器时,将数据chunk传播给最近的N-1个chunk服务器,从而确保了系统中每一个chunk存在多个副本,而这些chunk 的位置信息都会记录在master服务器的文件原数据中。再访问文件时,会先得到原数据,再从可用的chunk服务器中获取数据,所以一个chunk server发生故障不影响数据完整性,照样能读。另外DFS的故障的恢复等工做也是在master服务器监控下将某个副本chunk进行复制,以恢复故障机器上的数据副本。
最后值得提一下的是,Dynamo对于临时故障的处理方式是:找到一台可用机器,将数据暂时写到其上的临时表中,待临时故障恢复后,临时表中的数据会自动写回原目的地。这样作得目的是达到永远可写(那怕该云中只有一台机器可用,那么写请求的数据就不会丢失)。这个需求未见Bigtable提到,但从其架构上看DFS对写操做来讲,应该也是能达到接近Dynamo的永远可写需求的(master会帮助选择一个可写的chunk server 做为写请求的接受者的,所以系统只要master不可用,最少再有一台可用chunk server机器就以知足。
扩容问题
对于一个存储可视为无限大的存储系统来讲,扩容需求(扩容需求除了存储容量不足外,存储节点并发处理能力不足,也会要求扩容)天然没法逃避,并且对于在线服务系统扩容时期要尽可能不中止服务或者尽量短的中止服务,所以优美的扩容方案是存储云中最值得关注的要点之一。
咱们仍是先来讲说Dynamo系统的扩容策略和实现。试想一下,将一个机器中的指定数据表扩容,首先须要将这个数据表劈开成两个表,而后再把其中一个转移到另一台新机器上去。而这里的劈表动做提及简单,做起来则颇为费力,由于不管数据表是按照键值区间有序组织(如DHT环方式),或键值自己有序组织(如Bigtable方式),都不可避免的须要扫描整个数据表(特耗资源的操做,绝对会影响其余服务的)才能从中挑选出一部分有序数据移到新表中,从而保证劈开后的两个表仍然维持有序结构。为了不笨拙的扫表工做,Dynamo取巧了,它会将md5 key所围成的环行区间,尽可能划分的粒度细一些,也就是多分红一些较小的区间/段(一个段对应存在硬盘上的一个数据表),可是要求一个物理机器不仅存储一个段,而是存储连续区间的一组段表,这样以来在扩容时就能将劈大表的操做给回避了。好比将环分红1024段(存储数据上规模时,实际部署时段表要分的更细致得多),而后又规定每一个存储点维护64个段表,那么所有数据起先可部署在 16个机器的存储环上。若是发现某个机器存储不下64个段表时(或者承受不了当前的并发请求量时),则将其中部分段表转移到新扩容的机器上去便可,好比从原机器上转移32个段表拷贝到新机器便可完成扩容——这种小表迁移避免了对大表拆分时的扫表、劈表动做。固然你会说这种扩容有限制,只能扩容6次。没错,所以在实际存储环之初,是须要估计数据总量,扩容次数等问题的,但这绝对得。
Dynamo除了段表思想值得学习外,还提出了扩容期间不停服务这种要求非常可爱。咱们也尝试过这种高可用性扩容设计,其主要任务是要理清楚,从而细致处理扩容期间(包括数据扩容和路由更新)的访问请求的状态机。另外要说的是扩容时为了避免影响正常请求访问, 都将扩容例程安排在低优先级进行, 让它在正常读写请求压力小时再偷偷进行!
对于Bigtable扩容问题Google自己的论文描述有些暧昧,但却可在另外一个类Bigtable系统——hypertable——那里看到比较清晰的说法。Hypertable是Bigtable的开源C++实现。因为Hypertable中记录存储是被集合成固定大小的tablet(默认的最大值是每一个200M)存在DFS上——而DFS自己具备可扩容性(容许在线添加新机器到server farm中)—— 所以Hypertable存储总空间的扩容不存任何问题。其要做的只是当子表(Range段)过大时,须要将其从中间key 劈开成两个新表,把包含后半段key范围的新字表迁移到别的range server上去。注意这种分子表的实现路数彷佛仍然须要去扫描表,在这一点上我我的认为不如Dynamo作的聪明、利索。关于hypertable的表的管理值得你们去留心,但这里很少说了。(请看hyptertable 站点:
http://www.hypertable.org/documentation.html/
)
负载均衡问题
负载均衡(意义在于数据存储均衡和访问压力均衡)对于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上的存储服务点,从层级结构上来讲处于子表服务器之下)。具体作法你可参见他们的论文,总的来讲有没有太多创新。
数据存取和查询问题
Dynamo和Bigtable两种体系都支持key/value形式的记录插入,并且也支持主建的随机查询。不过前面已经提到了若是须要按照列进行查询,或者须要range的query查询,则Dynamo就无能为力了,只能使用Bigtable架构(但要知道Bigtable并无关系数据那么强,对于query的支持也仅仅是支持条件是单个列,不能以多列为目标进行复合条件查询,更别说join查询等)。从这点上说bigtable更接近数据库,而Dynamo则是一个简单的存储系统。
amazon在S3(可能部分利用了Dynamo)以后,推出了支持query的Simpledb 系统。 该系统和Bigtable很相似,但彷佛功能更强,它支持=, !=, <, > <=, >=, STARTS-WITH, AND, OR, NOT, INTERSECTION AND UNION等复杂的query 操做。这真是个出色的产品,不幸的是amazon并无向对Dynamo那样慷慨的公开发表其实现的论文,所以你们只能猜想其实现,有的说是在Erlang上重写的,有的说在Dynamo基础上开发的,有的说是抛开Dynamo全新实现的,目前说法众多,无从得知。这里我仅仅就我我的的认知,谈谈假如在Dynamo上是如何实现Query功能相似的功能。
首先能想到的是为Dynamo增长schema,也就是将value划分红逻辑列,这样以来在存储时能够按列创建索引文件,那么就天然能够实现对列的 query。索引文件内容能够是列值到主建集合的映射,其存储以文件形式存在于分布文件系统之上。当对列进行query时,首先在索引文件中找到对应的主建集合,而后在以主建从Dynamo中得到记录。不过这样做有必定限制: 1 分布文件系统须要能支持并发修改文件能力(由于索引文件须要频繁改变),而大多数分布文件系统为了数据一致性和效率的考虑,都只能支持并发追加操做,所以要想实时的完成数据更新的同时支持查询操做有难度——简单的方法是按期更新索引文件,那么反作用就是查询的结果不是最新的;2 只能对预先创建索引的单列进行排序(固然能够创建联合索引),并不能支持对任列,或者任意的复合条件完成query查询——我是没想到什么好办法。
另一个方法是使用关系数据库做Dynamo的存储引擎——若是你看过Dynamo的论文,能否记得它提到了实际的存储引擎可以使用Berkelery DB或者mysql等——,那么在存储环中进行查询的操做可化整为零:将查询任务路由到各各存储节点上分别进行查询以后,再将结果收集起来,对于须要排序的请求则还要再集中进行排序一次。这种作法把索引等等的工做都交由关系数据库去做,咱们做的只是须要汇总结果。 在这个思路上能够进一步结合数据分发Partition策略:再也不按照md5 key那样在节点上均匀的存放数据,而是按照列做partition 篇分发数据,如地址属性中的Beijing,xi an等不一样地名的数据路由到指定不一样节点上,那么在按地名进行查询时,则能够直接将请求下发到对应存储节点,这样避免了全环下发查询人物,能更有效的完成以列为条件的复杂查询。除此外,还能够对列进行区间排序partation,如对年龄列,按照0-10岁一个区间,10-20一个区间,20-30一个区间,而每一个区间存储在不一样节点上,这种有序区间部署方法可支持按列排序查询要求。不过有得必有失,partition存放的缺点是数据不够均匀,所以负载不平衡,因此须要能把partation节点纵向扩容,好比把负责20-30区间的存储节点多搞几个以分担并发压力。
第三部分 当前计算云的架构实现
存储云的商业模式是出卖存储能力,而计算云的商业模式是出卖计算能力。存储云的基础技术是分布存储,而计算云的基础技术是分布计算——更准确说在是“并行计算“。 并行计算的做用是将大型的计算任务拆分,而后再派发到云中的节点进行分布式的并行计算,最终再将结果收集后统一整理(如排序、合并等)。 若是说云计算云是并行计算的升华的话,那么只在一个层面上有所进步 —— 计算资源虚拟化:计算云中的全部计算资源都被当作一个可分配和回收的计算资源池,用户可根据本身的实际需求购买相应的计算资源。
这种资源虚拟化得益于近日从新兴起的虚拟机技术,采用虚拟机实现资源的虚拟化,既能够避免了硬件异构的特性(不管什么样的硬件机器主要攒在一块儿,其计算资源均可被量化到计算资源池中,并被动态分配),更能够实现资源的动态调整,所以能极大的节约了云中的计算资源(动态调整就是不须要从新启动系统就可调整资源大小,这是虚拟化技术的最大用处之一)。这种虚拟化和咱们在本身机器上安装的虚拟机所采用的虚拟化技术大同小异,其异处就在于咱们我的用户的使用模式是将一台物理机器的资源虚拟化成多份,以使得其能同时启动多个操做系统;而云中的虚拟化技术是将多个物理机器的资源虚拟化成一个大的资源池,让用户感受是一个巨大资源的机器——可是要知道只有任务在能并行计算的前提下,资源池虚拟化才有意义。好比用100个386机器组成的计算云能够处理1T的日志数据,若是日志数据的处理能够被并行进行,那么可以让每一个386机器都处理1/100T的数据,最后将全部中间结果合并成最后结果。可是若是任务没法平行差分,再大的计算池也没用(云计算应用是有限的,目前最能用的上的是web网站——数据量大,但处理相对简单)。
总而言之:计算云的架构能够当作是:并行计算+ 资源虚拟化。
并行计算架构(Map/Reduce)
对于资源虚拟话的问题,这里不做讨论了,有机会咱们专门起个话题进行深刻探讨。这里主要说说云中的并行计算方式。并行计算是个老话题了,不少基于MPI的并行计算软件到处可见。MPI采用任务之间消息传递方式进行数据交换,其并行开发基本思路是将任务分割成能够独立完成的部分,再下发到各计算节点分别计算,计算后各节点将各自的结果汇总到主计算点进行最终汇总,各点之间的的交互由消息传递完成。对于并行计算面临的主要问题是: 1 算法是否能够划分红独立部分;2 获取计算数据以及中间结果存储代价很高,由于海量数据的读取会带来沉重的IO压力——如在处理诸如page rank等互联网应用上,很大程度上大量、频繁的读取分布存储的网页数据形成了任务计算速度的瓶颈。
对于第一个算法问题,从计算架构上考虑勉为其难,关键在于分割算法。而对于第二个IO压力问题,最好的解决办法莫过于Hadoop项目项目所用的Map/Reduce方式,其思想很简单,就是将计算程序下发到数据存储节点,就地进行计算,从而避免了在网络上传输数据的压力。这并不是一个创新思想,好久以前就有诸多尝试(好比IBM曾经搞国一个叫Aglet的移动代理项目,就是将计算程序下发到各节点计算和收集信息),但对于海量数据处理的今天这种方式无疑最具吸引力,代价最小。
简单说Map是一个把数据分开的过程,Reduce则是把分开的数据合并的过程。如Hadoop的word count例子:用Map把[one,word, one,dream]进行映射就变成了[{one,1}, {word,1}, {one,1}, {dream,1}],再用Reduce把[{one,1}, {word,1}, {one,1}, {dream,1}]归约变成[{one,2}, {word,1}, {dream,1}]的结果集。 关于Map/Reduce的抽象方法是map/recduce的精髓之一,但本文很少说它了(你可参看函数语言或其余种种资料,这里不在赘述),本文主要想谈谈Map 的数据来源问题。
MAP/REDUCE数据来源
Map 的数据来源初看也并不是什么问题,无非就是读本地数据而已(前面已经说过计算程序做为map的回调算子——借用java的说法——被转移到了数据所在地再执行)。然而具体在海量数据处理的应用场景下就必须考虑和分布存储系统搭配了。 Hadoop的搭配方式最简单,就是和其下的分布文件系统DFS配合: 经过文件系统的原数据来定位文件块的分布节点位置,而后将回调算子下发到其上,已顺序读取的方式从本地文件系统上读取数据。对于日志文件分析等应用,上述作法效率很高,由于日志文件读取但是顺序读取,文件系统的预读特色可充分利用 —— 离线日志分析是利用map/reduce分析的典型应用。
但咱们也应看到Map/Recduce 的使用也有明显的局限性:第一是,若是对于较为复杂的输入要求,好比须要对数据集合进行query查询,而非顺序读取文件的输入,则不能直接使用Hadoop的Map/Recduce框架;第二是,其下的分布文件系统为了一致性考虑,不支持多个并发写,并且写后不能修改,这些特性对日志等过后分析效果不错,但对于数据须要实时产生的场景有些勉为其难了。所以考虑是否能将Dynamo,甚至是Bigtable等分布存储系统或者分布类数据库系统在Map/Recduce环境下使用便成了新的需求。不过我感受Bigtable的存储结构彷佛不大容易实如今本地环境内完成进行较为复杂的查询(好比多列的符合查询,不必定能完成,且更不容易在本地完成——应为它没法避免到远程取数据,而若是一旦跨机器进行查询则又带来了过多的网络I/O,违背了Map/Reduce架构进行并行计算的设计初衷。那么Dynamo是否可知足负责query需求呢? 若是采用上文在查询时提到的方法:给记录定义对应的schema,并存储在存储点上将其存在传统的关系数据库中(能够在须要列上创建索引),那么将“回调算子——这里就是query语句了”下发到其上,则可按照传统方式在本地进行query!这样以来既符合了Map/Reduce的初衷,又能知足复杂输入需求,同时还能不影响数据的实时产生。所以我认为灵活、方便的并行计算架构能够由Dynamo或其变种存储系统(如上文所说的partition方式)+ Map/Reduce完成。
当前几种云计算架构中的明星系统
目前云计算中的各类子系统可谓风起云涌,层出不穷。我这里简单说起几个我了解过的项目,你们有兴趣的话可重点跟踪它们,近一步了解云计算知识。
1 Bigtable /Dynamo 上文已经讲过了。
2 Hbase 是Hadoop的一个子项目,相似于Bigtable , 最适合使用Hbase存储的数据是很是稀疏的数据(非结构化或者半结构化的数据)。Hbase之因此擅长存储这类数据,是由于Hbase和Bigtable同样,是列导向的存储机制
3 Couchdb 是Apache下的一个面向文档存储,由Erlang开发而成,和其余新型存储系统同样它一样是分布存储系统,具备很好的扩展性。但不一样在于没有任何统一的schema可言,数据组织是平坦的,无行无列。若是须要查询等操做,则借助于用户本身提供的聚合与过滤算子,以Map/Reduce方式进行对文档信息进行全文检索处理——这个角度上说它也能实现相似数据库的查询,可方式方法彻底不一样——但它提供了一个view的数据关系逻辑接口,对用户而言,能够想象成传统的表。
4 Simpledb 是amazon公司开发的一个可供查询的分布数据存储系统,它是Dynamo键值存储的补充和丰富,目前用在其云计算服务中。其具体实现方式没有论文公开。
5 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)
结束语: 我了解的差很少就这么多了。要知道这个领域发展很快,知识更新突飞猛进——各类存储系统和计算架构如雨后春笋层出不穷,相互促进,各显神通。 至于那个最好,大约只能取决于你实际的需求了。我也是开始学习时间不长,可能不少地方理解不对或者说的不清楚,欢迎你们批评指正。很但愿能结交一些研究相似系统的朋友,那么就算个人目的达到了。呵呵!