Google GAE Datastore：云計算中的結(jié)構(gòu)化數(shù)據(jù)
GAE Datastore是Google App Engine提供的（半）結(jié)構(gòu)化數(shù)據(jù)存儲系統(tǒng)，基于Google大名鼎鼎的Bigtable技術(shù)構(gòu)建。
一、數(shù)據(jù)模型
GAE Datastore的數(shù)據(jù)模型與關(guān)系模型有很大的相似性，但是無模式的。GAE Datastore的接口主要是ORM風(fēng)格的，一個類，稱為kind，與關(guān)系數(shù)據(jù)庫中的表類似。一個kind中的數(shù)據(jù)為多個entity，每個entity有唯一的key標(biāo)識。每個entity可有多個property，一個property可用多個value。這與關(guān)系模型有類似的地方，但GAE Datastore中屬于同一個model的不同entity可以擁有完成不同的property，不同entity的同一個property的value的類型也可以不一樣。因此GAE Datastore的數(shù)據(jù)模型更為靈活。
多個entity可組成entity group，一個entity group實際上是以一個entity為根，通過父子關(guān)系（在創(chuàng)建entity時指定父親）構(gòu)成的子樹。這一模型類似于關(guān)系模型之前的層次數(shù)據(jù)庫，自然也擁有與層次數(shù)據(jù)庫類似的局限，如很多模型就很難自然的用這種層次模型建模，如學(xué)生選課系統(tǒng)Student-Course-Elect，誰是誰的父親呢。entity group主要用于事務(wù)，后面會講到。
二、查詢與索引
GAE Datastore提供類似于SQL的GQL查詢，從SQL的觀點看，GQL的限制是只有單表查詢，有WHERE、ORDER BY和LIMIT/OFFSET，但沒有GROUP BY、HAVING、聚集函數(shù)等功能，也不支持子查詢。WHERE條件可以是基本的"property op value"條件通過and/or任意組合，ORDER BY可指定多個屬性。但條件的復(fù)雜度有一定限制：
１、如IN (list)條件中l(wèi)ist最多只能有30個元素；
２、不等條件只能針對一個屬性指定；
３、不等條件屬性必須出現(xiàn)到ORDER BY的最前；
這些限制，據(jù)估計應(yīng)該是為了實現(xiàn)方便和保證性能，如不等條件屬性在ORDER BY的最前這一限制使得系統(tǒng)可以方便的通過索引掃描直接輸出有序的結(jié)果，不需要再來排序。
更新的形式相比SQL有很大的限制。UPDATE通過put接口實現(xiàn)，給的參數(shù)是一個完整的entity，似乎不能像SQL一樣只更新某些屬性，為了更新一個屬性，似乎需要先取出整個entity（系統(tǒng)可能用lazy load技術(shù)，沒有用到的屬性不會?。?。刪除時只能指定一個key列表，在關(guān)系數(shù)據(jù)庫中的一條DELETE語句要分成兩步，先通過查詢得到要刪除的entity的key，然后再來刪除。并且一次操作中刪除的entity個數(shù)不能超過500。
默認情況下GAE Datastore會建立一些基本的索引，根據(jù)文檔的描述，我推測GAE應(yīng)默認為每個屬性建了一個索引，并且索引中都包含key (類似于InnoDB中的二級索引中都包含主鍵)。應(yīng)用也可以在在配置文件中定義索引，指定索引包含的屬性及排序方向。索引的排序方向必須與查詢中ORDER BY的方向一致，也就是索引只能正向，不能反向掃描，我不清楚造成這一奇怪限制的原因是什么。
如果一個查詢沒有合適的索引，則不允許執(zhí)行，也就是像關(guān)系數(shù)據(jù)庫一樣的表掃描是不行的。
三、事務(wù)
不使用事務(wù)時，對每個entity的寫操作是原子的。
系統(tǒng)使用樂觀的并發(fā)控制，其特征是在有并發(fā)沖突時，不等待，而是讓操作回滾失敗。這保證了操作的響應(yīng)時間，但可能導(dǎo)致由于無法立即完成而失敗的操作增多，這就好比基于鎖的數(shù)據(jù)結(jié)構(gòu)會被阻塞，無鎖數(shù)據(jù)結(jié)構(gòu)則可能需要不斷的進行CAS循環(huán)。系統(tǒng)提供自動的重試機制緩解這一問題。
在同一個entity group中的多個entity操作可組合成一個事務(wù)，事務(wù)的ACID性質(zhì)有保障。GAE Datastore應(yīng)該是通過多版本的技術(shù)實現(xiàn)的，因此事務(wù)能夠獲得事務(wù)開始時的一致快照，奇怪的是事務(wù)本身的更新也看不到。
對不同entity group的操作是無法組合事務(wù)的，而entity group必須通過entity間的父子關(guān)系才能組織趕來。這使得GAE Datastore的事務(wù)會受一些限制，比如經(jīng)典的銀行轉(zhuǎn)賬問題是搞不定的，兩個銀行賬戶，誰是誰的父親呢。理論上用一個偽的根entity把所有entity組成一個entity group，可以解決這一問題，但這會影響性能。因此只所以限制事務(wù)只能在一個entity group內(nèi)，是因為系統(tǒng)在決定entity存儲位置時，會將同一entity group存在在一臺機器上，如果把所有entity都納到一個group，系統(tǒng)就無法分布與伸縮。
有一個細節(jié)問題是事務(wù)的提交分兩步進行：更新entity和更新索引。因此可能出現(xiàn)根據(jù)key找到的是更新后的entity，但根據(jù)索引找不到。
四、限制
GAE Datastore的數(shù)據(jù)或操作有很多限制，比如entity***1M，一次刪除的entity最多500個，查詢最多返回1000個結(jié)果等。這些限制可能會給應(yīng)用開發(fā)帶來不便。對于查詢最多返回1000個結(jié)果這個限制，準(zhǔn)確的說是limit + offset不能超過1000，即如果你指定了offset是200，那最多只能返回800個結(jié)果了。
五、評價
系統(tǒng)性能的兩大要素是Scalabity和Efficiency。Scalable的系統(tǒng)不一定Efficient，Efficient的系統(tǒng)也不一定Scalable。對于海量數(shù)據(jù)存儲系統(tǒng)來說，Scalable是必須的，是行與不行的問題，但Efficient也是非常重要的，是省與不省的問題。
GAE Datastore的Scalabity我估計是不錯的，但我不清楚有什么具體的證據(jù)表明其Scalabity到底怎么樣。GAE Datastore的數(shù)據(jù)分布對應(yīng)用來說是透明的，應(yīng)用不能指定根據(jù)某屬性的值進行哈希分區(qū)之類的顯式數(shù)據(jù)分布策略，這使得精準(zhǔn)的查詢路由難以實現(xiàn)，Bigtable論文中說的bloom filer的效果是值得懷疑的。如果實現(xiàn)不了精準(zhǔn)的查詢路由，很多查詢都要訪問大量存儲節(jié)點的話，就會影響到Scalabity。 雖然Google內(nèi)部很多產(chǎn)品也用用GAE Datastore，但我們知道Google是買服務(wù)器不眨眼的，不好比。
但其Efficiency怎么樣，我持很大的懷疑態(tài)度。無模式將使得系統(tǒng)不能進行很多優(yōu)化，底層基于GFS，通過冗余保證可靠性等都可能會影響到系統(tǒng)效率。有人反映Amazon SimpleDB不快，最簡單的查詢的響應(yīng)時間也超過100ms，不知道類似的GAE Datastore會怎么樣。
功能上，***的優(yōu)勢是無模式帶來的好處，即應(yīng)用升級時不需要像數(shù)據(jù)庫那樣做非常耗時的增加/刪除字段操作了。但這是一把雙刃劍，也可能會帶來混亂。打個比方，這就類似于靜態(tài)類型與動態(tài)類型編程語句的區(qū)別。
其次，是ORM風(fēng)格的接口帶來的開發(fā)便利，不需要像JDBC編程那樣寫很多SQL語句。
與數(shù)據(jù)庫相比，GAE Datastore的功能局限性也是明顯的，主要體現(xiàn)在查詢處理和事務(wù)處理兩個方面。查詢處理方面，查詢只能是單表，沒有GROUP BY和聚集函數(shù)，查詢的條件復(fù)雜度和查詢返回的記錄數(shù)都存在限制；DELETE不能指定WHERE，只能指定key的列表等。對事務(wù)的支持是受限的，只能在entity group中進行。這些局限，給應(yīng)用開發(fā)會帶來多大的困難，我不清楚。我想，只有將我們的常見的應(yīng)用如用戶與好友關(guān)系、日志、相冊、消息等，用關(guān)系數(shù)據(jù)庫和GAE Datastore對照著實現(xiàn)一遍，那么哪個系統(tǒng)好用，哪個不好用才能一清二楚。
【編輯推薦】
