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。
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個結果了。