本文讲的是对云计算中几种基础设施的朴素看法，【IT168 资讯】云计算的概念近期可谓如火如荼，备受关注。我先前听到“云”这个名词时，很是觉得太过玄乎——也不知道它用在哪里，更不了解它如何实现，总有雾里看花的感觉！

　　好在近期工作需要的缘故，学习和开发过类似于“云计算”基础设施的内部系统,之后再回过头来看看业界两大寡头(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）

结束语：

　　我了解的差不多就这么多了。要知道这个领域发展很快，知识更新日新月异——各种存储系统和计算架构如雨后春笋层出不穷，相互促进，各显神通。 至于那个最好，大约只能取决于你实际的需求了。我也是开始学习时间不长，可能很多地方理解不对或者说的不清楚，欢迎大家批评指正。很希望能结交一些研究类似系统的朋友，那么就算我的目的达到了。呵呵！