谈下自己了解的云计算

2010年里，云计算发展异常迅猛，分布式架构 ，并行运算，分布存储，Hadoop，Map Reduce  ，SAAS，PAAS，IAAS 等词非常受人追捧。国内几大网络公司包括百度，新浪等也紧随google，Amazon开放了各自的app开放平台。当然相对于开放平台，IBM，Microsoft就属于封闭式云计算平台了。

 

1   Google  GAE

 

GAE(Google App Engine)。GAE也是Google云计算的一部分，是一个互联网应用服务引擎，开发人员可以使用GAE的API开发互联网应用，而带宽、主机全都不用担心，Google都提供给你了。目前免费用户拥有500M存储空间、每月500万次PV，对于一般的应用应该足够了。你可以用GAE来托管你的开心网、校内的应用，不用再为没有主机发愁了。

 

   google的云计算提供的服务如图1所示：

 

 

 

图 1 Google 云计算平台服务

 

在上图中，还有Google提供的很多服务没有一一列举出来，但是我们可以了解到在Google云计算平台上，Google云计算的SaaS层是Google Docs、Gmail、Google Earth、New search、Checkout、Google wave、Google Gears；Goole云计算的PaaS层是Google App Engine，GAE。

 

 

以下引自 http://database.51cto.com 

Google GAE Datastore：云计算中的结构化数据

 

GAE Datastore是Google App Engine提供的（半）结构化数据存储系统，基于Google大名鼎鼎的Bigtable技术构建。

一、数据模型

GAE Datastore的数据模型与关系模型有很大的相似性，但是无模式的。GAE Datastore的接口主要是ORM风格的，一个类，称为kind，与关系数据库中的表类似。一个kind中的数据为多个entity，每个entity有唯一的key标识。每个entity可有多个property，一个property可用多个value。这与关系模型有类似的地方，但GAE Datastore中属于同一个model的不同entity可以拥有完成不同的property，不同entity的同一个property的value的类型也可以不一样。因此GAE Datastore的数据模型更为灵活。

多个entity可组成entity group，一个entity group实际上是以一个entity为根，通过父子关系（在创建entity时指定父亲）构成的子树。这一模型类似于关系模型之前的层次数据库，自然也拥有与层次数据库类似的局限，如很多模型就很难自然的用这种层次模型建模，如学生选课系统Student-Course-Elect，谁是谁的父亲呢。entity group主要用于事务，后面会讲到。

二、查询与索引

GAE Datastore提供类似于SQL的GQL查询，从SQL的观点看，GQL的限制是只有单表查询，有WHERE、ORDER BY和LIMIT/OFFSET，但没有GROUP BY、HAVING、聚集函数等功能，也不支持子查询。WHERE条件可以是基本的"property op value"条件通过and/or任意组合，ORDER BY可指定多个属性。但条件的复杂度有一定限制：

１、如IN (list)条件中list最多只能有30个元素；

２、不等条件只能针对一个属性指定；

３、不等条件属性必须出现到ORDER BY的最前；

这些限制，据估计应该是为了实现方便和保证性能，如不等条件属性在ORDER BY的最前这一限制使得系统可以方便的通过索引扫描直接输出有序的结果，不需要再来排序。

更新的形式相比SQL有很大的限制。UPDATE通过put接口实现，给的参数是一个完整的entity，似乎不能像SQL一样只更新某些属性，为了更新一个属性，似乎需要先取出整个entity（系统可能用lazy load技术，没有用到的属性不会取）。删除时只能指定一个key列表，在关系数据库中的一条DELETE语句要分成两步，先通过查询得到要删除的entity的key，然后再来删除。并且一次操作中删除的entity个数不能超过500。

默认情况下GAE Datastore会建立一些基本的索引，根据文档的描述，我推测GAE应默认为每个属性建了一个索引，并且索引中都包含key (类似于InnoDB中的二级索引中都包含主键)。应用也可以在在配置文件中定义索引，指定索引包含的属性及排序方向。索引的排序方向必须与查询中ORDER BY的方向一致，也就是索引只能正向，不能反向扫描，我不清楚造成这一奇怪限制的原因是什么。

如果一个查询没有合适的索引，则不允许执行，也就是像关系数据库一样的表扫描是不行的。

三、事务

不使用事务时，对每个entity的写操作是原子的。

系统使用乐观的并发控制，其特征是在有并发冲突时，不等待，而是让操作回滚失败。这保证了操作的响应时间，但可能导致由于无法立即完成而失败的操作增多，这就好比基于锁的数据结构会被阻塞，无锁数据结构则可能需要不断的进行CAS循环。系统提供自动的重试机制缓解这一问题。

在同一个entity group中的多个entity操作可组合成一个事务，事务的ACID性质有保障。GAE Datastore应该是通过多版本的技术实现的，因此事务能够获得事务开始时的一致快照，奇怪的是事务本身的更新也看不到。

对不同entity group的操作是无法组合事务的，而entity group必须通过entity间的父子关系才能组织赶来。这使得GAE Datastore的事务会受一些限制，比如经典的银行转账问题是搞不定的，两个银行账户，谁是谁的父亲呢。理论上用一个伪的根entity把所有entity组成一个entity group，可以解决这一问题，但这会影响性能。因此只所以限制事务只能在一个entity group内，是因为系统在决定entity存储位置时，会将同一entity group存在在一台机器上，如果把所有entity都纳到一个group，系统就无法分布与伸缩。

有一个细节问题是事务的提交分两步进行：更新entity和更新索引。因此可能出现根据key找到的是更新后的entity，但根据索引找不到。

四、限制

GAE Datastore的数据或操作有很多限制，比如entity最大1M，一次删除的entity最多500个，查询最多返回1000个结果等。这些限制可能会给应用开发带来不便。对于查询最多返回1000个结果这个限制，准确的说是limit + offset不能超过1000，即如果你指定了offset是200，那最多只能返回800个结果了。

 

未完待续。。。。。。